Objektversionierung

Zu den Beispielen

Damit Sie auch bereits gelöschte oder ersetzte 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.

Die Objektversionsverwaltung behält eine nicht aktuelle Objektversion bei, wenn die Live-Objektversion ersetzt oder gelöscht wird. 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.

Einleitung

Sie aktivieren die Objektversionierung für Buckets. Nach der Aktivierung:

  • Jedes Mal, wenn Sie ein Live-Objekt ersetzen oder löschen, speichert Cloud Storage ein nicht aktuelles Objekt, sofern Sie keine Generierungsnummer der Live-Version angeben.

    • Nicht aktuelle Versionen behalten den Namen des Objekts, werden jedoch durch ihre Generierungsnummer eindeutig identifiziert.

    • Nicht aktuelle Versionen werden nur in Anfragen angezeigt, die explizit eine Aufnahme anfordern.

  • Sie löschen Versionen von Objekten dadurch endgültig, dass Sie die Generierungsnummer in die Löschanfrage aufnehmen oder die Verwaltung des Objektlebenszyklus verwenden.

  • Nicht aktuelle Versionen von Objekten existieren unabhängig von einer Live-Version.

Wenn Sie die Objektversionierung deaktivieren, gilt Folgendes:

  • Der Bucket nimmt keine neuen nicht aktuellen Versionen von Objekten mehr an.

  • Objektversionen, die bereits im Bucket vorhanden sind, sind davon nicht betroffen.

Hinweise

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

  • Wichtig: Es gibt keine Standardbeschränkung für die Anzahl der Objektversionen, die Sie haben können. Jede nicht aktuelle Version eines Objekts wird zum gleichen Preis abgerechnet wie die Live-Version des Objekts.

    • Wenn Sie die Versionsverwaltung aktivieren, sollten Sie auch die Verwaltung des Objektlebenszyklus nutzen, um ältere Versionen eines Objekts nach einer bestimmten Zeit zu entfernen oder wenn neuere Versionen nicht mehr aktuell sind. Eine mögliche Einrichtung finden Sie im Beispiel für die Lebenszykluskonfiguration unter Objekte löschen.

Nicht aktuelle Objektmetadaten

Nicht aktuelle Versionen von Objekten haben eigene Metadaten, die sich von den Metadaten der Live-Version unterscheiden können. Am wichtigsten ist jedoch, dass nicht aktuelle Versionen ihre Access Control Lists behalten und nicht unbedingt dieselben Berechtigungen wie die Live-Version des Objekts haben.

Sowohl Live- als auch nicht aktuelle Versionen haben einen Satz an Metadaten. Dabei verweist nur die neueste Metagenerierungsnummer auf die Metadaten. Ältere Metagenerierungsnummern 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 einer nicht aktuellen Version eines 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.

Objektversionierungsbeispiel

Anhand des folgenden Beispiels wird gezeigt, was mit der Datei cat.jpg in einem Bucket mit aktivierter Objektversionsverwaltung geschieht, wenn Sie die Datei ersetzen, 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 Objektversionierung.

Sie beschließen, die Objektversionierung 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 nicht aktuellen Zustand. Die nicht aktuelle Version behält die bisherige Speicherklasse und deren Metadaten. Sie wird nur angezeigt, wenn Sie die nicht aktuellen Versionen auflisten. Mit normalen Listenbefehlen lässt sie sich nicht anzeigen. Die nicht aktuelle Version wird jetzt als cat.jpg#1360887697105000 bezeichnet.

Die neu hochgeladene Datei cat.jpg wird nun zur Live-Version 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 Live-Version des Bildes.

Jetzt löschen Sie cat.jpg. Damit ist die Version mit der Generierungsnummer 1360887759327000 nicht mehr aktuell. Jetzt enthält Ihr Bucket zwei nicht aktuelle Versionen von cat.jpg, aber keine Live-Version mehr. Sie können weiterhin mit der jeweiligen generation-Nummer auf die beiden nicht aktuellen 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 nicht aktueller Versionen von Objekten finden Sie unter Nicht aktuelle Objektversionen auflisten.

Sie deaktivieren die Objektversionierung.

Sie deaktivieren die Objektversionsverwaltung, um zu verhindern, dass Objekte nicht mehr aktuell sind. Vorhandene nicht aktuelle 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 nicht aktuellen Versionen wieder her.

Auch wenn die Objektversionsverwaltung deaktiviert ist, können Sie eine Kopie einer der vorhandenen nicht aktuellen Versionen erstellen, wodurch die Version wiederhergestellt wird. Anschließend hat Ihr Bucket drei cat.jpg-Versionen: die zwei nicht aktuellen Versionen und die Live-Version, die aus der Wiederherstellung stammt.

