Blobversionsverwaltung

  • Artikel

Sie können die Blob Storage-Versionsverwaltung aktivieren, um frühere Versionen eines Objekts automatisch zu verwalten. Wenn die Blobversionsverwaltung aktiviert ist, können Sie auf frühere Versionen eines Blobs zugreifen, um Daten wiederherzustellen, wenn diese geändert oder gelöscht wurden.

Die Blobversionsverwaltung ist Teil einer umfassenden Datenschutzstrategie für Blobdaten. Microsoft empfiehlt die Aktivierung folgender Datenschutzfeatures, um einen optimalen Schutz Ihrer Blobdaten zu gewährleisten:

Weitere Informationen zu den Datenschutzempfehlungen von Microsoft finden Sie in der Datenschutzübersicht.

Achtung

Nachdem Sie die Blobversionsverwaltung für ein Speicherkonto aktiviert haben, führt jeder Schreibvorgang in ein Blob in diesem Konto zur Erstellung einer neuen Version. Aus diesem Grund kann die Aktivierung der Blobversionsverwaltung zu zusätzlichen Kosten führen. Wenn Sie Kosten minimieren möchten, verwenden Sie eine Richtlinie zur Lebenszyklusverwaltung, damit alte Versionen automatisch gelöscht werden. Weitere Informationen zur Lebenszyklusverwaltung finden Sie unter Optimieren der Kosten durch Automatisieren der Azure Blob Storage-Zugriffsebenen.

Funktionsweise der Blobversionsverwaltung

Eine Version erfasst den Zustand eines Blobs zu einem bestimmten Zeitpunkt. Jede Version wird durch eine Versions-ID identifiziert. Wenn die Blobversionsverwaltung für ein Speicherkonto aktiviert ist, wird von Azure Storage bei der ursprünglichen Erstellung sowie bei jeder Änderung des Blobs automatisch eine neue Version mit einer eindeutigen ID erstellt.

Eine Versions-ID kann die aktuelle Version oder eine vorherige Version identifizieren. Ein Blob kann immer nur eine aktuelle Version 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.

Die folgende Abbildung zeigt, wie Versionen bei Schreibvorgängen erstellt werden und wie eine vorherige Version zur aktuellen Version heraufgestuft werden kann:

Diagram showing how blob versioning works

Blobversionen sind unveränderlich. Inhalte oder Metadaten einer vorhandenen Blobversion können nicht geändert werden.

Wenn eine große Anzahl von Versionen pro Blob vorhanden ist, kann sich die Latenz bei Auflistungsvorgängen für Blobs erhöhen. Microsoft empfiehlt die Beibehaltung von weniger als 1000 Versionen pro Blob. Sie können die Lebenszyklusverwaltung verwenden, um alte Versionen automatisch zu löschen. Weitere Informationen zur Lebenszyklusverwaltung finden Sie unter Optimieren der Kosten durch Automatisieren der Azure Blob Storage-Zugriffsebenen.

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, die für die Verwendung mit Azure Data Lake Storage Gen2 aktiviert sind, werden derzeit nicht unterstützt.

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

Wichtig

Blobversionsverwaltung kann Ihnen nicht bei der Wiederherstellung nach dem versehentlichen Löschen eines Speicherkontos oder Containers helfen. Um das versehentliche Löschen des Speicherkontos zu verhindern, konfigurieren Sie eine Sperre für die Speicherkontoressource. Weitere Informationen zum Sperren eines Speicherkontos finden Sie unter Anwenden einer Azure Resource Manager-Sperre auf ein Speicherkonto.

Versions-ID

Jede Blobversion wird durch eine eindeutige Versions-ID identifiziert. Der Wert der Versions-ID ist der Zeitstempel der Blobaktualisierung. Die Versions-ID wird zum Zeitpunkt der Erstellung der Version zugewiesen.

Sie können Lese- oder Löschvorgänge für eine bestimmte Version eines Blobs durchführen, indem Sie die zugehörige Versions-ID angeben. Ohne Angabe der Versions-ID wird der Vorgang für die aktuelle Version ausgeführt.

