Teilen über

Rehydrierung von Klecksen aus der Archivebene

  • Artikel

Während sich ein Blob auf der Archivzugriffsebene befindet, wird es als offline betrachtet und kann nicht gelesen oder geändert werden. Wenn Daten in einem archivierten Blob gelesen oder geändert werden sollen, muss das Blob zunächst auf einer Onlineebene (heiße oder kalte Ebene) aktiviert werden. Es gibt zwei Möglichkeiten, ein auf der Archivebene gespeichertes Blob zu aktivieren:

Die Aktivierung eines Blobs aus der Archivebene kann mehrere Stunden dauern. Microsoft empfiehlt, größere Blobs zu archivieren, um eine optimale Leistung beim Aktivieren zu erzielen. Das Aktivieren einer großen Anzahl kleiner Blobs kann aufgrund des Verarbeitungsaufwands für jedes Blob zusätzliche Zeit erfordern. Pro Speicherkonto können bei einem Abruf mit hoher Priorität maximal 10 GiB pro Stunde aktiviert werden.

Informationen zum Aktivieren eines archivierten Blobs auf einer Onlineebene finden Sie unter Aktivieren eines archivierten Blobs auf einer Onlineebene.

Aktivierungspriorität

Wenn Sie ein Blob aktivieren, können Sie die Priorität für den Aktivierungsvorgang über den optionalen Header x-ms-rehydrate-priority bei den Vorgängen Set Blob Tier oder Copy Blob festlegen. Optionen für Aktivierungspriorität:

  • Standardpriorität: Die Aktivierungsanforderung wird gemäß der Eingangsreihenfolge verarbeitet und kann für Objekte mit einer Größe von weniger als 10 GB bis zu 15 Stunden dauern.
  • Hohe Priorität: Die Aktivierungsanforderung hat Vorrang vor Anforderungen mit Standardpriorität und kann bei Objekten mit einer Größe von weniger als 10 GB in weniger als einer Stunde verarbeitet werden.

Wenn Sie die Aktivierungspriorität während des Aktivierungsvorgangs prüfen möchten, rufen Sie Get Blob Properties (Blobeigenschaften abrufen) auf, sodass der Wert des x-ms-rehydrate-priority-Headers zurückgegeben wird. Für die Eigenschaft für die Aktivierungspriorität wird Standard oder Hoch zurückgegeben.

Die Standardpriorität ist die Standardaktivierungsoption. Die Aktivierung mit hoher Priorität ist eine schnellere Option, kostet aber auch mehr als die Aktivierung mit Standardpriorität. Die Aktivierung mit hoher Priorität kann je nach Blobgröße und aktueller Auslastung länger als eine Stunde dauern. Microsoft empfiehlt, die Aktivierung mit hoher Priorität nur in Notfallsituationen zu verwenden, in denen Daten dringend wiederhergestellt werden müssen.

Während ein Aktivierungsvorgang mit Standardpriorität läuft, können Sie die Einstellung der Aktivierungspriorität für ein Blob in Hoch ändern, um dieses Blog schneller zu aktivieren. Wenn Sie beispielsweile eine große Anzahl von Blobs in einem Arbeitsschritt aktivieren, können Sie im ersten Vorgang die Priorität Standard für alle Blobs festlegen und dann die Priorität für alle Blobs in Hoch ändern, die schneller online geschaltet werden müssen. Der Grenzwert liegt bei 10 GiB pro Stunde.

Die Einstellung der Aktivierungspriorität kann für einen ausstehenden Vorgang nicht von Hoch auf Standard herabgesetzt werden. Beachten Sie, dass eine Änderung der Aktivierungspriorität sich auf die Kosten auswirken kann.

Weitere Informationen zum Festlegen und Aktualisieren der Aktivierungspriorität finden Sie unter Aktivieren eines archivierten Blobs auf einer Onlineebene.

Weitere Informationen zu den Preisunterschieden zwischen Aktivierungsanforderungen mit Standardpriorität und hoher Priorität finden Sie unter Preise für Azure Blob Storage.

Kopieren eines archivierten Blobs auf eine Onlineebene

