Blobversionsverwaltung

Du kannst Blob-Versionierung aktivieren, um frühere Versionen eines Objekts automatisch zu verwalten. Wenn du die Blob-Versionierung aktivierst, kannst du auf frühere Versionen eines Blobs zugreifen, um deine Daten wiederherzustellen, falls diese geändert oder gelöscht werden.

Empfohlene Datenschutzkonfiguration

Blob-Versionierung ist eine von mehreren Data Protection-Features. Die Wahl der richtigen Funktion oder Kombination von Funktionen hängt von Ihrer Arbeitsbelastung und davon, wovor Sie sich schützen möchten, ab. Um mehr über Microsoft Empfehlungen zum Datenschutz zu erfahren, siehe Datenschutzübersicht.

Versionen im Vergleich zu Schnappschüssen

Eine Blob-Version ähnelt einem Schnappschuss, aber die beiden unterscheiden sich darin, wie sie erstellt werden und wofür sie am besten geeignet sind. Eine Version ist automatisch und systemverwaltet: Azure Storage erstellt bei jedem Schreiben oder Löschen eine neue Version, wenn Blob-Versionierung aktiviert ist, ohne dass Anwendungs-Logik erforderlich ist. Ein Snapshot ist manuell und anwendungsgesteuert: Sie erstellen explizit eine Kopie zu einem bestimmten Zeitpunkt, wenn Ihre Anwendung eine benötigt.

Verwenden Sie Versionskontrolle, wenn Sie automatischen, kontinuierlichen Schutz gegen versehentliche oder böswillige Überschreibungen und Löschungen wünschen. Verwenden Sie Snapshots, wenn Sie absichtlich erstellte Point-in-Time-Kopien benötigen, wie zum Beispiel einen bekannten funktionsfähigen Prüfpunkt vor einem geplanten Update. Microsoft empfiehlt, keine Snapshots von Blockblobs mehr zu machen, sobald die Versionsführung aktiviert ist.

Funktionsweise der Blobversionsverwaltung

Eine Version erfasst den Zustand eines Blobs zu einem bestimmten Zeitpunkt. Jede Version hat eine Versions-ID. Wenn du Blob-Versionierung für ein Speicherkonto aktivierst, erstellt Azure Storage automatisch eine neue Version mit einer eindeutigen ID, sobald du einen Blob erstellst, und jedes Mal, wenn du den Blob änderst.

Eine Versions-ID kann die aktuelle Version oder eine vorherige Version identifizieren. Ein Blob kann jeweils nur eine aktuelle Version haben: seinen aktuellen Zustand. Ein Blob kann mehrere vorherige Versionen haben.

Wenn Sie ein neues Blob erstellen, ist nur eine einzelne Version (die aktuelle Version) vorhanden. Wenn Sie ein vorhandenes Blob ändern, wird die aktuelle Version zu einer vorherigen Version. Es wird eine neue Version erstellt, um den aktualisierten Zustand zu erfassen, und diese neue Version ist die aktuelle Version. Wenn Sie ein Blob löschen, wird die aktuelle Version des Blobs zu einer vorherigen Version, und es gibt keine aktuelle Version mehr. Alle vorherigen Versionen des Blobs bleiben erhalten.

Das folgende Diagramm zeigt, wie Versionen bei Schreiboperationen erstellt werden und wie eine vorherige Version zur aktuellen Version befördert werden kann:

Frühere Blob-Versionen sind unveränderlich, das heißt, man kann den Inhalt oder die Metadaten nicht verändern.

Versions-ID

Jede Blob-Version hat eine einzigartige Versions-ID. Der Wert der Versions-ID ist der Zeitstempel, als der Blob aktualisiert wurde. Du weist die Versions-ID zu, wenn du die Version erstellst.

Man kann eine bestimmte Version eines Blobs lesen oder löschen, indem man seine Versions-ID verwendet. Wenn du die Versions-ID nicht angibst, zielt die Operation auf die aktuelle Version ab.