Wenn Sie einen Schreibvorgang zum Erstellen oder Ändern eines Blobs aufrufen, gibt Azure Storage den Header x-ms-version-id Header in der Antwort zurück. Dieser Header enthält die Versions-ID für die aktuelle Version des Blobs, das durch den Schreibvorgang erstellt wurde.

Die Versions-ID bleibt für die Lebensdauer der Version gleich.

Versionsverwaltung für Schreibvorgänge

Wenn Blobversionsverwaltung aktiviert ist, erstellt jeder Schreibvorgang in einem Blob eine neue Version. Zu den Schreibvorgängen zählen Put Blob, Put Block List, Copy Blob und Set Blob Metadata.

Wenn der Schreibvorgang ein neues Blob erstellt, entspricht das sich ergebende Blob der aktuellen Version des Blobs. Wenn durch den Schreibvorgang ein vorhandenes Blob geändert wird, wird die aktuelle Version zu einer vorherigen Version, und es wird eine neue aktuelle Version erstellt, um das aktualisierte Blob zu erfassen.

Die folgende Abbildung zeigt, wie sich Schreibvorgänge auf Blobversionen auswirken. Der Einfachheit halber wird in den in diesem Artikel gezeigten Abbildungen die Versions-ID als einfacher Integerwert angezeigt. In Wirklichkeit ist die Versions-ID ein Zeitstempel. Die aktuelle Version ist blau dargestellt, und vorherige Versionen werden grau dargestellt.

Diagram showing how write operations affect versioned blobs.

Hinweis

Ein Blob, das vor Aktivierung von Versionsverwaltung für das Speicherkonto erstellt wurde, weist keine Versions-ID auf. Wenn dieses Blob geändert wird, wird das geänderte Blob zur aktuellen Version, und es wird eine Version erstellt, um den Zustand des Blobs vor der Aktualisierung zu speichern. Der Version wird eine Versions-ID zugewiesen, die ihre Erstellungszeit angibt.

Wenn die Blobversionsverwaltung für ein Speicherkonto aktiviert ist, wird durch alle Schreibvorgänge für Blockblobs die Erstellung einer neuen Version ausgelöst. Einzige Ausnahme ist der Vorgang Put Block (Block festlegen).

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

Die folgenden Vorgänge führen nicht zum Erstellen einer neuen Version. Um Änderungen aus diesen Vorgängen aufzuzeichnen, erstellen Sie eine manuelle Momentaufnahme:

Alle Versionen eines Blobs müssen denselben Blobtyp aufweisen. 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 Sie den Vorgang Delete Blob (Blob löschen) ohne Angabe einer Versions-ID aufrufen, wird die aktuelle Version zu einer früheren Version und es gibt keine aktuelle Version mehr. Alle vorhandenen vorherigen Versionen des Blobs bleiben erhalten.

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

Diagram showing deletion of versioned blob.

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. Ist für das Speicherkonto vorläufiges Löschen von Blobs aktiviert, bleibt die Version bis zum Ende des Aufbewahrungszeitraums für vorläufig gelöschte Ressourcen im System erhalten.

Wenn neue Daten in das Blob geschrieben werden, wird eine neue aktuelle Version des Blobs erstellt. Alle vorhandenen Versionen sind nicht betroffen, wie in der folgenden Abbildung gezeigt.

Diagram showing re-creation of versioned blob after deletion.

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. Sie können niedrigere Kapazitätspreise nutzen, indem Sie ältere Versionen eines Blobs in die kalte Ebene oder die Archivebene verschieben. Weitere Informationen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“, „Cold“ und „Archiv“ für Blobdaten.

Verwenden Sie Bloblebenszyklusverwaltung, um den Prozess des Verschiebens von Blockblobs in die entsprechende Ebene zu automatisieren. Weitere Informationen zur Lebenszyklusverwaltung finden Sie unter Verwalten des Lebenszyklus von Azure Blob Storage.

Aktivieren/Deaktivieren von Blobversionsverwaltung

Informationen zum Aktivieren und Deaktivieren der Blobversionsverwaltung finden Sie unter Aktivieren und Verwalten der Blobversionsverwaltung.

