Rehydrierung von Klecksen aus der Archivebene

Ein archivierter Blob ist offline und kann nicht gelesen oder verändert werden. Um auf die zugehörigen Daten zuzugreifen, aktivieren Sie den Blob zunächst auf einer Online-Ebene: heiß, kühl oder kalt. Verwenden Sie eine der folgenden Rehydrierungsmethoden:

Wichtig

Archivierte Snapshots oder frühere Versionen kann man nicht direkt rehydrieren. Um auf Daten aus einem archivierten Snapshot oder einer früheren Version zuzugreifen, müssen Sie diese über die Operation Copy Blob in einen neuen Blob in einem Online-Tier (heiß, kühl oder kalt) kopieren.

Die Aktivierung eines Blobs aus der Archivebene kann mehrere Stunden dauern. Archiviere größere Blobs für optimale Rehydrationsleistung. Das Aktivieren einer großen Anzahl kleiner Blobs kann aufgrund des Verarbeitungsaufwands für jedes Blob zusätzliche Zeit erfordern. Maximal 10 GiB pro Speicherkonto können pro Stunde mit Prioritätsabruf rehydratisiert werden.

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

Aktivierungspriorität

Wenn du einen Blob rehydrierst, kannst du die Operationspriorität mit dem optionalen x-ms-rehydrate-priority Header auf einer Set Blob Tier - oder Copy Blob-Operation 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 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. Eine Rehydrierung mit hoher Priorität ist schneller, kostet aber mehr als eine Standard-Rehydrierung. Eine hochprioritäre Rehydrierung kann je nach Blob-Größe und aktuellem Bedarf länger als eine Stunde dauern. Rehydrierung mit hoher Priorität für Notfalldatenwiederherstellung reservieren.

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.

Wichtig

Der Grenzwert von 10 GiB/Stunden gilt auf Speicherkontoebene und nicht pro BLOB. Obwohl Zeitpläne wie "bis zu 15 Stunden" für Standardpriorität unter idealen Bedingungen für einzelne Blobs gelten könnten, skalieren sie für Großbetriebe nicht linear. Wenn du große Datenmengen rehydrierst, rechne mit längeren Dauern und plane entsprechend. Der Durchsatz wird von allen Blobs gemeinsam genutzt, die im selben Konto rehydratisiert werden, und das Überschreiten des Stundenlimits kann zu Drosselung oder längeren Verzögerungen führen. Berücksichtigen Sie für eine optimale Leistung die Batchverarbeitung von Rehydrationsanforderungen und die Überwachung der Aktivität auf Kontoebene.

Man kann die Rehydrierungspriorität für eine ausstehende Operation nicht von Hoher auf Standard senken. Das Aktualisieren der Priorität könnte die Abrechnung beeinflussen.

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

Um einen archivierten Blob durch Kopieren wieder zu hydratisieren, verwenden Sie die Copy Blob-Operation , um einen neuen Ziel-Blob in der heißen, kühlen oder kalten Kategorie zu erstellen. Der Quellblob bleibt im Archiv-Tier 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“.

Vermeiden Sie die Neuarchivierung von Lebenszyklusrichtlinien

Das Kopieren kann außerdem verhindern, dass eine Lebenszyklusverwaltungsrichtlinie einen rehydratisierten Blob zurück in die Archivschicht verschiebt. Dieses Risiko besteht dann, wenn die tierToArchive Aktion der Richtlinie die Bedingung daysAfterLastTierChangeGreaterThan nicht einschließt und die zuletzt modifizierte Zeit des Blobs die Richtlinienschwelle überschreitet. Eine Kopieroperation lässt den Quellblob in der Archivstufe und erstellt einen neuen Blob mit einem anderen Namen und einer neuen Zeit der letzten Änderung.

Überwachen Sie den Abschluss des Kopiervorgangs

Das Kopieren eines Blobs aus der Archivebene kann Stunden dauern, abhängig von der gewählten Rehydrationspriorität. Die Kopieroperation liest den archivierten Quellblob und erstellt einen neuen Blob in der ausgewählten Online-Schicht. Der neue Blob könnte im Elternbehälter erscheinen, bevor die Rehydrierung abgeschlossen ist, aber seine Stufe bleibt archiviert. Seine Daten werden verfügbar, nachdem der Dienst den Quellblob gelesen und dessen Inhalt an den Zielblob geschrieben hat. Der neue Blob ist eine unabhängige Kopie, daher beeinflusst das Ändern oder Löschen nicht den archivierten Quellblob.

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

Wichtig

Lösche den Quellblob nicht, bis die Rehydrierung erfolgreich abgeschlossen ist. Wenn du den Quellblob löschst, könnte der Zielblob das Kopieren nicht beenden. Überwachen Sie das Abschlussereignis, um festzustellen, wann Sie den Quellblob sicher löschen können. Weitere Informationen finden Sie unter Behandeln eines Blob-Rehydrierungsereignisses.

Kopieren über Speicherkonten hinweg

Die Serviceversion 2021-02-12 und höher unterstützt die Rehydrierung durch Kopieren eines archivierten Blobs in ein anderes Speicherkonto in derselben Region. Frühere Service-Versionen unterstützen Rehydration nur innerhalb desselben Speicherkontos. Die kontoübergreifende Rehydration ermöglicht es Ihnen, Ihre Produktionsdaten von Ihren Sicherungsdaten zu trennen, indem Sie sie in separaten Konten speichern. Die Isolierung archivierter Daten in einem separaten Konto kann ebenfalls helfen, Kosten durch unbeabsichtigte Rehydration zu minimieren.

