Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Eine WORM-Richtlinie (Write Once, Read Many) auf Versionsebene ist eine Art von Unveränderlichkeitsrichtlinie, die auf Konto-, Container- oder Versionsebene festgelegt werden kann. Weitere Informationen zum unveränderlichen Speicher für Azure Blob Storage finden Sie unter Speichern geschäftskritischer Blob-Daten mit unveränderlichem Speicher im Zustand "Einmal schreiben, vielfach lesen" (WORM).
Verfügbarkeit
Richtlinien für die Unveränderlichkeit auf Versionsebene (VLW) werden auf Kontoebene für neue Konten und auf Container- und BLOB-Ebene für neue und vorhandene Konten/Container unterstützt. Diese Richtlinien werden sowohl für Universal v2 als auch für Premium-Blockblob-Konten unterstützt. Dieses Feature wird für hierarchische Namespacekonten nicht unterstützt.
Versionsabhängigkeit
Richtlinien auf Versionsebene erfordern, dass die Blob-Versionsverwaltung für das Speicherkonto aktiviert ist. Informationen zum Aktivieren der Blobversionsverwaltung finden Sie unter Aktivieren und Verwalten der Blobversionsverwaltung (Vorschau). Denken Sie daran, dass die Aktivierung der Versionsverwaltung möglicherweise Auswirkungen auf die Abrechnung hat. Weitere Informationen finden Sie im Abschnitt "Preise und Abrechnung" für blob-Versionsverwaltung.
Nachdem die Versionsverwaltung aktiviert wurde, ist diese Version, wenn ein Blob zum ersten Mal hochgeladen wird, die aktuelle Version des Blobs. Jedes Mal, wenn das Blob überschrieben wird, wird eine neue Version erstellt, die den vorherigen Zustand des Blobs speichert. Wenn Sie die aktuelle Version eines Blobs löschen, wird die aktuelle Version zu einer früheren Version und wird bis zum expliziten Löschen beibehalten. Eine vorherige BLOB-Version hat die zeitbasierte Aufbewahrungsrichtlinie, die galt, als die aktuelle Version zu einer vorherigen Version wurde.
Wenn eine Standardrichtlinie für das Speicherkonto oder den Container wirksam ist, erbt die neue aktuelle Version die Standardrichtlinie für das Konto oder den Container, wenn ein Überschreibvorgang eine frühere Version erstellt.
Jede Version kann nur eine zeitbasierte Aufbewahrungsrichtlinie konfiguriert haben. Eine Version kann auch eine gesetzliche Aufbewahrungspflicht konfiguriert haben.
Informationen zum Konfigurieren zeitbasierter Aufbewahrungsrichtlinien auf Versionsebene finden Sie unter Konfigurieren von Unveränderlichkeitsrichtlinien für BLOB-Versionen.
Aktivierung und Richtlinienfestlegung
Die Verwendung unveränderlicher Richtlinien mit WORM auf Versionsebene ist ein zweistufiger Prozess. Aktivieren Sie zunächst die Unveränderlichkeit auf Versionsebene. Anschließend können Sie Richtlinien für die Unveränderlichkeit auf Versionsebene festlegen.
Um eine Richtlinie auf Speicherkontoebene festzulegen, müssen Sie zuerst den WORM auf Versionsebene für das Speicherkonto aktivieren. Sie können dies nur zum Zeitpunkt der Kontoerstellung tun. Es gibt keine Option, WORM auf Versionsebene für bereits vorhandene Konten zu aktivieren.
Um eine Richtlinie auf Containerebene festzulegen, müssen Sie zuerst den WORM auf Versionsebene entweder für das Konto ODER für den Container aktivieren.
Wenn Sie beabsichtigen, WORM auf Versionsebene für einen Container zu aktivieren, empfiehlt Microsoft, sie zur Containererstellungszeit zu aktivieren. Sie können jedoch einen nicht auf Versionsebene aktivierten WORM-Container zu einem WORM-Container auf Versionsebene migrieren. Wenn Sie sich entscheiden, einen Container nicht zu migrieren, können Sie weiterhin eine WORM-Richtlinie auf Containerebene für diesen Container festlegen, aber die Option zum Festlegen von Richtlinien auf Blobebene steht für diesen Container nicht zur Verfügung.
Um eine Richtlinie auf Blobebene festzulegen, müssen Sie WORM auf Versionsebene entweder für das Konto oder den Container aktivieren. Es gibt keine Möglichkeit, WORM auf Versionsebene auf Blobebene zu aktivieren. Es muss vererbt werden.
Migration
Vorhandene Container können die Unveränderlichkeit auf Versionsebene unterstützen, müssen sich jedoch zuerst einem Migrationsprozess unterziehen. Dieser Vorgang kann einige Zeit in Anspruch nehmen. Nach der Aktivierung kann die WORM-Unterstützung auf Versionsebene für diesen Container nicht entfernt werden. Sie können 10 Container gleichzeitig pro Speicherkonto migrieren. Die Zeit für die Migration hängt in erster Linie von der Menge der Blobs im Container ab. Container mit einer großen Anzahl von Blobs benötigen viel mehr Zeit für die Migration. Weitere Informationen zum Migrieren eines Containers zur Unterstützung der Unveränderlichkeit auf Versionsebene finden Sie unter Migrieren eines vorhandenen Containers zur Unterstützung der Unveränderlichkeit auf Versionsebene.
Konfigurieren einer Richtlinie für die aktuelle Version
Nachdem Sie die Unterstützung für die Unveränderlichkeit auf Versionsebene für ein Speicherkonto oder einen Container aktiviert haben, haben Sie die Möglichkeit, eine standardzeitbasierte Aufbewahrungsrichtlinie für das Konto oder den Container zu konfigurieren. Wenn Sie eine zeitbasierte Standardaufbewahrungsrichtlinie für das Konto oder den Container konfigurieren und dann ein Blob hochladen, erbt das Blob diese Standardrichtlinie. Sie können auch die Standardrichtlinie für ein beliebiges Blob beim Hochladen außer Kraft setzen, indem Sie eine benutzerdefinierte Richtlinie für dieses Blob konfigurieren.
Wenn die standardmäßige zeitbasierte Aufbewahrungsrichtlinie für das Konto oder den Container entsperrt ist, verfügt die aktuelle Version eines Blobs, das die Standardrichtlinie erbt, auch über eine entsperrte Richtlinie. Nachdem ein einzelnes Blob hochgeladen wurde, können Sie den Aufbewahrungszeitraum für die Richtlinie für die aktuelle Version des Blobs verkürzen oder verlängern oder die aktuelle Version löschen. Sie können die Richtlinie auch für die aktuelle Version sperren, auch wenn die Standardrichtlinie für das Konto oder den Container entsperrt bleibt.
Wenn die standardmäßige zeitbasierte Aufbewahrungsrichtlinie für das Konto oder den Container gesperrt ist, verfügt die aktuelle Version eines Blobs, das die Standardrichtlinie erbt, auch über eine gesperrte Richtlinie. Wenn Sie die Standardrichtlinie jedoch außer Kraft setzen, wenn Sie ein Blob hochladen, indem Sie eine Richtlinie nur für dieses Blob festlegen, bleibt die Richtlinie dieses Blobs entsperrt, bis Sie es explizit sperren. Wenn die Richtlinie für die aktuelle Version gesperrt ist, können Sie das Aufbewahrungsintervall erweitern, aber Sie können die Richtlinie nicht löschen oder das Aufbewahrungsintervall verkürzen.
Wenn keine Standardrichtlinie für das Speicherkonto oder den Container konfiguriert ist, können Sie ein Blob entweder mit einer benutzerdefinierten Richtlinie oder ohne Richtlinie hochladen.
Wenn die Standardrichtlinie für ein Speicherkonto oder container geändert wird, bleiben Richtlinien für Objekte innerhalb dieses Containers unverändert, auch wenn diese Richtlinien von der Standardrichtlinie geerbt wurden.
In der folgenden Tabelle sind die verschiedenen Optionen zum Festlegen einer zeitbasierten Aufbewahrungsrichtlinie für ein BLOB beim Upload aufgeführt:
| Status der Standardrichtlinie für Konto oder Container | Laden Sie ein Blob mit der Standardrichtlinie hoch | Ein Blob mit einer benutzerdefinierten Richtlinie hochladen | Hochladen eines Blobs ohne Richtlinie |
|---|---|---|---|
| Standardrichtlinie für Konto oder Container (entsperrt) | Blob wird mit entsperrter Standardrichtlinie hochgeladen | Blob wird mit entsperrter benutzerdefinierter Richtlinie hochgeladen | Blob wird ohne Richtlinie hochgeladen |
| Standardrichtlinie für Konto oder Container (gesperrt) | Blob wird mit gesperrter Standardrichtlinie hochgeladen | Blob wird mit entsperrter benutzerdefinierter Richtlinie hochgeladen | Blob wird ohne Richtlinie hochgeladen |
| Keine Standardrichtlinie für ein Konto oder einen Container | Nicht verfügbar | Blob wird mit entsperrter benutzerdefinierter Richtlinie hochgeladen | Blob wird ohne Richtlinie hochgeladen |
Konfigurieren einer Richtlinie für eine vorherige Version
Wenn die Versionsverwaltung aktiviert ist, erstellt ein Schreib- oder Löschvorgang in einem Blob eine neue vorherige Version dieses Blobs, die den Blobstatus vor dem Vorgang speichert. Standardmäßig verfügt eine frühere Version über die zeitbasierte Aufbewahrungsrichtlinie, die für die aktuelle Version in Kraft war, sofern vorhanden, als die aktuelle Version zu einer früheren Version wurde. Die neue aktuelle Version erbt die Richtlinie für den Container, wenn es eine gibt.
Wenn die von einer früheren Version geerbte Richtlinie entsperrt ist, kann das Aufbewahrungsintervall gekürzt oder verlängert werden, oder die Richtlinie kann gelöscht werden. Die Richtlinie für eine frühere Version kann auch für diese Version gesperrt werden, auch wenn die Richtlinie für die aktuelle Version entsperrt ist.
Wenn die von einer früheren Version geerbte Richtlinie gesperrt ist, kann das Aufbewahrungsintervall verlängert werden. Die Richtlinie kann nicht gelöscht werden, und das Aufbewahrungsintervall kann nicht verkürzt werden. Wenn für die aktuelle Version keine Richtlinie konfiguriert ist, erbt die vorherige Version keine Richtlinie.
Sie können eine benutzerdefinierte Richtlinie für die Version konfigurieren. Wenn die Richtlinie für eine aktuelle Version geändert wird, bleiben die Richtlinien für vorhandene frühere Versionen unverändert, auch wenn die Richtlinie von einer aktuellen Version geerbt wurde.
Löschen
Sobald ein Konto oder Container für eine unveränderliche Richtlinie aktiviert ist, kann es erst gelöscht werden, wenn es leer ist. Die Hauptsache ist, dass es egal ist, ob eine unveränderliche Richtlinie für ein WORM-Konto oder einen Container auf Versionsebene festgelegt wurde, es ist wichtig, ob sie für eine Richtlinie aktiviert ist. Sobald dies der Vorgang ist, muss das Konto oder der Container leer sein, um gelöscht zu werden.
Szenarien
| Szenario | Unzulässige Vorgänge | Blobschutz | Containerschutz | Kontoschutz |
|---|---|---|---|---|
| Eine Blobversion wird durch eine aktive Aufbewahrungsrichtlinie und/oder eine Richtlinie zur Aufbewahrung für juristische Zwecke geschützt | Blob löschen, Blob-Metadaten festlegen und Seite ablegen | Die Blobversion kann nicht gelöscht werden. Benutzermetadaten können nicht geschrieben werden. Das Überschreiben eines Blobs mit Put Blob, Put Block List oder Copy Blob erstellt eine neue Version1. |
Beim Löschen des Containers tritt ein Fehler auf, wenn mindestens ein Blob im Container vorhanden ist (unabhängig davon, ob die Richtlinie gesperrt ist oder nicht). | Das Löschen des Speicherkontos schlägt fehl, wenn mindestens ein Container über aktivierten unveränderlichen Speicher auf Versionsebene verfügt oder der unveränderliche Speicher für das gesamte Konto aktiviert ist. |
| Eine Blobversion wird durch eine abgelaufene Aufbewahrungsrichtlinie geschützt, und es ist keine Richtlinie zur Aufbewahrung für juristische Zwecke in Kraft | Festlegen von Blob-Metadaten und Hinzufügen einer Seite | Eine Blobversion wird durch eine abgelaufene Aufbewahrungsrichtlinie geschützt, und es ist keine Richtlinie zur Aufbewahrung für juristische Zwecke in Kraft | Die Blob-Version kann gelöscht werden. Das Überschreiben eines Blobs mit Put Blob, Put Block List oder Copy Blob erstellt eine neue Version1. |
Das Löschen eines Speicherkontos schlägt fehl, wenn mindestens ein Container vorhanden ist, der eine BLOB-Version mit einer gesperrten zeitbasierten Aufbewahrungsrichtlinie enthält. Entsperrte Richtlinien bieten keinen Schutz vor Löschvorgängen. |
1 Blob-Versionen sind für Inhalte immer unveränderlich. Wenn die Versionsverwaltung für das Speicherkonto aktiviert ist, erstellt ein Schreibvorgang in ein Block-BLOB eine neue Version, mit Ausnahme des Put Block-Vorgangs.
Grenzen
In einem Konto können maximal 10 000 Container mit eindeutigen zeitbasierten Aufbewahrungsrichtlinien eingerichtet werden. Sie können jedoch eine Richtlinie auf Kontoebene festlegen, die von mehr als 10 000 Containern geerbt wird.