Durch Deaktivierung der Blobversionsverwaltung werden vorhandene Blobs, Versionen oder Momentaufnahmen nicht gelöscht. Wenn Sie Blobversionsverwaltung deaktivieren, kann auf alle vorhandenen Versionen in Ihrem Speicherkonto weiterhin zugegriffen werden. Anschließend werden keine weiteren neuen Versionen erstellt.

Wenn die Versionsverwaltung deaktiviert ist, wird durch Ändern der aktuellen Version ein Blob erstellt, bei dem es sich nicht um eine Version handelt. 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 mithilfe der Versions-ID lesen oder löschen, nachdem Versionsverwaltung deaktiviert wurde. 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.

Diagram showing that modification of a current version after versioning is disabled creates a blob that isn't a version.

Blobversionsverwaltung und vorläufiges Löschen

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

Überschreiben eines Blobs

Wenn die Blobversionsverwaltung und vorläufiges Löschen von Blobs für ein Speicherkonto aktiviert sind, wird durch das Überschreiben eines Blobs automatisch eine neue Version erstellt. Die neue Version wird nicht vorläufig gelöscht und nicht entfernt, wenn die Beibehaltungsdauer für vorläufiges Löschen abläuft. Es werden keine vorläufig gelöschten Momentaufnahmen erstellt.

Löschen eines Blobs oder einer Version

Wenn die Versionsverwaltung und vorläufiges Löschen für ein Speicherkonto aktiviert sind und Sie ein Blob löschen, wird die aktuelle Version des Blobs zu einer vorherigen Version. Es werden keine neue Version und auch keine vorläufig gelöschten Momentaufnahmen erstellt. Der Aufbewahrungszeitraum für vorläufig gelöschte Ressourcen gilt nicht für das gelöschte Blob.

Vorläufiges Löschen bietet zusätzlichen Schutz beim Löschen von Blobversionen. 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.

Die folgende Abbildung zeigt, was geschieht, wenn Sie ein Blob oder eine Blobversion löschen.

Diagram showing deletion of a version with soft delete enabled.

Wiederherstellen einer vorläufig gelöschten Version

Sie können den Vorgang Undelete Blob (Blob wiederherstellen) verwenden, um vorläufig gelöschte Versionen innerhalb des Aufbewahrungszeitraums für vorläufig gelöschte Ressourcen wiederherzustellen. Durch den Vorgang Undelete Blob (Blob wiederherstellen) werden immer alle vorläufig gelöschten Versionen des Blobs wiederhergestellt. Es ist nicht möglich, nur eine einzelne vorläufig gelöschte Version wiederherzustellen.

Durch das Wiederherstellen vorläufig gelöschter Versionen mit dem Vorgang Undelete Blob (Blob wiederherstellen) wird keine Version zur aktuellen Version. 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.

In der folgenden Abbildung wird gezeigt, wie Sie vorläufig gelöschte Blobversionen mit dem Vorgang Undelete Blob wiederherstellen, und wie Sie die aktuelle Version des Blobs mit dem Vorgang Copy Blob wiederherstellen.

Diagram showing how to restore soft-deleted versions.

Nachdem die Beibehaltungsdauer für vorläufiges löschen abgelaufen ist, werden alle vorläufig gelöschten Blobversionen dauerhaft gelöscht.

Blobversionsverwaltung und Blobmomentaufnahmen

Eine Blobmomentaufnahme ist eine schreibgeschützte Kopie eines Blobs, die zu einem bestimmten Zeitpunkt erstellt wird. Blobmomentaufnahmen und Blobversionen sind ähnlich, aber eine Momentaufnahme wird manuell von Ihnen oder Ihrer Anwendung erstellt, während eine Blobversion bei einem Schreib- oder Löschvorgang automatisch erstellt wird, wenn die Blobversionsverwaltung für Ihr Speicherkonto aktiviert ist.

Wichtig