Wenn Sie eine Schreiboperation ausführen, um einen Blob zu erstellen oder zu verändern, gibt Azure Storage in der Antwort den Header x-ms-version-id zurück. Dieser Header enthält die Versions-ID der aktuellen Version des Blobs, die durch die Schreiboperation erzeugt wurde.

Die Versions-ID bleibt während der gesamten Lebensdauer der Version gleich.

Versionsverwaltung für Schreibvorgänge

Wenn Sie die Blob-Versionierung aktivieren, erzeugt jede Schreiboperation für einen Blob eine neue Version. Zu den Schreibvorgängen zählen Put Blob, Put Block List, Copy Blob und Set Blob Metadata.

Wenn die Schreiboperation einen neuen Blob erzeugt, ist der resultierende Blob die aktuelle Version des Blobs. Wenn die Schreiboperation einen bestehenden Blob modifiziert, wird die aktuelle Version zu einer vorherigen Version, und eine neue aktuelle Version erfasst den aktualisierten Blob.

Die folgende Abbildung zeigt, wie sich Schreibvorgänge auf Blobversionen auswirken. Der Einfachheit halber zeigen die Diagramme in diesem Artikel die Versions-ID als einfachen ganzzahligen Wert an. In Wirklichkeit ist die Versions-ID ein Zeitstempel. Die aktuelle Version ist blau dargestellt, und vorherige Versionen werden grau dargestellt.

Wenn Sie die Blob-Versionierung für ein Speicherkonto aktivieren, lösen alle Schreibvorgänge für Blockblobs die Erstellung einer neuen Version aus, mit Ausnahme der Operation Put Block .

Bei Seiten- und Anfügeblobs wird die Versionserstellung nur durch einen Teil der Schreibvorgänge ausgelöst. Dazu zählen die Operationen:

• Platzieren eines Blobs
• Blockliste setzen
• Festlegen von Blobmetadaten
• Kopieren von Blobs

Die folgenden Operationen lösen nicht die Erstellung einer neuen Version aus:

• Put Page (Seitenblob)
• Append Block (Anfügeblob)

Um Änderungen aus diesen Operationen zu erfassen, machen Sie einen manuellen Snapshot. Weitere Informationen finden Sie unter Blob-Snapshots.

Alle Versionen eines Blobs müssen denselben Blob-Typ haben. Wenn ein Blob über mehrere Versionen verfügt, kann ein Blob eines Typs nicht durch einen Blob eines anderen Typs überschrieben werden, es sei denn, Sie löschen zuerst das Blob und alle zugehörigen Versionen.

Versionsverwaltung für Löschvorgänge

Wenn du die Delete Blob-Operation ohne Angabe einer Versions-ID ausführst, wird die aktuelle Version zur vorherigen Version, und es gibt keine aktuelle Version mehr. Die Operation bewahrt alle bestehenden vorherigen Versionen des Blobs.

Die folgende Abbildung zeigt die Auswirkung eines Löschvorgangs auf ein Blob mit Versionsangabe:

Wenn Sie eine bestimmte Version eines Blobs löschen möchten, müssen Sie für den Löschvorgang die ID der gewünschten Version angeben. Wenn Sie auch Blob Soft Delete für das Speicherkonto aktivieren, behält das System die Version bis zum Ablauf der Soft-Delete-Aufbewahrungszeit.

Wenn neue Daten in das Blob geschrieben werden, wird eine neue aktuelle Version des Blobs erstellt. Diese Aktion betrifft keine bestehenden Versionen, wie im folgenden Diagramm gezeigt.

Zugriffsebenen

Sie können jede beliebige Version eines Blockblobs (einschließlich der aktuellen Version) in eine andere Blobzugriffsebene verschieben, indem Sie den Vorgang Set Blob Tier aufrufen. Indem Sie ältere Versionen eines Blobs in die Ebene „Kalt“ oder „Archiv“ verschieben, können Sie von niedrigeren Kapazitätspreisen profitieren. Weitere Informationen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“, „Cold“ und „Archiv“ für Blobdaten.

