Objektversionsverwaltung

Damit Sie auch bereits gelöschte oder überschriebene Objekte abrufen können, bietet Cloud Storage die Möglichkeit der Objektversionsverwaltung. Auf dieser Seite werden die Funktion und die verfügbaren Optionen näher erklärt. Weitere Informationen zum Aktivieren und Nutzen der Objektversionsverwaltung finden Sie in Objektversionsverwaltung verwenden.

Aktivieren Sie Objektversionsverwaltung, um Ihre Cloud Storage-Daten vor dem Überschreiben oder versehentlichen Löschen zu schützen. Durch die Aktivierung werden die Speicherkosten erhöht. Dies können Sie jedoch teilweise ausgleichen, wenn Sie die Verwaltung des Objektlebenszyklus so konfigurieren, dass ältere Objektversionen gelöscht werden.

Einführung

Die Objektversionsverwaltung kann für Buckets aktiviert werden. Nach der Aktivierung erstellt Cloud Storage jedes Mal, wenn die Liveversion eines Objekts überschrieben oder gelöscht wird, eine archivierte Version des Objekts. Diese behält den Namen des Objekts, wird aber durch eine Generierungsnummer zweifelsfrei gekennzeichnet. Es wird zwar allen Objekten eine Generierungsnummer zugewiesen, aber archivierte Objekte müssen eine solche Nummer haben, um sie identifizieren zu können.

Wenn die Objektversionierung aktiviert ist, können Sie die archivierten Versionen eines Objekts auflisten, die Liveversion eines Objekts in einem älteren Zustand wiederherstellen oder ggf. eine archivierte Version endgültig löschen. Sie können die Versionierung für einen Bucket jederzeit aktivieren bzw. deaktivieren. Wenn Sie die Versionsverwaltung deaktivieren, bleiben die vorhandenen Objektversionen bestehen. Der Bucket sammelt jedoch keine neuen archivierten Versionen mehr.

Details zur Objektversionsverwaltung

Cloud Storage verwendet zwei Attribute, an denen sich die Version eines Objekts erkennen lässt. Ein Attribut bezeichnet die Version der Objektdaten, das andere die Version der Objektmetadaten. Diese Attribute sind bei jeder Version eines Objekts vorhanden, auch wenn die Objektversionierung nicht aktiviert ist; sie können als Vorbedingungen für bedingte Updates genutzt werden, um die Sortierung von Aktualisierungen zu erzwingen.

Cloud Storage kennzeichnet alle Objekte mit den folgenden Attributen:

Attribut Beschreibung
generation Gibt die Erzeugung von Inhalten (Daten) an und wird aktualisiert, wenn der Inhalt eines Objekts überschrieben wird. Zwischen den Generierungsnummern unabhängiger Objekte besteht keinerlei Zusammenhang, selbst wenn sich diese im selben Bucket befinden.
metageneration Gibt die Erzeugung von Metadaten an und erhöht sich jedes Mal, wenn die Metadaten einer bestimmten Inhaltsgenerierung aktualisiert werden. metageneration wird für jede neue generation eines Objekts auf 1 zurückgesetzt. Das Attribut metageneration ist ohne das Attribut generation bedeutungslos und sollte daher nur zusammen mit diesem verwendet werden. Es ist also sinnlos, die Metadatengenerierungen zweier Versionen zu vergleichen, die unterschiedliche Datengenerierungen haben.

Die Objektversionsverwaltung kann nicht für einen Bucket aktiviert werden, für den aktuell eine Aufbewahrungsrichtlinie festgelegt ist.

Archivierte Objektmetadaten

Archivierte Objekte haben eigene Metadaten, die sich von den Metadaten von Liveobjekten unterscheiden können. Am wichtigsten ist jedoch, dass archivierte Versionen ihre Zugriffssteuerungslisten behalten und nicht unbedingt dieselben Berechtigungen wie die Liveversion des Objekts haben.

Sowohl Liveobjekte als auch versionierte Objekte haben einen Satz an Metadaten. Dabei verweist nur die neueste Metagenerierungsnummer auf die Metadaten. Ältere Nummern können nicht verwendet werden, um auf Metadaten zuzugreifen, die in der Zwischenzeit geändert wurden.

Geben Sie in Ihrer Anfrage das Attribut generation an, um die Metadaten eines archivierten Objekts zu aktualisieren. Sie können die Vorbedingung "metageneration-match" verwenden, um eine sichere Read-Modify-Write-Semantik zu gewährleisten. Diese Vorbedingung bewirkt, dass das Update fehlschlägt, wenn die Metadaten, die Sie aktualisieren möchten, in dem Zeitraum zwischen dem Lesen der Metadaten und dem Senden des Updates geändert wurden.

Beispiel für die Objektversionsverwaltung

