Buckets & Objekte

Wie kann ich auf meine Buckets zugreifen?

Für wesentliche Aktionen, wie das Erstellen eines Buckets, kann die Cloud Console genutzt werden. Um Daten in einem Bucket effizient zu verwalten und alle Funktionen des Object Storage vollständig zu nutzen, sollten Amazon S3-kompatible Tools mit der Hetzner S3 API verwendet werden. Es ist auch möglich, die API direkt zu nutzen. Da man die Signatur mit diesem Ansatz aber selbst erstellen muss, was recht mühsam sein kann, ist das nicht die empfohlene Option. Hier sind die Optionen zusammengefasst:

Beachten Sie, dass Sie zum Verwenden der API einen Access Key und einen Secret Key benötigen. Diese können über Cloud Console erstellt werden. Jedes "Access Key & Secret Key"-Paar kann automatisch für jeden Bucket innerhalb desselben Projekts verwendet werden.

• Amazon S3 REST API mit Hetzner S3 Endpunkt
• Tools, die eine Amazon S3-kompatible API unterstützen (z.B. S3cmd oder MinIO)
• Cloud Console (nur wesentliche Aktionen)

Für detaillierte Anleitungen, wie man Buckets mittels eines Amazon S3-kompatiblen API-Tools oder der Cloud Console erstellt und verwaltet, wechseln Sie über die linke Menüleiste zu Object Storage » Getting Started und wählen Sie eine der Optionen aus.

Wenn Sie die Sichtbarkeit des Buckets auf öffentlich setzen, können Sie über die Bucket URL in einem Webbrowser auf die Daten zugreifen.

Wer kann Buckets bearbeiten?

Über die Cloud Console kann jeder mit mindestens der Rolle "Mitglied" an den Buckets Änderungen vornehmen (Buckets hinzufügen / löschen).

Über die S3 API kann im Grunde jeder Daten hochladen / löschen — selbst jemand ohne Hetzner-Account.

• Wenn die Sichtbarkeit des Buckets auf privat gesetzt wurde, muss jedem der Zugriff benötigt ein Access Key und ein Secret Key bereitgestellt werden. Beachten Sie, dass ein privater Bucket öffentliche Objekte enthalten kann, wenn die Zugriffsrechte entsprechend personalisiert wurden.

• Wenn die Sichtbarkeit des Buckets auf öffentlich gesetzt wurde, wird für "Lese-Zugriff" kein Access Key oder Secret Key benötigt. Jeder, der die URL des Buckets und den Dateinamen kennt, kann auf die Dateien zugreifen und diese herunterladen (Dateien können nicht gelistet werden). Für "Schreib-Zugriff" (z.B. Daten hinzufügen) werden weiterhin ein Access Key und ein Secret Key benötigt.

Wie kann ich einen ganzen Ordner auf einmal hochladen?

Das hängt ganz vom S3-kompatiblen Tool ab. Wir empfehlen daher die entsprechende Dokumentation des Tools zu lesen. Mit MinIO Client würde der Befehl beispielsweise so aussehen:

mc mirror beispiel_ordner <alias_name>/<bucket_name>

beispiel_ordner
├── datei1
├── datei2
└── datei3

Mit diesem Befehl werden automatisch datei1, datei2 und datei3 ins Bucket hochgeladen.

Kann ich eine Datei innerhalb eines Buckets bearbeiten?

Nein, mit Object Storage ist es nicht möglich, Dateien zu bearbeiten, da Objekte unveränderlich sind. Um eine Datei zu "aktualisieren", muss die neue Version als neues Objekt hochgeladen werden. Wenn derselbe Objektname angegeben wird, wird das alte Objekt automatisch überschrieben.

Welche Namen sind für Buckets erlaubt?

Der Name muss folgenden Kriterien entsprechen:

• Entspricht den Bestimmungen aus RFC 1123 (siehe "2.1 Host Names and Numbers")
• Ist nicht wie eine IP-Adresse formatiert (z.B. 203.0.113.1)
• Ist einzigartig über alle Hetzner Object Storage Nutzer (unabhängig vom Standort)

Der Name muss einzigartig sein. Das heißt, dass zwei verschiedene Buckets nicht denselben Namen besitzen können, selbst wenn diese unterschiedliche Standorte besitzen. Diese Regel gilt Hetzner-weit, über alle Standorte. Wenn ein anderer Kunde bereits einen Bucket mit dem Namen ihrer Wahl besitzt, müssen Sie sich einen anderen Namen überlegen.

Der Bucket Name ist Teil der Bucket URL, weshalb der Name den Bestimmungen für Hostnamen entsprechen muss. Ein paar der Regeln lauten:

• Zulässig sind das Alphabet (A-Z), Zahlen (0-9), Minuszeichen (-)
• Keine Punkte (.)
• Keine Leerzeichen
• Keine Großbuchstaben
• Das erste Zeichen muss ein Buchstabe oder eine Zahl sein
• Das letzte Zeichen darf kein Minuszeichen sein
• Host-Namen müssen aus mindestens drei und höchstens 63 Zeichen bestehen

Beachten Sie, dass es nicht möglich ist den Namen zu ändern, nachdem ein Bucket erstellt wurde.

Welche Namen sind für Objekte erlaubt?

Bei der Benennung der Objekte, sollte man folgende Regeln beachten:

• Maximal 1024 Bytes (entspricht 1024 US-ASCII-Zeichen)
• Zulässig sind das Alphabet (A-Z) und Zahlen (0-9)
• Zulässig sind Sonderzeichen, z. B. ! - . * ' ( und ).
• Zulässig sind UTF-8-Zeichen. Solche Zeichen können aber Probleme verursachen.

In einem Bucket können keine Ordner oder Unterordner angelegt werden. Um eine hierarchische Struktur darzustellen, muss man das Objekt entsprechend benennen und die einzelnen "Ordner" mit / simulieren.

Beispiele:

• website/images/example1.jpg
• website/images/example2.jpg
• backup/snapshot.bak
• backup/mysqldump.dmp

Wann kann ich den Namen eines gelöschten Buckets wieder verwenden?

Nachdem ein Bucket gelöscht wurde, wird dessen Name 14 Tage später für andere Buckets wieder verfügbar.

Können Buckets zwischen Projekten verschoben werden?

Es ist derzeit nicht möglich, Buckets von einem Projekt in ein anderes zu verschieben. Wenn Sie Daten zwischen Projekten verschieben möchten, müssen Sie einen neuen Bucket im Zielprojekt erstellen und die Objekte mit Tools wie z.B. rclone oder ähnlichen replizieren.

Wie schütze ich meinen Bucket vor versehentlichem Löschen?

Buckets können in der Cloud Console mit der Eigenschaft protected geschützt werden. Protected ist eine Eigenschaft, die festlegt, dass ein Bucket nie gelöscht werden darf. Bevor Sie einen geschützten Bucket löschen können, müssen Sie zuerst den Löschschutz deaktivieren.

In der Cloud Console werden geschützte Ressourcen auf der Übersichtsseite der Buckets durch ein Sperrsymbol angezeigt.

Wie schütze ich meine Objekte vor versehentlichem Löschen?

Objekte können nicht nur manuell versehentlich gelöscht werden. Wenn Sie ein neues Objekt mit dem gleichen Namen wie ein bereits existierendes Objekt hochladen, wird das existierende Objekt automatisch gelöscht und mit dem neuen Objekt ersetzt. Wenn man bei der Namensgebung von Objekten nicht bewusst aufpasst, kann es daher zu versehentlichen Verlusten von wichtigen Daten kommen.

Um Objekte vor automatischem Löschen zu schützen, kann Versioning genutzt werden.

Um Objekte vor manuellem Löschen zu schützen, kann Object Locking genutzt werden. Beachten Sie allerdings, dass Object Locking nur genutzt werden kann, wenn diese Option bereits beim Erstellen des Buckets aktiviert wurde. Dafür muss der Bucket wie in diesem How-To erklärt mittels eines S3-kompatiblen Tools erstellt werden.

Insgesamt stehen folgende Optionen zur Verfügung:

Siehe hierzu folgende Amazon S3 Artikel: Versioning, Retention, Legal Hold

Kann ich einem Bucket eine eigene Domain / CNAME zuweisen?

Diese Funktion ist derzeit noch nicht verfügbar. Wir beabsichtigen aber, diese in Zukunft hinzuzufügen.

Was ist der Unterschied zwischen Versioning und Object Locking?

Versioning ermöglicht es das automatische Überschreiben von Objekten zu verbieten. Jedem Objekt wird automatisch eine Versions ID zugewiesen. Dadurch ist es möglich mehrere Versionen eines Objekts in einem Bucket zu speichern. Wenn ein Objekt mit einem Namen hochgeladen wird, der im Bucket bereits vorhanden ist (z.B. file_name.txt), wird das bestehende Objekt somit nicht gelöscht, sondern über die Versions ID unterschieden. Das manuelle Löschen von Objekten ist weiterhin möglich.

Object Locking ermöglicht es, das manuelle Löschen von ausgewählten Objekten zu verbieten. Für Object Locking sind die Optionen "Legal Hold" und "Retention" verfügbar. Legal Hold schützt ein Objekt davor gelöscht zu werden, bis der Legal Hold manuell wieder entfernt wurde. Retention schützt ein Objekt davor gelöscht zu werden, bis ein definierter Zeitraum abgelaufen ist. Mit Retention kann man zwischen dem Modus "Governance" und dem Modus "Compliance" wählen.