Microsoft empfiehlt, dass Sie nach der Aktivierung von Blobversionsverwaltung auch Ihre Anwendung aktualisieren, damit keine Momentaufnahmen von Blockblobs mehr erstellt werden. Wenn Versionsverwaltung für Ihr Speicherkonto aktiviert ist, werden alle Blockblobaktualisierungen und -löschungen durch Versionen aufgezeichnet und beibehalten. Die Erstellung von Momentaufnahmen bietet keinen zusätzlichen Schutz für Ihre Blockblobdaten, wenn Blobversionsverwaltung aktiviert ist, und sie erhöht möglicherweise die Kosten und die Komplexität der Anwendung.

Momentaufnahme eines Blobs bei aktivierter Versionsverwaltung

Obwohl dies nicht empfohlen wird, können Sie eine Momentaufnahme eines Blobs erstellen, die auch mit einer Versionsangabe 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 Sie eine Momentaufnahme eines Blobs mit Versionsangabe erstellen, wird eine neue Version zur gleichen Zeit erstellt, zu der die Momentaufnahme erstellt wird. Eine neue aktuelle Version wird ebenfalls erstellt, wenn eine Momentaufnahme erstellt wird.

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.

Diagram showing snapshots of a versioned blob.

Autorisieren von Vorgängen für Blobversionen

Sie können Zugriff auf Blobversionen mit einer der folgenden Methoden autorisieren:

  • Mithilfe der rollenbasierten Azure-Zugriffssteuerung (Azure RBAC) zum Erteilen von Berechtigungen für einen Microsoft Entra-Sicherheitsprinzipal. Microsoft empfiehlt die Verwendung von Microsoft Entra ID für eine bessere Sicherheit und Benutzerfreundlichkeit. Weitere Informationen zur Verwendung von Microsoft Entra ID mit Blob-Vorgängen finden Sie unter Zugriff auf Daten in Azure Storage autorisieren.
  • Durch Delegieren des Zugriffs auf Blobversionen mithilfe einer Shared Access Signature (SAS). Geben Sie die Versions-ID für den signierten Ressourcentyp bv an, der eine Blobversion darstellt, um ein SAS-Token für Vorgänge mit einer bestimmten Version zu erstellen. Weitere Informationen zu SAS (Shared Access Signatures) finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).
  • Durch Verwendung der Kontozugriffsschlüssel zur Autorisierung von Vorgängen für Blobversionen mit gemeinsam verwendetem Schlüssel. 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 Blobversion

In der folgenden Tabelle wird gezeigt, welche Azure RBAC-Aktionen das Löschen eines Blobs oder einer Blobversion unterstützen:

BESCHREIBUNG Vorgang des Blob-Diensts Erforderliche Azure RBAC-Datenaktion Unterstützung für integrierte Azure-Rollen
Löschen der aktuellen Version Delete Blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete Mitwirkender an Storage-Blobdaten
Löschen einer vorherigen Version Delete Blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action Besitzer von Speicherblobdaten

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.

Berechtigung URI-Symbol Zulässige Vorgänge
Löschen x Löschen einer Blobversion.

Preise und Abrechnung

Wenn Sie Blobversionsverwaltung aktivieren, kann dies zu zusätzlichen Kosten für Datenspeicher für Ihr Konto führen. Es ist wichtig, dass Sie sich bei der Gestaltung Ihrer Anwendung bewusst sind, wie diese Gebühren entstehen, damit Sie Ihre Kosten minimieren können.

Blobversionen werden wie Blobmomentaufnahmen mit den gleichen Gebühren abgerechnet wie aktive Daten. Die Abrechnung von Versionen hängt davon ab, ob Sie die Ebene explizit für die aktuelle Version oder frühere Versionen eines Blobs (oder von Momentaufnahmen) festgelegt haben. Weitere Informationen zu Blobebenen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“, „Cold“ und „Archiv“ für Blobdaten.

Wenn Sie die Ebene eines Blobs oder einer Version nicht geändert haben, werden Ihnen die eindeutigen Datenblöcke in diesem Blob, seinen Versionen und allen ggf. vorhandenen Momentaufnahmen in Rechnung gestellt. Weitere Informationen finden Sie unter Abrechnung bei nicht explizit festgelegter Blobebene.