Um den Prozess des Verschiebens von Blockblobs auf die entsprechende Zugriffsebene zu automatisieren, erstellen Sie eine Lebenszyklus-Management-Richtlinie, erstellen Sie eine Storage Actions-Aufgabe oder aktivieren Sie Smart Tier.

Aktivieren/Deaktivieren von Blobversionsverwaltung

Anleitungen zum Aktivieren oder Deaktivieren der Blob-Versionierung finden Sie unter Blob-Versionierung aktivieren und verwalten.

Durch Deaktivierung der Blobversionsverwaltung werden vorhandene Blobs, Versionen oder Momentaufnahmen nicht gelöscht. Wenn du die Blob-Versionierung deaktivierst, kannst du keine neuen Versionen erstellen.

Nachdem du die Versionierung deaktiviert hast, erzeugt die Änderung der aktuellen Version einen Blob, der keine Version ist. Alle nachfolgenden Aktualisierungen des Blobs überschreiben seine Daten, ohne den vorherigen Zustand zu speichern. Alle vorhandenen Versionen bleiben als vorherige Versionen erhalten.

Sie können Versionen auch nach dem Deaktivieren der Versionierung mithilfe der Versions-ID lesen oder löschen. Nach Deaktivierung von Versionsverwaltung können Sie auch die Versionen eines Blobs auflisten.

Die Objektreplikation basiert auf der Blobversionsverwaltung. Bevor Sie die Blobversionsverwaltung deaktivieren, müssen Sie alle Objektreplikationsrichtlinien für das Konto löschen. Weitere Informationen zur Objektreplikation finden Sie unter Objektreplikation für Blockblobs.

Die folgende Abbildung zeigt, wie durch das Ändern eines Blobs nach dem Deaktivieren der Versionsverwaltung ein Blob ohne Angabe zu einer Version erstellt wird. Alle vorhandenen Versionen, die dem Blob zugeordnet sind, bleiben erhalten.

Featureunterstützung

Die Unterstützung für dieses Feature kann durch aktivieren von Data Lake Storage Gen2, Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie Blob Storage Funktionalitätsunterstützung in Azure Storage Konten, um die Unterstützung für dieses Feature zu bewerten.

Die Blobversionsverwaltung ist für Standardkonten vom Typ „Allgemein v2“, für Premium-Blockblobkonten und für Legacy-Blobspeicherkonten verfügbar. Speicherkonten mit einem hierarchischen Namespace, der für die Verwendung mit Azure Data Lake Storage aktiviert ist, werden derzeit nicht unterstützt.

Version 2019-10-10 und höher der Azure Storage REST-API unterstützt BLOB-Versionsverwaltung.

Versionsmanagement wird nicht für Blobs unterstützt, die du mit Data Lake Storage APIs hochlädst.

Autorisieren von Vorgängen für Blobversionen

Sie können den Zugriff auf Blob-Versionen autorisieren, indem Sie eine der folgenden Ansätze verwenden:

• Verwenden Sie die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC), um einem Microsoft Entra-Sicherheitsprinzipal Berechtigungen zu gewähren. Microsoft empfiehlt die Verwendung von Microsoft Entra ID für höhere Sicherheit und Benutzerfreundlichkeit. Weitere Informationen zur Verwendung von Microsoft Entra ID mit Blob-Vorgängen finden Sie unter Autorisieren des Datenzugriffs in Azure Storage.
• Verwenden Sie eine Shared-Access-Signatur (SAS), um Zugriff auf Blob-Versionen zu delegieren. Geben Sie die Versions-ID für den signierten Ressourcentyp bv, der eine Blob-Version darstellt, an, um ein SAS-Token für Operationen auf einer bestimmten Version zu erstellen. Weitere Informationen zu freigegebenen Zugriffssignaturen finden Sie unter Gewähren Sie eingeschränkten Zugriff auf Azure-Speicherressourcen mit freigegebenen Zugriffssignaturen (SAS).
• Verwenden Sie die Zugriffsschlüssel des Kontos, um Operationen gegen Blob-Versionen mithilfe von Shared Key zu autorisieren. Weitere Informationen finden Sie unter Authentifizieren mit gemeinsam verwendetem Schlüssel.