Referenz zur Objektversionsverwaltung

In dieser Referenztabelle wird gezeigt, was passiert, wenn Sie bestimmte Aktionen mit der Objektversionsverwaltung ausführen.

Status der Objektversionsverwaltung Aktion Folge
Deaktiviert
Ersetzen Sie dog.png durch eine neue Version. Die neue Version ersetzt die Live-Version und erhält eine neue Generierungsnummer. Die alte Live-Version wird endgültig gelöscht.
Kopieren Sie eine nicht aktuelle Version von dog.png über die Live-Version.1 Eine Kopie der nicht aktuellen Version ersetzt die Live-Version und erhält eine neue Generierungsnummer. Die alte Live-Version wird endgültig gelöscht.
Löschen Sie dog.png. dog.png wird endgültig gelöscht.
Löschen Sie eine nicht aktuelle Version von dog.png, indem Sie ihre Generierungsnummer angeben.1 Die nicht aktuelle Version wird endgültig gelöscht.
Aktiviert
Ersetzen Sie dog.png durch eine neue Version. Die neue Version ersetzt die Live-Version und erhält eine neue Generierungsnummer. Die alte Live-Version wird zu einer nicht aktuellen Version und behält dieselbe Generierungsnummer.
Kopieren Sie eine nicht aktuelle Version von dog.png aus der Live-Version. Eine Kopie der nicht aktuellen Version ersetzt die Live-Version und erhält eine neue Generierungsnummer. Die alte Live-Version wird zu einer nicht aktuellen Version und behält dieselbe Generierungsnummer.
Löschen Sie die Live-Version von dog.png, ohne die Generierungsnummer anzugeben. Die Live-Version wird zu einer nicht aktuellen Version und behält dieselbe Generierungsnummer bei.
Löschen Sie die Live-Version von dog.png, indem Sie die Generierungsnummer angeben. Die Live-Version wird endgültig gelöscht.
Löschen Sie eine aktuelle Version von dog.png, indem Sie deren Generierungsnummer angeben. Die nicht aktuelle Version wird endgültig gelöscht.

1 Eine nicht aktuelle Version ist möglicherweise vorhanden, wenn die Objektversionsverwaltung für den Bucket bereits aktiviert war.

Tipps

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

gsutil-Tool verwenden

  • Das gsutil-Tool bietet eine umfassende Unterstützung für die Arbeit mit versionierten Objekten und vereinfacht viele Aufgaben im Zusammenhang mit der Objektversionierung. Sie können beispielsweise mit nicht aktuellen Versionen von Objekten arbeiten, indem Sie # und die generation-Nummer an den Objektnamen anhängen. Weitere Informationen finden Sie auf dem Tab „gsutil” unter Mit versionierten Objekten arbeiten.

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.

Informationen zum Verhalten bei der Wiederherstellung von Dateien

  • Sie können eine nicht aktuelle Objektversion auf die aktuelle Live-Version zurücksetzen. Eine detaillierte Anleitung hierzu finden Sie unter Nicht aktuelle Objektversionen wiederherstellen.

    Wenn Sie dies bei aktivierter Objektversionierung tun und bereits eine Live-Version des Objekts in Ihrem Bucket vorhanden ist, ersetzt Cloud Storage die vorhandene Live-Version, behält sie aber als neue, nicht aktuelle Version bei. In einem solchen Fall enthält Ihr Bucket anschließend das ersetzte Objekt (jetzt nicht aktuell) und zwei Kopien des zuvor nicht aktuellen Objekts (eine Live-Kopie und eine weiterhin nicht aktuelle Kopie). Dadurch fallen Speichergebühren an. Um unnötige Kosten zu vermeiden, [löschen Sie die nicht aktuelle Version]12], mit der Sie die aktuelle Live-Kopie erstellt haben, oder konfigurieren Sie das Object Lifecyle Management so, dass nicht aktuelle Objekte entfernt werden, wenn sie die von Ihnen festgelegten Bedingungen erfüllen.

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 Live-Objekt oder ein nicht aktuelles 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 nicht aktuell 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. Dieses Feature ist nützlich, wenn Ihre Objekte aus mehreren Quellen aktualisiert werden und Sie gewährleisten müssen, dass Nutzer sie nicht versehentlich ersetzen.

  • 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 nicht aktuelle Versionen davon gibt. Wenn eine Liveversion des Objekts vorhanden ist, bricht Cloud Storage die Aktualisierung mit dem Statuscode 412 Precondition Failed ab.

Nächste Schritte