Wenn Sie die Ebene eines Blobs oder einer Version geändert haben, wird Ihnen das gesamte Objekt in Rechnung gestellt, unabhängig davon, ob sich das Blob und die Version wieder auf derselben Ebene befinden. Weitere Informationen finden Sie unter Abrechnung bei explizit festgelegter Blobebene.

Hinweis

Das Aktivieren von Versionsverwaltung für häufig überschriebene Daten kann zu höheren Gebühren für die Speicherkapazität und einer höheren Latenz bei Auflistungsvorgängen führen. Um diese Probleme zu vermeiden, speichern Sie häufig überschrieben Daten in einem separaten Speicherkonto mit deaktivierter Versionsverwaltung.

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

Abrechnung bei nicht explizit festgelegter Blobebene

Wenn Sie die Blobebene für eine beliebige Version eines Blobs nicht explizit festgelegt haben, werden Ihnen die eindeutigen Blöcke oder Seiten für alle Versionen und ggf. vorhandene Momentaufnahmen in Rechnung gestellt. Daten, die von mehreren Blobversionen gemeinsam genutzt werden, werden nur ein Mal in Rechnung gestellt. Wenn ein Blob aktualisiert wird, unterscheiden sich die Daten in der neuen aktuellen Version von den in den vorherigen Versionen gespeicherten Daten, und die eindeutigen Daten werden pro Block oder Seite abgerechnet.

Wenn Sie einen Block innerhalb eines Block-BLOBs ersetzen, wird dieser Block anschließend als eindeutiger Block berechnet. Dies gilt auch, wenn der Block dieselbe Block-ID und dieselben Daten enthält wie in der früheren Version. Nachdem der Block erneut committet wurde, weicht er von seinem Pendant in den früheren Versionen ab. Es werden Ihnen dann die Daten des Blocks berechnet. Gleiches gilt für eine Seite in einem Seitenblob, die mit identischen Daten aktualisiert wird.

Blob Storage kann nicht feststellen, ob zwei Blöcke identische Daten enthalten. Jeder hochgeladene Block, für den ein Commit ausgeführt wird, wird als eindeutig behandelt, selbst wenn die enthaltenen Daten und die Block-ID identisch sind. Da Gebühren jeweils für eindeutige Blöcke anfallen, sollten Sie berücksichtigen, dass beim Aktualisieren eines Blobs mit aktivierter Versionsverwaltung zusätzliche eindeutige Blöcke generiert werden, für die zusätzliche Kosten entstehen.

Wenn die Blobversionsverwaltung aktiviert ist, rufen Sie Aktualisierungsvorgänge für Blockblobs auf, damit Sie die geringstmögliche Anzahl von Blöcken aktualisieren. Die Schreibvorgänge, die eine differenzierte Steuerung von Blöcken ermöglichen, sind Put Block und Put Block List. Der Vorgang Put Blob hingegen ersetzt den gesamten Inhalt eines Blobs und kann zu zusätzlichen Kosten führen.

Die folgenden Szenarien veranschaulichen, wie Gebühren für ein Blockblob und zugehörige Versionen berechnet werden, wenn die Blobebene nicht explizit festgelegt wurde.

Szenario 1

In Szenario 1 ist eine frühere Version des Blobs vorhanden. Das Blob wurde nicht aktualisiert, seit die Version erstellt wurde, sodass Gebühren nur für die eindeutigen Blöcke 1, 2, und 3 anfallen.

Diagram 1 showing billing for unique blocks in base blob and previous version.

Szenario 2

In Szenario 2 wurde ein Block (Block 3 in der Abbildung) 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:

Diagram 2 showing billing for unique blocks in base blob and previous version.

Szenario 3

In Szenario 3 wurde das Blob aktualisiert, die Version jedoch nicht. Block 3 wurde im aktuellen Blob durch Block 4 ersetzt, die vorherige Version enthält aber immer noch Block 3. Daher wird das Konto mit Gebühren für vier Blöcke belastet:

Diagram 3 showing billing for unique blocks in base blob and previous version.