Blobversionsverwaltung dient zum Schutz Ihrer Daten vor versehentlichem oder böswilligem Löschen. Um den Schutz zu verbessern, sind für das Löschen einer Blobversion spezielle Berechtigungen erforderlich. In den folgenden Abschnitten werden die Berechtigungen beschrieben, die zum Löschen einer Blobversion erforderlich sind.

Azure RBAC-Aktion zum Löschen einer BLOB-Version

Die folgende Tabelle zeigt, welche Azure RBAC-Aktionen das Löschen eines Blobs oder einer BLOB-Version unterstützen.

SAS-Parameter (Shared Access Signature)

Die signierte Ressource für eine Blobversion ist bv. Weitere Informationen finden Sie unter Erstellen einer Dienst-SAS oder Erstellen einer SAS für die Benutzerdelegierung.

In der folgenden Tabelle werden die Berechtigungen aufgeführt, die für eine SAS erforderlich sind, um eine Blobversion zu löschen.

Berücksichtigung der vorhandenen Auslastung

• Das Löschen eines Blobs gibt keinen Speicherplatz mehr frei. Wenn du die Versionierung aktivierst, entfernt das Löschen eines Blobs nicht seine Daten. Die aktuelle Version wird zu einer vorherigen Version, die bestehen bleibt und weiterhin Gebühren verursacht. Workloads, die auf Löschoperationen angewiesen sind, um Speicher zurückzugewinnen, verursachen weiterhin Gebühren, bis du diese Versionen explizit löschst.

• Überschreibungsintensive Arbeitslasten können viele Versionen erzeugen. Versionen bleiben bestehen, bis du sie explizit löschst. Diese Persistenz kann zu einer Ansammlung von Versionen führen, wenn man sie nicht richtig verwaltet. Um Kosten zu senken, sollten Blockänderungen auf Blockebene über verschiedene Versionen hinweg berechnet werden, wodurch die Kosten pro Version minimiert werden.

Feature-Interaktionen

Soft-Löschen

Blobversionsverwaltung und vorläufiges Löschen sind ein Bestandteil der empfohlenen Datenschutzkonfiguration für Speicherkonten. Weitere Informationen zu den Empfehlungen von Microsoft zum Datenschutz finden Sie in der Übersicht über den Datenschutz.

Überschreiben eines Blobs

Wenn Sie sowohl Blob-Versionierung als auch Blob-Soft-Delete für ein Speicherkonto aktivieren, erzeugt das Überschreiben eines Blobs automatisch eine neue vorherige Version, die den Zustand des Blobs vor der Schreiboperation widerspiegelt. Die neue Version wird nicht soft-gelöscht und bleibt bestehen, bis sie explizit gelöscht wird. Es werden keine vorläufig gelöschten Momentaufnahmen erstellt.

Löschen eines Blobs oder einer Version

Wenn du sowohl Versionsmanagement als auch Soft Delete für ein Speicherkonto aktivierst, wird beim Löschen eines Blobs die aktuelle Version des Blobs zu einer vorherigen Version. Die Operation erstellt keine neue Version oder irgendwelche vorläufig gelöschten Snapshots. Die Soft-Delete-Aufbewahrungsfrist gilt nicht für den gelöschten Blob.