Der Ziel-Blob für die Kopieroperation muss sich in einer Online-Stufe befinden (heiß, kühl oder kalt). 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 Kalte Speicherebene als Quelle Quelle: Archivebene
Ziel: Heiße Ebene Unterstützt 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 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 der kalten Stufe Unterstützt 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 Unterstützt Nicht unterstützt

Aktivierung aus einer sekundären Region

Wenn Ihr Speicherkonto lesezugriffsgeoredundanten Speicher (RA-GRS) verwendet, nutzen Sie den Vorgang Copy Blob, um Blobs aus der sekundären Region in ein anderes Konto in dieser Region zu rehydrieren. 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 dieser Operation kannst du die Stufe des archivierten Blobs auf heiß, kühl oder kalt ändern.

Du kannst eine Set Blob Tier-Anfrage nicht mehr abbrechen, nachdem sie gestartet ist. Während der Rehydrierung bleibt die Zugangsstufe des Blobs archiviert. Wenn die Rehydration abgeschlossen ist, zeigt die Eigenschaft der Zugriffsebene die neue Ebene an.

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

Vorsicht

Wenn Sie die Ebene eines Blobs ändern, hat das keine Auswirkungen auf den Zeitpunkt der letzten Änderung. Wenn das Speicherkonto über eine Richtlinie zur Lebenszyklusverwaltung verfügt, kann die Richtlinie den Blob nach der Rehydrierung zurück in die Archivierungsebene verschieben, sobald das Datum der letzten Änderung den in der Richtlinie festgelegten Schwellenwert überschreitet.

Wenn Sie dieses Szenario vermeiden möchten, fügen Sie der Aktion daysAfterLastTierChangeGreaterThan der Richtlinie die Bedingung tierToArchive 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. Das Ausführen einer Kopieroperation erzeugt eine neue Instanz des Blobs mit einer aktualisierten letzten Änderungszeit, sodass die Lebenszyklus-Management-Richtlinie 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.

Ein Blob-Rehydrierungsereignis behandeln

Das Rehydratieren eines archivierten Blobs kann bis zu 15 Stunden dauern, und das wiederholte Abfragen von Get Blob Properties ist ineffizient. Verwenden Sie Azure Event Grid, um das Abschlussereignis zu erfassen und für bessere Leistung und geringere Kosten zu sorgen.

Azure Event Grid aktiviert das Microsoft.Storage.BlobTierChanged Ereignis, wenn die Blob-Rehydration abgeschlossen ist:

  • Das Microsoft.Storage.BlobTierChanged Event wird ausgelöst, wenn sich die Stufe eines Blobs ändert. Bei der Blob-Aktivierung wird das Ereignis ausgelöst, wenn der Ziel-Blob erfolgreich von der Archivebene in eine Online-Ebene (heiß, kühl oder kalt) geändert wird.

Wenn Sie den Vorgang "Blob kopieren " verwenden, um ein Blob aus der Archivebene in ein neues Ziel-Blob in einer Onlineebene (heiß, kühl oder kalt) für die Rehydratation zu kopieren:

  1. Azure Event Grid löst ein Microsoft.Storage.BlobCreated Ereignis aus, wenn die Kopieroperation startet. Die Ebene des Blobs ist Archiv.

  2. Nachdem der Blob kopiert und rehydriert wurde, löst Azure Event Grid ein Microsoft.Storage.BlobTierChanged Ereignis aus, das den Wechsel von Archive auf die angegebene Online-Stufe anzeigt.

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.

Für weitere Informationen zur Handhabung von Ereignissen in Blob Storage siehe Reacting to Azure Blob storage events und Azure Blob Storage as Event Grid source.

Preise und Abrechnung

Für Set Blob Tier erhebt Azure Storage Gebühren für Datenlesetransaktionen und die Menge der abgerufenen Daten. Die Rehydrierung mit hoher Priorität kostet mehr als eine Rehydrierung mit Standardpriorität und wird auf Ihrer Rechnung als separater Posten aufgeführt. Wenn eine hochprioritäre Anfrage für einen archivierten Blob kleiner als 10 GB mehr als fünf Stunden dauert, berechnet Azure Storage nicht die hochprioritäre Abrufrate. Standard-Rückfindungsraten gelten weiterhin. Eine Beispielkostenschätzung finden Sie unter Kostenschätzung: Verschieben von Daten aus dem Archivspeicher.

Für Copy Blob berechnet Azure Storage für Datenlesetransaktionen, die Menge der abgerufenen Daten und Datenschreibtransaktionen für den Ziel-Blob. Frühzeitige Löschgebühren fallen nicht an, da der Quellblob im Archiv-Tier unverändert bleibt. Bei Auswahl fallen hochprioritäre Abrufgebühren an. Eine Beispielschätzung finden Sie unter Kostenschätzung: Abrufen von Daten aus dem Archivspeicher für die Analyse.

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 in die Archivstufe verschoben und dann nach 45 Tagen gelöscht oder in die Hot-Stufe zurückverschoben wird, wird eine Gebühr für vorzeitiges Löschen in Höhe der Kosten für 135 (180 minus 45) Tage Speicherung dieses Blobs in der Archivstufe fällig. Weitere Informationen finden Sie unter Zugriffsebene „Archiv“.

Weitere Informationen zur Preisgestaltung von Blockblobs und Datenrehydration finden Sie unter Azure Storage pricing. Weitere Informationen zu ausgehenden Datenübertragungsgebühren finden Sie unter Details zu Datenübertragungspreisen.

Weitere Informationen

  • Zuletzt aktualisiert um