Szenario 4

In Szenario 4 wurde die aktuelle Version vollständig aktualisiert und enthält keinen der ursprünglichen Blöcke. Folglich wird das Konto für alle acht eindeutigen Blöcke belastet: vier in der aktuellen Version und insgesamt vier in den beiden Vorgängerversionen. Dieses Szenario kann eintreten, wenn Sie mit dem Vorgang Put Blob (Blob festlegen) in ein Blob schreiben, weil dabei der gesamte Inhalt des Blobs ersetzt wird.

Diagram 4 showing billing for unique blocks in base blob and previous version.

Abrechnung bei explizit festgelegter Blobebene

Wenn Sie die Ebene für ein Blob oder eine Version (oder eine Momentaufnahme) explizit festgelegt haben, wird Ihnen der gesamte Inhalt des Objekts auf der neuen Ebene in Rechnung gestellt. Dabei ist es irrelevant, ob es Blöcke mit einem Objekt auf der ursprünglichen Dienstebene gemeinsam nutzt. Ihnen wird auch der vollständige Inhalt der ältesten Version auf der ursprünglichen Ebene in Rechnung gestellt. Bei allen anderen früheren Versionen oder Momentaufnahmen, die auf der ursprünglichen Dienstebene verbleiben, erfolgt die Abrechnung nach eindeutigen Blöcken, die sie eventuell gemeinsam nutzen, wie unter Abrechnung bei nicht explizit festgelegter Blobebene beschrieben.

Verschieben eines Blobs auf eine neue Dienstebene

In der folgenden Tabelle wird das Abrechnungsverfahren für Blobs oder Versionen beschrieben, wenn diese auf eine neue Ebene verschoben werden.

Wenn die Blobebene wie folgt festgelegt ist... Dann wird Ihnen Folgendes in Rechnung gestellt:
Explizit für eine Version, ob aktuell oder älter Die vollständige Inhaltslänge dieser Version. Für Versionen ohne explizit festgelegte Ebene werden nur eindeutige Blöcke in Rechnung gestellt. 1
Auf Archiv Die vollständige Inhaltslänge aller Versionen und Momentaufnahmen.1

1 Wenn andere frühere Versionen oder Momentaufnahmen nicht von der ursprünglichen Ebene verschoben wurden, werden diese Versionen oder Momentaufnahmen basierend auf der Anzahl der enthaltenen eindeutigen Blöcke abgerechnet, wie in Abrechnung bei nicht explizit festgelegter Blobebene beschrieben.

Im folgenden Diagramm wird veranschaulicht, wie Objekte in Rechnung gestellt werden, wenn ein Blob mit Versionsangabe auf eine andere Dienstebene verschoben wird.

Diagram showing how objects are billed when a versioned blob is explicitly tiered.

Das explizite Festlegen der Ebene für ein Blob, eine Version oder eine Momentaufnahme kann nicht rückgängig gemacht werden. Wenn Sie ein Blob auf eine neue Ebene verschieben und dann wieder auf die ursprüngliche Ebene zurück verschieben, wird Ihnen der gesamte Inhalt des Objekts in Rechnung gestellt. Dies gilt auch, wenn Blöcke mit anderen Objekten auf der ursprünglichen Ebene gemeinsam genutzt werden.

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

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

Wenn vorläufiges Löschen für das Blob aktiviert ist, werden alle vorläufig gelöschten Entitäten mit voller Inhaltslänge abgerechnet. Wenn Sie eine aktuelle Version löschen oder überschreiben, deren Dienstebene explizit festgelegt wurde, werden alle früheren Versionen des vorläufig gelöschten Blobs mit vollständiger Inhaltslänge abgerechnet. Weitere Informationen zur gemeinsamen Verwendung von Blobversionsverwaltung und vorläufigem Löschen finden Sie unter Blobversionsverwaltung und vorläufiges Löschen.

Featureunterstützung

Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem 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 bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Die Versionsverwaltung wird für Blobs, die mit Data Lake Storage Gen2 APIs hochgeladen werden, nicht unterstützt.

Siehe auch