Anhand des folgenden Beispiels wird gezeigt, was mit der Datei cat.jpg in einem Bucket, für den die Objektversionsverwaltung aktiviert wurde, geschieht, wenn Sie die Datei überschreiben, aktualisieren oder löschen.

Sie laden ein neues Bild hoch.

Wenn Sie cat.jpg in Cloud Storage hochladen, erhält die Datei je eine Nummer für generation und metageneration. In diesem Beispiel lautet die Generierungsnummer 1360887697105000. Da das Objekt neu ist, hat es die metageneration-Nummer 1.

cat.jpg erhält generation- und metageneration-Nummern, obwohl die Objektversionsverwaltung nicht aktiviert ist. Sie können diese Nummern mit dem Befehl stat in gsutil anzeigen. Eine Anleitung dazu finden Sie unter Objektmetadaten anzeigen.

Sie aktivieren die Objektversionsverwaltung.

Sie beschließen, die Objektversionsverwaltung für den Bucket zu aktivieren. Dies wirkt sich nicht auf die generation- und metageneration-Nummern von cat.jpg aus.

Sie ändern die Metadaten des Bildes.

Sie aktualisieren die Metadaten für cat.jpg durch Hinzufügen von benutzerdefinierten Metadaten, in diesem Fall color:black. Durch die Aktualisierung der Metadaten erhöht sich der metageneration-Wert von cat.jpg von 1 auf 2. Da das Objekt selbst unverändert bleibt, speichert Cloud Storage weiterhin nur eine Version von cat.jpg und diese behält die generation-Nummer 1360887697105000.

Sie laden eine neue Version des Bildes hoch.

Sie laden eine neue Version von cat.jpg in den Cloud Storage-Bucket hoch. Dabei versetzt die Objektversionsverwaltung das bestehende Objekt cat.jpg in einen archivierten Zustand. Die archivierte Version behält die bisherige Speicherklasse und ihre Metadaten. Sie wird nur angezeigt, wenn Sie die archivierten Versionen auflisten. Mit normalen Listenbefehlen lässt sie sich nicht anzeigen. Die archivierte Version wird jetzt als cat.jpg#1360887697105000 bezeichnet.

Die neu hochgeladene Datei cat.jpg wird nun zur Liveversion des Objekts. Diese neue cat.jpg-Datei bekommt ihre eigene generation-Nummer, die in diesem Beispiel 1360887759327000 lautet. Außerdem erhält sie eigene Metadaten und die metageneration-Nummer 1, d. h. sie hat nicht die Metadaten color:black, sofern Sie sie nicht angeben. Wenn Sie auf cat.jpg, zugreifen oder die Datei ändern, wird mit dieser Version gearbeitet. Sie können auf diese Version von cat.jpg mithilfe ihrer generation-Nummer verweisen. Im gsutil-Tool würden Sie sie zum Beispiel mit cat.jpg#1360887759327000 angeben.

Sie löschen die Liveversion des Bildes.

Jetzt löschen Sie cat.jpg. Damit wird die Version mit der Generierungsnummer 1360887759327000 archiviert. Jetzt enthält Ihr Bucket zwei archivierte Versionen von cat.jpg, aber keine Liveversion mehr. Sie können weiterhin mit der jeweiligen generation-Nummer auf die beiden archivierten Versionen verweisen, aber wenn Sie versuchen, ohne generation-Nummer auf cat.jpg zuzugreifen, schlägt dies fehl.

Ebenso wird cat.jpg bei einer normalen Objektauflistung des Buckets nicht als Objekt in diesem Bucket zurückgegeben. Weitere Informationen zum Auflisten archivierter Versionen von Objekten finden Sie unter Archivierte Objektversionen auflisten.

Sie deaktivieren die Objektversionsverwaltung.

Sie deaktivieren die Objektversionsverwaltung, wodurch keine Objekte mehr archiviert werden. Vorhandene archivierte Versionen von Objekten verbleiben jedoch in Cloud Storage. Obwohl die Objektversionsverwaltung deaktiviert wurde, bleiben cat.jpg#1360887697105000 und cat.jpg#1360887759327000 im Bucket gespeichert, bis Sie die Versionen löschen – entweder manuell oder über die Verwaltung des Objektlebenszyklus.

Sie stellen eine der archivierten Versionen wieder her.

Auch wenn die Objektversionsverwaltung deaktiviert ist, können Sie eine der vorhandenen archivierten Versionen wiederherstellen, indem Sie eine Kopie davon erstellen. Benennen Sie hierfür einfach die Kopie, die zu cat.jpg wird. Anschließend hat Ihr Bucket drei cat.jpg-Versionen: die zwei archivierten Versionen und die Liveversion, die durch das Erstellen einer Kopie entstanden ist.

Tipps

In diesem Abschnitt erhalten Sie Tipps, wie Sie die Objektversionierung effektiver einsetzen können.