Soft Delete bietet zusätzlichen Schutz beim Löschen von Blob-Versionen. Wenn Sie eine vorherige Version des Blobs löschen, wird diese Version vorläufig gelöscht. Die vorläufig gelöschte Version wird beibehalten, bis der Aufbewahrungszeitraum für vorläufig gelöschte Ressourcen abläuft, und wird dann endgültig gelöscht.

Wenn Sie eine vorherige Version eines Blobs löschen möchten, rufen Sie den Vorgang Delete Blob (Blob löschen) auf, und geben Sie die Versions-ID an.

Wiederherstellen einer vorläufig gelöschten Version

Verwenden Sie den Vorgang Undelete Blob, um während des Soft-Delete-Aufbewahrungszeitraums vorläufig gelöschte Versionen wiederherzustellen. Durch den Vorgang Undelete Blob (Blob wiederherstellen) werden immer alle vorläufig gelöschten Versionen des Blobs wiederhergestellt. Sie können nicht nur eine einzelne vorläufig gelöschte Version wiederherstellen.

Beim Wiederherstellen vorläufig gelöschter Versionen mithilfe des Vorgangs Undelete Blob wird keine Version zur aktuellen Version heraufgestuft. Stellen Sie zum Wiederherstellen der aktuellen Version zunächst alle vorläufig gelöschten Versionen wieder her, und verwenden Sie dann den Vorgang Copy Blob (Blob kopieren), um eine vorherige Version in eine neue aktuelle Version zu kopieren.

Nach Ablauf der Soft-Delete-Aufbewahrungszeit löscht das System dauerhaft alle soft-gelöschten Blob-Versionen.

Blob-Momentaufnahmen

Eine Blobmomentaufnahme ist eine schreibgeschützte Kopie eines Blobs, die zu einem bestimmten Zeitpunkt erstellt wurde. Blob-Snapshots und Blob-Versionen sind ähnlich, aber Sie oder Ihre Anwendung erstellen manuell einen Snapshot, während eine Blob-Version automatisch bei einer Schreib- oder Löschoperation erstellt wird, wenn Sie die Blob-Version für Ihr Speicherkonto aktivieren.

Momentaufnahme eines Blobs bei aktivierter Versionsverwaltung

Obwohl es nicht empfohlen wird, können Sie eine Momentaufnahme eines Blobs erstellen, das ebenfalls mit einer Version versehen ist. Wenn Sie die Anwendung nicht so aktualisieren können, dass keine Momentaufnahmen von Blobs erstellt werden, wenn Sie die Versionsverwaltung aktivieren, kann Ihre Anwendung sowohl Momentaufnahmen als auch Versionen unterstützen.

Wenn man einen Snapshot eines versionierten Blobs macht, erstellt man gleichzeitig mit dem Snapshot eine neue Version. Du erstellst auch eine neue aktuelle Version, wenn du einen Schnappschuss machst.

Die folgende Abbildung zeigt, was geschieht, wenn Sie eine Momentaufnahme eines Blobs mit Versionsangabe erstellen. In der Abbildung enthalten Blobversionen und Momentaufnahmen mit der Versions-ID 2 und 3 identische Daten.

Bekannte Einschränkungen

• Nicht unterstützt auf hierarchischen Namespace-Konten (Azure Data Lake Storage) oder für Blobs, die über Data Lake Storage APIs hochgeladen werden.

• Schützt nicht vor der Löschung von Containern oder Konten. Versionsmanagement funktioniert nur auf Blob-Ebene. Das Löschen eines Containers entfernt alle Blobs und deren Versionen. Die Wiederherstellung von dieser Löschung erfordert vorläufiges Löschen für Container. Der Schutz vor Kontolöschung erfordert eine Ressourcensperre.

• Versionen sind unveränderlich. Du kannst den Inhalt oder die Metadaten einer bestehenden Version nicht ändern.

• Alle Versionen eines Blobs müssen denselben Blob-Typ haben. Du kannst einen Blob nicht mit einem anderen Blob-Typ überschreiben, solange er vorherige Versionen hat, es sei denn, du löschst zuerst den Blob und alle seine Versionen.