Die erste Möglichkeit, ein Blob aus der Archivebene in eine Onlineebene zu verschieben, besteht darin, das archivierte Blob in ein neues Zielblob zu kopieren, das sich entweder auf heißer, kühler oder kalter Ebene befindet. Sie können den Vorgang Copy Blob verwenden, um das Blob zu kopieren. Wenn ein archiviertes Blob in ein neues Blob auf der Onlineebene kopiert wird, bleibt das Quellblob auf der Archivebene unverändert.

Das archivierte Blob muss in ein neues Blob mit einem anderen Namen oder in einen anderen Container kopiert werden. Das Quellblob kann nicht durch Kopieren in dasselbe Blob überschrieben werden.

Durch Kopieren eines Blobs aus der Archivebene in eine Onlineebene wird die Gebühr für vorzeitiges Löschen vermieden, die erhoben wird, wenn die Ebene für das Blob vor Ablauf der vorgesehenen Frist von 180 Tagen von der Archivebene gewechselt wird. Weitere Informationen finden Sie unter Zugriffsebene „Archiv“.

Diese Option kann auch sinnvoll sein, wenn eine Lebenszyklusverwaltungsrichtlinie für das Speicherkonto wirksam ist und die daysAfterLastTierChangeGreaterThan-Bedingung nicht jeder tierToArchive-Aktion der Richtlinie hinzugefügt wird. In diesem Fall kann die Aktivierung eines Blobs mit Set Blob Tier dazu führen, dass das Blob aufgrund der Lebenszyklusrichtlinie nach der Aktivierung auf die Archivebene zurückverschoben wird, weil der Zeitpunkt der letzten Änderung nach dem für die Richtlinie festgelegten Schwellenwert liegt. Bei einem Kopiervorgang bleibt das Quellblob auf der Archivebene, und es wird ein neues Blob mit einem anderen Namen und einem neuen Wert für den Zeitpunkt der letzten Änderung erstellt. Es besteht also keine Gefahr, dass das aktivierte Blob aufgrund der Lebenszyklusrichtlinie auf die Archivebene zurückverschoben wird.

Das Kopieren eines Blobs aus dem Archiv kann je nach ausgewählter Aktivierungspriorität mehrere Stunden dauern. Im Hintergrund wird beim Vorgang „Copy Blob“ das archivierte Quellblob gelesen und so auf der ausgewählten Zielebene ein neues Onlineblob erstellt. Das neue Blob wird möglicherweise angezeigt, wenn Sie die Blobs im übergeordneten Container auflisten, bevor der Aktivierungsvorgang abgeschlossen ist, seine Ebene ist aber auf „Archiv“ festgelegt. Die Daten bleiben so lange verfügbar, bis der Lesevorgang aus dem Quellblob auf der Archivebene abgeschlossen ist und die Inhalte des Blobs in das neue Zielblob auf einer Onlineebene geschrieben wurden. Beim neuen Blob handelt es sich um eine unabhängige Kopie, sodass es keine Auswirkungen auf das Quellblob auf der Archivebene hat, wenn das neue Blob geändert oder gelöscht wird.

Informationen zum Aktivieren eines Blobs durch Kopieren in eine Onlineebene finden Sie unter Aktivieren eines Blobs mit einem Kopiervorgang.

Wichtig

Löschen Sie das Quellblob erst, nachdem die Aktivierung erfolgreich durchgeführt wurde. Wenn das Quellblob gelöscht wird, kann der Kopiervorgang für das Zielblob möglicherweise nicht abgeschlossen werden. Sie können das Ereignis behandeln, das nach Abschluss des Kopiervorgangs ausgelöst wird, um zu ermitteln, wann das Quellblob bedenkenlos gelöscht werden kann. Weitere Informationen hierzu finden Sie unter Behandeln eines Ereignisses bei der Blobaktivierung.

Die Aktivierung eines archivierten Blobs durch Kopieren in eine Onlinezielebene wird nur bei Dienstversionen vor 12.02.2021 innerhalb desselben Speicherkontos unterstützt. Ab Dienstversion 12.02.2021 können Sie ein archiviertes Blob aktivieren, indem Sie es in ein anderes Speicherkonto kopieren, solange sich das Zielkonto in derselben Region wie das Quellkonto befindet. Durch die speicherkontoübergreifende Aktivierung können Sie Ihre Produktionsdaten von Ihren Sicherungsdaten trennen, indem Sie sie in separaten Konten verwalten. Das Isolieren archivierter Daten in einem separaten Konto kann auch dazu beitragen, die Kosten bei einer unbeabsichtigten Aktivierung zu verringern.