gsutil nutzen

  • Das gsutil-Tool bietet eine umfassende Unterstützung für die Arbeit mit versionierten Objekten und vereinfacht viele Aufgaben im Zusammenhang mit der Objektversionsverwaltung. So können Sie zum Beispiel mit archivierten Versionen von Objekten arbeiten. Dazu hängen Sie # und die generation-Nummer an den Objektnamen an. Weitere Informationen zur Verwendung von "gsutil" für die Objektversionsverwaltung finden Sie unter Objektversionsverwaltung und Gleichzeitigkeitserkennung.

ETags vermeiden

  • Für bedingte Updates können Sie anstelle von ETags die generation- und metageneration-Nummern verwenden. Mit der kombinierten Verwendung von generation- und metageneration-Nummern haben Sie die Möglichkeit, alle Objektaktualisierungen einschließlich Metadatenänderungen zu erfassen. Dies ist wesentlich zuverlässiger als ETags.

Löschen und Wiederherstellen von Dateien verstehen

  • Sie können eine archivierte Objektversion in die aktuelle Liveversion kopieren. Eine detaillierte Anleitung zum Kopieren archivierter Objekte finden Sie unter Archivierte Objektversionen kopieren.

    Wenn Sie dies bei aktivierter Objektversionierung tun und bereits eine Liveversion des Objekts in Ihrem Bucket vorhanden ist, überschreibt Cloud Storage diese, erstellt jedoch auch eine neue archivierte Version des überschriebenen Objekts. In einem solchen Fall enthält Ihr Bucket anschließend das überschriebene Objekt (jetzt archiviert) und zwei Kopien des zuvor archivierten Objekts (eine Livekopie und eine noch archivierte Kopie). Dadurch fallen Speichergebühren an. Um unnötige Kosten zu vermeiden, sollten Sie die archivierte Version, mit der Sie die aktuelle Livekopie erstellt haben, löschen.

  • Wenn Sie eine Löschanfrage ohne Angabe einer Generierungsnummer senden, archiviert Cloud Storage das aktuelle Liveobjekt. Bei zukünftigen Anfragen ohne Versionsangabe wird es dann nicht mehr ausgegeben.

  • Wenn Sie eine Löschanfrage mit einer generation-Nummer senden, die dem aktuellen Liveobjekt entspricht, löscht Cloud Storage das Objekt, ohne eine archivierte Kopie zu erstellen.

  • Wenn Sie ein archiviertes Objekt löschen, entfernt Cloud Storage diese Version des Objekts dauerhaft.

generation-match-Vorbedingungen beim Mutieren von Liveversionen von Objekten verwenden

  • Wenn Sie Generierungsnummern verwenden, sind Anfragen dann erfolgreich, wenn es ein Objekt mit diesem Namen und dieser Generierungsnummer gibt, unabhängig davon, ob es sich um ein Liveobjekt oder ein archiviertes Objekt handelt. Wenn kein solches Objekt vorhanden ist, gibt Cloud Storage die Meldung 404 Not Found aus.

  • Wenn Sie generation-match-Vorbedingungen verwenden, sind Anfragen nur dann erfolgreich, wenn die Liveversion des angefragten Objekts die angegebene Generierungsnummer hat. Wenn kein solches Objekt vorhanden oder es archiviert ist, gibt Cloud Storage die Meldung 412 Precondition Failed aus.

  • Die gleichzeitige Verwendung einer generation-match-Vorbedingung und einer Generierungsnummer im Objektnamen sollte vermieden werden. Wenn Sie beide einsetzen und die Nummern übereinstimmen, ist die Verwendung der Vorbedingung redundant. Wenn die Nummern nicht übereinstimmen, schlägt die Anfrage immer fehl.

  • Wenn Sie mehrere Mutationsanfragen mit einer generation-match-Vorbedingung gleichzeitig senden, sorgt die Strong Consistency von Cloud Storage dafür, dass nur eine dieser Anfragen ausgeführt wird. Diese Funktion ist hilfreich, wenn Ihre Objekte aus verschiedenen Quellen aktualisiert werden und Sie gewährleisten möchten, dass Nutzer sie nicht versehentlich überschreiben.

  • Wird die generation-match-Vorbedingung beim Hochladen eines Objekts auf 0 gesetzt, führt Cloud Storage die angegebene Anfrage nur aus, wenn es keine Liveversion des Objekts gibt. Wenn Sie beispielsweise mit der XML API eine PUT-Anfrage ausführen, um ein neues Objekt mit dem Header x-goog-if-generation-match:0 zu erstellen, ist die Anfrage erfolgreich, wenn das Objekt nicht existiert oder es nur archivierte Versionen davon gibt. Wenn eine Liveversion des Objekts vorhanden ist, bricht Cloud Storage die Aktualisierung mit dem Statuscode 412 Precondition Failed ab.