• Nicht alle Schreibvorgänge erstellen eine Version. Beachten Sie die weiter oben in diesem Artikel stehenden Informationen, in denen die Ausnahmen beschrieben werden. Um diese Zustände zu erfassen, verwenden Sie einen manuellen Snapshot.

• Versionsverwaltung kann nicht deaktiviert werden, solange Objekt-Replikationsrichtlinien vorhanden sind auf dem Konto. Du musst zuerst alle Objekt-Replikationsrichtlinien löschen.

• Undelete Blob stellt alle vorläufig gelöschten Versionen eines Blobs wieder her, nicht nur eine einzelne. Man kann eine Version nicht selektiv wiederherstellen. Wiederherstellen macht eine Version nie zur aktuellen Version.

• Empfohlene Obergrenze von 1.000 Versionen pro Blob. Wird dieser Grenzwert überschritten, verschlechtert sich die Leistung der Blob-Auflistung.

Preise und Abrechnung

Wenn Sie Blob-Versionierung aktivieren, könnten zusätzliche Datenspeicherkosten anfallen. Wenn Sie Ihre Anwendung gestalten, berücksichtigen Sie, wie sich diese Gebühren summieren könnten, um die Kosten niedrig zu halten.

Du wirst für Blob-Versionen, wie Blob-Snapshots, mit dem gleichen Satz wie für aktive Daten abgerechnet. Wie du für Versionen abgerechnet wirst, hängt davon ab, ob du den Tarif explizit für die aktuelle oder frühere Version eines Blobs (oder Snapshots) festlegst. Weitere Informationen zu Blobebenen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“, „Cold“ und „Archiv“ für Blobdaten.

Wenn Sie die Stufe eines Blobs oder einer Version nicht ändern, werden Ihnen eindeutige Datenblöcke in diesem Blob, seinen Versionen und allen Snapshots abgerechnet. Weitere Informationen finden Sie unter Abrechnung, wenn die Blob-Ebene nicht explizit festgelegt ist.

Wenn du die Stufe eines Blobs oder einer Version änderst, wirst du für das gesamte Objekt abgerechnet, unabhängig davon, ob Blob und Version wieder in derselben Stufe landen. Weitere Informationen finden Sie unter Abrechnung bei explizit festgelegter Blob-Ebene.

Weitere Informationen zu Abrechnungsdetails für Blobmomentaufnahmen finden Sie unter Blobmomentaufnahmen.

Für Speicherkonten, die Smart Tier verwenden, zahlst du für Versionen und Snapshots in voller Inhaltslänge. Weitere Informationen finden Sie unter Optimieren der Kosten mit smarter Ebene.

Abrechnung, wenn Sie die Blobebene nicht explizit festlegen

Wenn du die Blob-Stufe für keine Versionen eines Blobs explizit festlegst, wirst du für einzigartige Blöcke oder Seiten in allen Versionen sowie für alle eventuellen Snapshots des Blobs berechnet. Für Daten, die zwischen Blob-Versionen geteilt werden, werden dir nur einmal berechnet. Wenn Sie einen Blob aktualisieren, unterscheiden sich die Daten in der aktuellen neuen Version von den in früheren Versionen gespeicherten Daten, sodass Ihnen die eindeutigen Daten pro Block oder Seite berechnet werden.

Wenn du einen Block innerhalb eines Blockblobs ersetzt, wirst du für diesen Block als eindeutiger Block abgerechnet. Diese Regel gilt auch dann, wenn der Block die gleiche Block-ID und dieselben Daten hat, wie er sie in der vorherigen Version hatte. Nachdem du den Block erneut committest, weicht er von seinem Gegenstück in der vorherigen Version ab, und du wirst für seine Daten abgerechnet. Die gleiche Regel gilt für eine Seite in einem Page Blob, die du mit identischen Daten aktualisierst.

