Blobversionsverwaltung

Sie können die Blob Storage-Versionsverwaltung 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.

Vorsicht

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 von Blob-Versionierung zusätzliche Kosten verursachen. 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 Kostenoptimierung durch die Automatisierung der Zugriffsebenen von Azure Blob Storage.

Funktionsweise der Blobversionsverwaltung

Eine Version erfasst den Zustand eines Blobs zu einem bestimmten Zeitpunkt. Jede Version wird durch eine Versions-ID identifiziert. Wenn die Blob-Versionsverwaltung für ein Speicherkonto aktiviert ist, erstellt Azure Storage automatisch eine neue Version mit einer eindeutigen ID, wenn ein Blob zum ersten Mal erstellt wird und jedes Mal, wenn das Blob anschließend geändert wird.

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:

Diagramm, das zeigt, wie Blob-Versionierung Versionen bei Schreiboperationen erstellt und befördert.

Wichtig

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, weniger als 1000 Versionen pro Blob beizubehalten. Sie können die Lebenszyklusverwaltung verwenden, um alte Versionen automatisch zu löschen. Weitere Informationen zur Lebenszyklusverwaltung finden Sie unter Kostenoptimierung durch die Automatisierung der Zugriffsebenen von Azure Blob Storage.

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

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.

Wichtig

Blob-Versionierung kann dir nicht helfen, dich von der versehentlichen Löschung eines Speicherkontos oder Containers zu erholen. 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 Eine Azure Resource Manager Sperre auf ein Speicherkonto anwenden.

Versions-ID

Jede Blob-Version hat eine einzigartige Versions-ID. Der Versions-ID-Wert 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 einen Schreibvorgang zum Erstellen oder Ändern eines Blobs aufrufen, gibt Azure Storage den Header x-ms-version-id in der Antwort zurück. Dieser Header enthält die Versions-ID für die aktuelle Version des Blobs, den die Schreiboperation erzeugt.

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.

Abbildung, die zeigt, wie sich Schreibvorgänge auf Blobs mit Versionsangabe auswirken

Hinweis

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:

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 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 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. Die Operation bewahrt alle bestehenden vorherigen Versionen des Blobs.

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

Abbildung, die das Löschen eines Blobs mit Versionsangabe zeigt

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.

Abbildung, die die erneute Erstellung eines Blobs mit Versionsangabe nach dem Löschen zeigt

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 auf die Cool- oder Archiv-Ebene verschieben, können Sie von günstigeren Preisen 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 Ebene zu automatisieren, verwenden Sie Blob Lifecycle Management. Weitere Informationen zum Lebenszyklusmanagement finden Sie unter Verwaltung des Azure Blob-Speicherlebenszyklus.

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 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.

Abbildung, die zeigt, dass die Änderung einer aktuellen Version nach der Deaktivierung der Versionsverwaltung ein Blob erzeugt, das keine Version mehr ist

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 Empfehlungen von Microsoft zum Datenschutz finden Sie in der Übersicht über den Datenschutz.

Überschreiben eines Blobs

Wenn die Blobversionsverwaltung und das vorläufige 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 du Versionsmanagement und Soft-Delete für ein Speicherkonto aktivierst, wird beim Löschen eines Blobs die aktuelle Version des Blobs zu einer früheren Version. Der Vorgang erstellt weder eine neue Version noch vorläufig gelöschte 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 du eine vorherige Version des Blobs löschst, wird diese Version vorläufig gelöscht. Die vorläufig gelöschte Version bleibt erhalten, bis der Aufbewahrungszeitraum für die vorläufige Löschung abläuft, und wird danach dauerhaft 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.

Abbildung, die das Löschen einer Version mit aktiviertem vorläufigem Löschen zeigt

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. Man kann nicht nur eine einzelne Soft-Delete-Version wiederherstellen.

Das Wiederherstellen von vorläufig gelöschten Versionen mithilfe des Vorgangs Undelete Blob macht 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.

Das folgende Diagramm zeigt, wie man weich gelöschte Blob-Versionen mit der Operation Undelete Blob wiederherstellt und wie man die aktuelle Version des Blobs mit der Copy Blob-Operation wiederherstellt.

Abbildung, die zeigt, wie vorläufig gelöschte Versionen wiederhergestellt werden

Nach Ablauf des Aufbewahrungszeitraums für das vorläufige Löschen werden alle vorläufig gelöschten Blobversionen dauerhaft gelöscht.

Blobversionsverwaltung und Blobmomentaufnahmen

Ein Blob-Snapshot 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 während einer Schreib- oder Löschoperation erstellt wird, wenn Sie die Blob-Versionierung für Ihr Speicherkonto aktivieren.

Wichtig

Microsoft empfiehlt, dass Sie nach der Aktivierung der BLOB-Versionsverwaltung auch Ihre Anwendung aktualisieren, um die Erstellung von Momentaufnahmen von Block-Blobs zu beenden. Wenn du die Versionssteuerung für dein Speicherkonto aktivierst, erfasst und speichert es alle Blockblob-Updates und -Löschungen, indem es Versionen verwendet. Das Aufnehmen von Snapshots bietet keinen zusätzlichen Schutz für Ihre Block-Blob-Daten, wenn Blob-Versionierung aktiviert ist, und könnte die Kosten und die Anwendungskomplexität erhöhen.

Momentaufnahme eines Blobs bei aktivierter Versionsverwaltung