Das Zielblob für den Kopiervorgang muss sich auf einer Onlineebene (heiße oder kalte Ebene) befinden. Ein archiviertes Blob kann nicht in ein Zielblob kopiert werden, das sich auch auf der Archivebene befindet.

In der folgenden Tabelle ist das Verhalten eines Blobkopiervorgangs abhängig von den Ebenen des Quell- und des Zielblobs dargestellt.

Quelle: Heiße Ebene Quelle: Kalte Ebene Quelle: Archivebene
Ziel: Heiße Ebene Unterstützt Unterstützt Wird kontenübergreifend in derselben Region mit Version 12.02.2021 und höher unterstützt. Wird nur bei früheren Versionen innerhalb desselben Speicherkontos unterstützt. Erfordert eine Blobaktivierung
Ziel: Kalte Ebene Unterstützt Unterstützt Wird kontenübergreifend in derselben Region mit Version 12.02.2021 und höher unterstützt. Wird nur bei früheren Versionen innerhalb desselben Speicherkontos unterstützt. Erfordert eine Blobaktivierung
Ziel: Archivebene Unterstützt Unterstützt Nicht unterstützt

Aktivierung aus einer sekundären Region

Wenn Sie Ihr Speicherkonto für die Verwendung von georedundantem Speicher mit Lesezugriff (RA-GRS) konfiguriert haben, können Sie die Operation Copy Blob verwenden, um Blobs in der sekundären Region für ein anderes Speicherkonto in derselben sekundären Region zu aktivieren. Siehe Aktivierung aus einer sekundären Region.

Weitere Informationen zum Erlangen von Lesezugriff für sekundäre Regionen finden Sie unter Lesezugriff auf Daten in der sekundären Region.

Ändern der Zugriffsebene eines Blobs in eine Onlineebene

Die zweite Möglichkeit, ein Blob aus der Archivebene in einer Onlineebene zu aktivieren, besteht darin, die Ebene des Blobs durch den Aufruf von Set Blob Tier zu wechseln. Mit diesem Vorgang kann die Ebene des archivierten Blobs in heiß oder kalt geändert werden.

Sobald eine Set Blob Tier-Anforderung eingeleitet wurde, kann sie nicht mehr abgebrochen werden. Während des Aktivierungsvorgangs wird die Zugriffsebene des Blobs weiterhin als archiviert angezeigt, bis der Aktivierungsprozess abgeschlossen ist. Nach Abschluss des Aktivierungsvorgangs wird die Zugriffsebeneneigenschaft des Blobs aktualisiert, sodass die neue Ebene angezeigt wird.

Informationen zum Aktivieren eines Blobs durch Ändern seiner Ebene in eine Onlineebene finden Sie unter Aktivieren eines Blobs durch Ändern seiner Ebene.

Achtung

Wenn Sie die Ebene eines Blobs ändern, hat das keine Auswirkungen auf den Zeitpunkt der letzten Änderung. Wenn für das Speicherkonto eine Lebenszyklusverwaltungsrichtlinie gilt, kann die Aktivierung eines Blobs mit Set Blob Tier dazu führen, dass das Blob aufgrund der Lebenszyklusrichtlinie nach der Aktivierung auf die Archivebene zurück verschoben wird, weil der Zeitpunkt der letzten Änderung nach dem für die Richtlinie festgelegten Schwellenwert liegt.

Wenn Sie dieses Szenario vermeiden möchten, fügen Sie der Aktion tierToArchive der Richtlinie die Bedingung daysAfterLastTierChangeGreaterThan hinzu. Alternativ können Sie das archivierte Blob aktivieren, indem Sie es stattdessen so kopieren, wie es im Abschnitt Kopieren eines archivierten Blobs auf eine Onlineebene beschrieben wird. Bei einem Kopiervorgang wird eine neue Instanz des Blobs mit einem aktualisierten Zeitpunkt der letzten Änderung erstellt, sodass die Lebenszyklusverwaltungsrichtlinie nicht ausgelöst wird.

Überprüfen des Status eines Blob-Aktivierungsvorgangs