Blob-Speicher hat keine Möglichkeit zu bestimmen, ob zwei Blöcke identische Daten enthalten. Jeder Block, den du hochlädst und committest, wird als einzigartig behandelt, auch wenn er dieselben Daten und dieselbe Block-ID hat. Da dir für eindeutige Blöcke berechnet wird, solltest du bedenken, dass das Aktualisieren eines Blobs bei aktivierter Versionierung zu zusätzlichen einzigartigen Blöcken und zusätzlichen Gebühren führt.

Wenn du Blob-Versionierung aktivierst, rufe Update-Operationen für Blockblobs auf, damit sie die möglichst kleine Anzahl von Blöcken aktualisieren. Die Schreibvorgänge, die eine differenzierte Steuerung von Blöcken ermöglichen, sind Put Block und Put Block List. Put Block stellt die Änderungen bereit, aber die eigentliche Änderung und Versionserstellung erfolgt über die Operation Put Block List. Die Put Blob-Operation hingegen ersetzt den gesamten Inhalt eines Blobs und kann daher zu zusätzlichen Gebühren führen.

Die folgenden Szenarien zeigen, wie sich Gebühren für einen Blockblob und seine Versionen ansammeln, wenn man die Blob-Stufe nicht explizit festlegt.

Szenario 1

In Szenario 1 ist eine frühere Version des Blobs vorhanden. Der Blob wird seit der Erstellung der Version nicht aktualisiert, sodass du nur für einzigartige Blöcke 1, 2 und 3 Gebühren bekommst.

Szenario 2

Im Szenario 2 wird ein Block (Block 3 im Diagramm) im Blob aktualisiert. Obwohl der aktualisierte Block die gleichen Daten und dieselbe ID enthält, ist er nicht identisch mit Block 3 in der vorherigen Version. Daher wird das Konto mit Gebühren für vier Blöcke belastet:

Szenario 3

In Szenario 3 wird der Blob aktualisiert, aber die Version nicht. Block 3 wird im aktuellen Blob durch Block 4 ersetzt, aber die vorherige Version zeigt weiterhin Block 3. Daher wird das Konto mit Gebühren für vier Blöcke belastet:

Szenario 4

Im Szenario 4 ist die aktuelle Version komplett aktualisiert und enthält keine ihrer ursprünglichen Blöcke. Daher wird das Konto für alle acht einzigartigen Blöcke belastet – vier in der aktuellen Version und vier zusammen in den beiden vorherigen Versionen. Dieses Szenario kann passieren, wenn man mit der Operation Put Blob in einen Blob schreibt, da dieser den gesamten Inhalt des Blobs ersetzt.

Abrechnung, wenn du explizit die Blobebene einstellst

Wenn Sie die Blob-Stufe explizit für ein Blob, eine Version oder eine Momentaufnahme festlegen, zahlen Sie für die gesamte Inhaltslänge des Objekts in der neuen Stufe, unabhängig davon, ob es Blöcke mit einem Objekt in der ursprünglichen Stufe gemeinsam nutzt. Du zahlst auch für die gesamte Inhaltslänge der ältesten Version in der ursprünglichen Tarifstufe. Für alle anderen früheren Versionen oder Momentaufnahmen, die in der ursprünglichen Ebene verbleiben, bezahlst du für die eindeutigen Blöcke, die von ihnen gemeinsam genutzt werden, wie unter Abrechnung, wenn die Blob-Ebene nicht explizit festgelegt ist beschrieben.

Verschieben eines Blobs auf eine neue Dienstebene

Die folgende Tabelle beschreibt das Abrechnungsverhalten für einen Blob oder eine Version, wenn Sie ihn auf eine neue Ebene verschieben.

¹Wenn es andere frühere Versionen oder Snapshots gibt, die nicht aus ihrer ursprünglichen Ebene verschoben wurden, werden diese Versionen oder Snapshots auf der Grundlage der Anzahl der darin enthaltenen eindeutigen Blöcke abgerechnet, wie unter Abrechnung, wenn die Blobebene nicht explizit festgelegt ist beschrieben.