Obwohl dies nicht empfohlen wird, kannst du einen Snapshot eines Blobs erstellen, für den ebenfalls die Versionsverwaltung aktiviert 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 versionierten Blobs erstellen, erstellen Sie gleichzeitig mit der Momentaufnahme auch 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.

Abbildung, die Momentaufnahmen eines Blobs mit Versionsangabe zeigt

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.

BESCHREIBUNG Vorgang des Blob-Diensts Erforderliche Azure RBAC-Datenaktion Azure integrierte Rollenunterstützung
Löschen der aktuellen Version Blob löschen Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete Mitwirkender an Storage-Blobdaten
Löschen einer vorherigen Version Blob löschen 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

Die Aktivierung von Blob-Versionierung kann zu zusätzlichen Datenspeicherkosten für Ihr Konto führen. Berücksichtigen Sie beim Entwerfen Ihrer Anwendung, wie diese Gebühren anfallen können, damit Sie die Kosten minimieren können.

Blobversionen werden wie Blobmomentaufnahmen mit den gleichen Gebühren abgerechnet wie aktive Daten. Wie du für Versionen bezahlst, hängt davon ab, ob du die Stufe 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 du die Stufe eines Blobs oder einer Version nicht änderst, zahlst du für einzigartige Datenblöcke in diesem Blob, seinen Versionen und eventuellen Snapshots. Weitere Informationen finden Sie unter Abrechnung, wenn die Blob-Ebene nicht explizit festgelegt ist.

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

Hinweis

Das Aktivieren von Versionsmanagement für häufig überschriebene Daten könnte die Speicherkapazitätskosten erhöhen und die Latenz während der Auflistungsoperationen erhöhen. Um diese Probleme zu vermeiden, speichern Sie häufig überschrieben Daten in einem separaten Speicherkonto mit deaktivierter Versionsverwaltung.

Wenn Versionen in Speicherkonten aktiviert werden, die häufig gesichert werden, können Gebühren für den Datenabruf ausgelöst werden, wenn die Versionen auf den Zugriffsebenen „Kalt“ oder „Cold“ gespeichert werden.

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 du die Blob-Stufe nicht explizit festgelegt hast

Wenn du die Blob-Stufe für keine Versionen eines Blobs explizit festlegst, zahlst du für einzigartige Blöcke oder Seiten über alle Versionen hinweg und für eventuelle Snapshots. Für geteilte Daten zwischen Blob-Versionen zahlst du nur einmal. Wenn du einen Blob aktualisierst, unterscheiden sich die Daten in der neuen aktuellen Version von den in früheren Versionen gespeicherten Daten, und du zahlst für die eindeutigen Daten pro Block oder Seite.

Wenn du einen Block innerhalb eines Blockblobs ersetzt, zahlst du für diesen Block als einzigartigen Block. Diese Regel gilt auch dann, wenn der Block dieselbe Block-ID und dieselben Daten wie in der vorherigen Version hat. Nachdem du den Block erneut committest, weicht er von seinem Gegenstück in der vorherigen Version ab, und du bezahlst für seine Daten. 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 du für einzigartige Blöcke bezahlst, solltest du bedenken, dass das Aktualisieren eines Blobs bei aktivierter Versionierung zu mehr 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. 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.

Diagramm 1 zeigt die Abrechnung für einzigartige Blöcke im Basis-Blob und in der vorherigen Version.

Szenario 2

In Szenario 2 aktualisiert man einen Block (Block 3 im Diagramm) im Blob. Obwohl der aktualisierte Block die gleichen Daten und dieselbe ID enthält, ist er nicht identisch mit Block 3 in der vorherigen Version. Dadurch zahlst du für vier Blocks.

Diagramm 2 zeigt die Abrechnung für eindeutige Blöcke im Basis-Blob und in der vorherigen Version.

Szenario 3

In Szenario 3 aktualisiert man den Blob, aber nicht die Version. Du ersetzt Block 3 durch Block 4 im aktuellen Blob, aber die vorherige Version zeigt weiterhin Block 3. Dadurch zahlst du für vier Blocks.

Diagramm 3 zeigt die Abrechnung für eindeutige Blöcke im Basis-Blob und in der vorherigen Version.

Szenario 4

In Szenario 4 aktualisiert man die aktuelle Version komplett und sie enthält keine der ursprünglichen Blöcke. Dadurch zahlst du für alle acht einzigartigen Blöcke – 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.

Diagramm 4 zeigt die Abrechnung für eindeutige Blöcke im Basis-Blob und in der vorherigen Version.

Abrechnung, wenn das Blob-Tier explizit festgelegt ist

Wenn du die Blob-Stufe explizit für einen Blob, eine Version oder einen Snapshot einstellst, zahlst du für die volle Inhaltslänge des Objekts in der neuen Stufe, selbst wenn es Blöcke mit einem Objekt im ursprünglichen Bestand teilt. 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 Sie die Blob-Ebene festlegen... 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

1Wenn 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.

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

Diagramm der Abrechnung von Objekten, wenn ein Blob mit Versionsangabe explizit auf eine Dienstebene ausgelagert wird

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:

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 mit einer explizit festgelegten Stufe löschst oder überschreibst, zahlst du für alle vorherigen Versionen des weich gelöschten Blobs in voller Inhaltslänge. 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 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.

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

Weitere Informationen

  • Last updated on