Während des Blog-Aktivierungsvorgangs können Sie den Vorgang Get Blob Properties aufrufen, um den Status zu überprüfen. Informationen zum Prüfen des Status eines Aktivierungsvorgangs finden Sie unter Überprüfen des Status eines Aktivierungsvorgangs.

Behandeln eines Ereignisses bei der Blobaktivierung

Die Aktivierung eines archivierten Blobs kann bis zu 15 Stunden dauern, und das wiederholte Aufrufen von Get Blob Properties, um festzustellen, ob die Aktivierung abgeschlossen ist, ist ineffizient. Microsoft empfiehlt die Verwendung von Azure Event Grid zur Erfassung des Ereignisses, das bei Abschluss der Aktivierung ausgelöst wird, um Leistung und Kosten zu optimieren.

Azure Event Grid löst das Microsoft.Storage.BlobTierChanged-Ereignis nach Abschluss der Blob-Rehydrations aus:

  • Das Ereignis Microsoft.Storage.BlobTierChanged wird ausgelöst, wenn sich die Ebene des Blobs ändert. Im Kontext der Blobaktivierung wird dieses Ereignis ausgelöst, wenn die Zugriffsebene eines Zielblobs erfolgreich von der Archivebene in eine Onlineebene (heiß, kühl oder kalt) geändert wird. Sie können den Vorgang „Blob-Ebene festlegen“ verwenden, um die Zugriffsebene eines archivierten Blobs zu ändern, oder den Copy-Blob-Vorgang verwenden, um ein archiviertes Blob in einen neuen Ziel-Blob in einer Onlineebene zu kopieren.

Informationen zum Aufzeichnen eines Ereignisses bei der Aktivierung und zum Senden des Ereignisses an einen Ereignishandler einer Azure-Funktion finden Sie unter Ausführen einer Azure-Funktion als Reaktion auf ein Blob-Aktivierungsereignis.

Weitere Informationen zur Behandlung von Ereignissen in Blob Storage finden Sie unter Reagieren auf Azure Blob Storage-Ereignisse und unter Azure Blob Storage als Event Grid-Quelle.

Preise und Abrechnung

Ein Aktivierungsvorgang mit Set Blob Tier wird pro Datenlesetransaktion und je nach Datenabrufgröße berechnet. Eine Aktivierung mit hoher Priorität verursachen höhere Vorgangs- und Datenabrufkosten als Vorgänge mit Standardpriorität. Aktivierungsvorgänge mit hoher Priorität werden auf Ihrer Rechnung als separater Posten ausgewiesen. Wenn eine Anforderung mit hoher Priorität zum Abrufen eines archivierten Blobs, der weniger als 10 GB groß ist, über fünf Stunden dauert, werden Ihnen nicht die Gebühren für einen Abruf mit hoher Priorität berechnet. Stattdessen werden die Standardgebühren für Abrufvorgänge berechnet.

Das Kopieren eines archivierten Blobs in eine Onlineebene mit Copy Blob wird pro Datenlesetransaktion und je nach Datenabrufgröße berechnet. Das Erstellen des Zielblobs in einer Onlineebene wird pro Datenschreibtransaktion berechnet. Gebühren für frühes Löschen fallen beim Kopieren in ein Onlineblob nicht an, weil das Quellblob auf der Archivzugriffsebene unverändert bleibt. Für einen Abruf mit hoher Priorität werden Gebühren berechnet, sofern dieser ausgewählt ist.

Blobs auf Archivzugriffsebene müssen mindestens 180 Tage lang gespeichert werden. Für das Löschen oder Ändern der Ebene eines archivierten Blobs vor Ablauf der 180-Tage-Frist wird eine Gebühr für vorzeitiges Löschen berechnet. Wenn ein Blob beispielsweise auf die Archivebene verschoben und dann nach 45 Tagen gelöscht oder auf die heiße Ebene verschoben wird, wird Ihnen eine Gebühr für frühzeitiges Löschen berechnet, die den 135 Speichertagen (180–45) dieses Blobs auf der Archivebene entspricht. Weitere Informationen finden Sie unter Zugriffsebene „Archiv“.

Weitere Informationen zu den Preisen für Blockblobs und Datenaktivierung finden Sie unter Preise für Azure Storage. Weitere Informationen zu den Kosten für ausgehende Datenübertragungen finden Sie unter Datenübertragungen – Preisdetails.

Weitere Informationen