Das folgende Diagramm zeigt, wie Objekte abgerechnet werden, wenn Sie einen versionierten Blob auf eine andere Ebene verschieben.

Du kannst das explizite Festlegen der Stufe für einen Blob, eine Version oder einen Snapshot nicht rückgängig machen. Wenn du einen Blob auf eine neue Stufe verschiebst und ihn dann wieder auf die ursprüngliche Stufe zurückversetzt, zahlst du für die volle Inhaltslänge des Objekts, selbst wenn es Blöcke mit anderen Objekten der ursprünglichen Stufe teilt.

Vorgänge, mit denen die Dienstebene eines Blobs, einer Version oder einer Momentaufnahme explizit festgelegt wird:

• Festlegen der Blobebene
• Put Blob mit der angegebenen Dienstebene
• Put Block List mit der angegebenen Dienstebene
• Copy Blob mit der angegebenen Dienstebene

Löschen eines Blobs mit aktiviertem vorläufigem Löschen

Wenn Sie das vorläufige Löschen für Blobs aktivieren, zahlen Sie für alle vorläufig gelöschten Entitäten zum gleichen Tarif wie für aktive Daten. Wenn du eine aktuelle Version löschst oder überschreibst, für die du explizit die Stufe festgelegt hast, zahlst du für alle vorherigen Versionen des vorläufig gelöschten Blobs in voller Inhaltslänge. Weitere Informationen darüber, wie Blob-Versionierung und Soft Delete zusammenarbeiten, finden Sie unter Feature-Interaktionen.

Überwachung und Problembehandlung

• Meine LCM-Richtlinie löscht keine Versionen wie erwartet: Das Alter einer Version basiert darauf, wann Sie ihre Daten ursprünglich geschrieben haben, nicht wann sie eine vorherige Version wurde. Die Uhr startet bei der Blob-Erstellung, nicht bei der Überschreibung, durch die der Blob in den Versionsverlauf verschoben wurde. Infolgedessen kann ein Blob, der lange aktuell geblieben ist, bevor er überschrieben wurde, eine vorherige Version erzeugen, die bereits zum Zeitpunkt ihrer Erstellung deinen daysAfterCreationGreaterThan Schwellenwert überschreitet und dadurch fast sofort gelöscht wird. Umgekehrt können Versionen kürzlich erstellter Blobs länger als erwartet bestehen bleiben. Zur Bestätigung sollten Sie den tatsächlichen Erstellungszeitstempel der Versionen überprüfen, anstatt davon auszugehen, dass er mit der Überschreibzeit übereinstimmt. Wenn Sie die Aufbewahrung darauf basieren müssen, wann eine Version nicht mehr aktuell wurde, oder eine detailliertere Kontrolle wünschen als die tagbasierten Schwellenwerte des Lebenszyklusmanagements erlauben, sollten Sie stattdessen Azure Storage Actions verwenden. Weitere Informationen finden Sie unter Speicheraktionen.

• Meine Rechnung ist nach dem Deaktivieren der Versionen immer noch hoch: Bestehende Versionen bleiben erhalten, bis man sie manuell löscht.

• Ich kann die Versionsführung nicht deaktivieren. Objektreplikation könnte auf dem Konto konfiguriert sein. Löschen Sie zuerst alle Objekt-Replikationsrichtlinien und deaktivieren Sie dann die Versionierung. Alternativ könnte eine Unveränderlichkeitsrichtlinie (WORM) für einen Container oder ein Konto vorhanden sein, bei dem die Versionsverwaltung nicht deaktiviert werden kann.

Weitere Informationen

• Aktivieren und Verwalten der Blobversionsverwaltung
• Erstellen einer Momentaufnahme eines Blobs
• Vorläufiges Löschen für Blobs
• Vorläufiges Löschen für Container