Alle Optionen im direkten Vergleich:

Betrifft die Sichtbarkeit-Einstellung alle Objekte innerhalb eines Buckets?

Wenn die Sichtbarkeit während der Bucket-Erstellung auf öffentlich gesetzt wird, wenden wir automatisch Zugriffs-Richtlinien an, die Lese-Zugriff auf alle Objekte innerhalb des Buckets erlauben.

Wenn Sie Ihre eigenen Zugriffs-Richtlinien anwenden, gibt es die Option, den Zugriff lediglich auf Objekte mit einem bestimmten Präfix zu erlauben (bucket_name/prefix/*) anstelle den Zugriff auf alle Objekte innerhalb des Buckets zu erlauben (bucket_name/*).

Wenn Sie einen Client wie zum Beispiel WinSCP verwenden, gibt es ggf. die Option, die Zugriffsrechte für einzelne Objekte individuell anzupassen. In diesem Fall kann es vorkommen, dass ein privater Bucket ein Objekt mit öffentlichen Zugriffsrechten enthält. Um böse Überraschungen zu vermeiden, sollten Sie die Sichtbarkeit eines einzelnen Objektes nur überlegt ändern und diese Änderungen entsprechend dokumentieren oder auf andere Weise nachverfolgen.

Wichtig: Es ist nicht empfohlen, die Sichtbarkeit zu öffentlich zu ändern, nachdem im Bucket bereits Daten hinzugefügt wurden. Wenn es dennoch notwendig ist, sollte man den Inhalt seines Buckets immer prüfen und sensible Daten löschen, bevor man die Sichtbarkeit auf öffentlich setzt.

Im besten Fall sollte man nur leere Buckets auf öffentlich setzen und die Daten erst anschließend hochladen.

Kann die Sichtbarkeit eines Buckets nachträglich geändert werden?

Ja das ist möglich. Die Sichtbarkeit können Sie entweder über die Cloud Console ändern oder über ein S3-kompatibles Tool.

Um die Sichtbarkeit über die Cloud Console anzupassen, wählen Sie Ihren Bucket aus und klicken Sie oben rechts auf "Aktionen". Klicken Sie anschließend auf "Bucket-Sichtbarkeit zurücksetzen" und setzen Sie die Sichtbarkeit entweder auf "Privat" oder "Öffentlich".

Die Sichtbarkeit eines Buckets ist automatisch "privat". Um Zugriffsrechte zu erlauben, verwendet Object Storage sogenannte Zugriffs-Richtlinien ("access policies"). Die Richtlinien werden in einer JSON-Datei bestimmt, welche anschließend auf den Bucket angewendet wird.

In anderen Worten, die Zugriffs-Richtlinien überschreiben automatisch die Standard-Sichtbarkeit, welche immer "privat" ist.

• Wenn die Bucket-Sichtbarkeit beim Erstellen des Buckets auf "öffentlich" gesetzt wird, erstellen wir die nötigen Zugriffs-Richtlinien für Sie und wenden diese direkt an.
• Wenn die Bucket-Sichtbarkeit beim Erstellen des Buckets auf "privat" gesetzt wird, werden keine Zugriffs-Richtlinien erstellt.

Die Sichtbarkeit nach dem Erstellen eines Buckets über ein S3-kompatibles Tool ändern:

• privat zu öffentlich: Fügen Sie Ihre eigenen Zugriffs-Richtlinien hinzu
• öffentlich zu privat: Löschen Sie die aktuell angewendeten Zugriffs-Richtlinien

Anstatt ein Bucket komplett privat oder komplett öffentlich zu nutzen, kann der Zugriff über die Zugriffs-Richtlinien eingeschränkt werden (z.B. nur bestimmte IPs).

Weitere Informationen über Zugriffs-Richtlinien und verfügbare Zugriffseinschränkungen finden Sie in den Amazon-Artikeln "Richtlinien und Berechtigungen in Amazon S3" und "Beispiele für Amazon S3 S3-Bucket-Richtlinien".

Der Befehl zum Anwenden der Zugriffs-Richtlinien unterscheidet sich je nach S3-kompatiblen Tool. Prüfen Sie für weitere Informationen daher die Dokumentation des Tools, das Sie verwenden (z.B. MinIO Client)

Kann ich auf einen privaten Bucket über einen Webbrowser zugreifen?

Wenn Sie einzelne Dateien aus Ihrem Bucket mit jemanden teilen möchten, der keine S3-Zugangsdaten besitzt, können Sie die URL zu dieser Datei mit Ihren S3-Zugangsdaten im Voraus signieren. Mit dieser sogenannten Presigned URL, kann jeder der möchte die Datei über einen Webbrowser oder über Tools wie curl oder wget herunterladen, ohne eigene S3-Zugangsdaten angeben zu müssen. Beim Erstellen der URL kann auch eine Zeit festgelegt werden, wie lange die URL gültig sein soll. Sobald der festgelegte Zeitpunkt überschritten wurde, ist es nicht mehr möglich über diese Presigned URL auf die Datei zuzugreifen.

Der Befehl zum Signieren der URL unterscheidet sich je nach S3-kompatiblen Tool (z.B. MinIO Client, AWS CLI, rclone). Mit dem MinIO Client, AWS CLI und S3cmd könnten Sie beispielsweise diese Befehle verwenden:

mc share download <alias-name>/<bucket-name>/<file-name> --expire 12h34m56s # hours, minutes, seconds (default 168h = 7 days)
s3cmd signurl s3://<bucket-name>/<file-name> 1765541532           # use https://epochconverter.com/ to convert the time
aws s3 presign s3://<bucket-name>/<file-name> --expires-in 60480  # number of seconds (default 3600 seconds = 1 hour)

Mit dem MinIO Client ist es möglich mehre Presigned URLs auf einmal zu erstellen, indem man keinen genauen Dateinamen angibt. Dies kann hilfreich sein, wenn man mehrere Dateien innerhalb desselben Ordners signieren möchte.

Beispiel:

<bucket-name>
├─ example-file-1
└─ example-file-2

mc share download <alias-name>/<bucket-name>

In diesem Beispiel werden zwei URLs signiert — eine für example-file-1 und eine für example-file-2.

Was sind Lifecycle-Policies und wie verwende ich sie?

Mit Lifecycle-Policies, ist es möglich:

• Einen bestimmten Zeitpunkt oder Zeitraum festlegen, nach welchem ein Objekt abgelaufen ist ("expired"). Zum Beispiel 30 Tage nach Erstellung. Abgelaufene Objekte werden automatisch gelöscht. Wenn Sie Lifecycle-Policies auf einen Bucket anwenden, werden die Regeln auf alle Objekte angewendet — bereits existierende und neue.

• Einen bestimmten Zeitraum festlegen, nach welchem "übriggebliebene" Objekte von einem (frühzeitig) abgebrochenen mehrteiligen Upload automatisch gelöscht werden. Ohne diese Lifecycle-Regel verbleiben diese Fragmente in Ihrem Bucket und verbrauchen Speicherplatz, bis Sie diese löschen.

Eine Anleitung, wie Sie Lifecycle-Policies auf einen Bucket anwenden, finden Sie in dem How-To "Lifecycle-Policies anwenden".

Beachten Sie, dass die Lifecycle-Regeln abhängig vom Versioning-Status unterschiedlich umgesetzt werden:

Eine Löschmarkierung ist ein leeres Objekt (besitzt keine Daten), das einen Key (Objekt-Name) und eine Versions-ID besitzt. Eine Löschmarkierung ist die aktuellste Version eines Objekts und wird behandelt als ob das Objekt tatsächlich gelöscht wäre.

Klicken Sie hier für ein Beispiel

Kein Versioning

• Objekt A
  Erstellt: vor 31 Tagen

• Objekt B
  Erstellt: vor 18 Tagen

Versioning aktiviert

• Objekt C latest
  Erstellt: vor 44 Tagen

• Objekt C noncurrent
  Erstellt: vor 94 Tagen
  Noncurrent seit: vor 44 Tagen

Versioning ausgesetzt

• Objekt D delete-marker
  Erstellt: vor 91 Tagen

• Objekt E latest
  Erstellt: vor 31 Tagen
  Versions-ID: null

In diesem Beispiel wird diese Lifecycle-Konfiguration angewendet:

{
 "Rules": [{
    "ID": "expiry",
    "Status": "Enabled",
    "Prefix": "",

    "Expiration": {
      "Days": 30
    },
    "NoncurrentVersionExpiration": {
      "NoncurrentDays": 15
    }
  },
  {
    "ID": "deletemarker",
    "Status": "Enabled",
    "Prefix": "",

    "Expiration": {
      "ExpiredObjectDeleteMarker": true
    }
  }]
}

Nachdem die Lifecycle-Konfiguration angewendet wurde, besitzt der Bucket folgende Objekte:

Kein Versioning

• Objekt B
  Erstellt: vor 18 Tagen

Versioning aktiviert

• Objekt C delete-marker
  Erstellt: vor 1 Tagen

• Objekt C noncurrent
  Erstellt: vor 44 Tagen
  Noncurrent seit: vor 1 Tagen

Versioning ausgesetzt