Richtlinienstruktur für die Azure Blob Storage-Lebenszyklusverwaltung

2025-06-16

Sie können Lebenszyklusverwaltungsrichtlinien verwenden, um Blobs basierend auf ihren Verwendungsmustern auf kosteneffiziente Zugriffsebenen umzustellen. Sie können Blobs auch vollständig am Ende ihres Lebenszyklus löschen. Eine Richtlinie kann auf aktuellen Versionen, früheren Versionen und Momentaufnahmen ausgeführt werden, aber eine Richtlinie funktioniert nicht auf Blobs in Systemcontainern wie dem $logs oder $web Containern. Allgemeine Informationen finden Sie in der Übersicht über die Azure Blob Storage-Lebenszyklusverwaltung.

In diesem Artikel werden die Elemente einer Lifecycle Management-Richtlinie beschrieben. Beispiele für Richtlinien finden Sie in den folgenden Artikeln:

Tipp

Während die Lebenszyklusverwaltung Ihnen hilft, Ihre Kosten für ein einzelnes Konto zu optimieren, können Sie Azure Storage-Aktionen verwenden, um mehrere Datenvorgänge über mehrere Konten hinweg auszuführen.

Regeln

Eine Richtlinie zur Lebenszyklusverwaltung ist eine Sammlung von Regeln in einem JSON-Dokument. Das folgende JSON-Beispiel zeigt eine vollständige Regeldefinition:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

Parametername	Parametertyp	Hinweise
Regeln	Ein Array von Regelobjekten	Eine Richtlinie muss mindestens eine Regel enthalten. Sie können in einer Richtlinie bis zu 100 Regeln definieren.

Jede Regel innerhalb der Richtlinie verfügt über mehrere Parameter, die in der folgenden Tabelle beschrieben werden:

Parametername	Typ	Hinweise	Erforderlich
Name	Schnur	Ein Regelname kann bis zu 256 alphanumerische Zeichen enthalten. Bei dem Regelnamen wird die Groß-/Kleinschreibung beachtet. Er muss innerhalb einer Richtlinie eindeutig sein.	Ja
aktivierte	Boolescher Typ (Boolean)	Ein optionaler boolescher Wert, über den eine Regel temporär deaktiviert werden kann. Der Standardwert ist true.	Nein
Typ	Ein Enumerationswert	Aktuell ist `Lifecycle` der gültige Typ.	Ja
Definition	Ein Objekt, das die Lebenszyklusregel definiert	Jede Definition beinhaltet einen Filtersatz und einen Aktionssatz.	Ja

Filter

Filter beschränken Aktionen auf eine Teilmenge von Blobs innerhalb des Speicherkontos. Sie können einen Filter verwenden, um anzugeben, welche Blobs einbezogen werden sollen. Mit Filtern können Sie nicht angeben, welche Blobs ausgeschlossen werden sollen. Wenn mehr als ein Filter definiert ist, wird ein logisches AND auf alle Filter angewendet. In der folgenden Tabelle werden die einzelnen Parameter beschrieben.

Filtername	Typ	BESCHREIBUNG	Erforderlich
blobTypes	Ein Array von vordefinierten Enumerationswerten.	Der Typ des Blobs ( entweder blockblob oder appendBlob)	Ja
prefixMatch	Array von Zeichenfolgen	Diese Zeichenfolgen sind Präfixe, die abgeglichen werden sollen.	Nein
blobIndexMatch	Ein Array von Wörterbuchwerten	Diese Werte bestehen aus einem Blob-Index-Tagschlüssel und zu erfüllenden Wertbedingungen.	Nein

Präfix-Übereinstimmungsfilter

Wenn Sie den PrefixMatch-Filter anwenden, kann jede Regel bis zu 10 case-sensitive Präfixe definieren. Eine Präfixzeichenfolge muss mit einem Containernamen beginnen. Wenn Sie beispielsweise alle Blobs unter dem Pfad https://myaccount.blob.core.windows.net/sample-container/blob1/... abgleichen möchten, geben Sie den prefixMatch als sample-container/blob1 an.

Dieser Filter stimmt mit allen Blobs in sample-container überein, deren Namen mit blob1 beginnen. Wenn Sie keine Präfix-Übereinstimmung definieren, gilt die Regel für alle Blobs innerhalb des Speicherkontos. Präfixzeichenfolgen unterstützen keinen Wildcardabgleich. Zeichen wie * und ? werden als Zeichenfolgenliterale behandelt.

Blobindex-Übereinstimmungsfilter

Wenn Sie den blobIndexMatch-Filter anwenden, kann jede Regel bis zu 10 BLOB-Indextagbedingungen definieren. Wenn Sie beispielsweise alle Blobs mit Project = Contoso unter https://myaccount.blob.core.windows.net/ abgleichen möchten, verwenden Sie den blobIndexMatch Filter {"name": "Project","op": "==","value": "Contoso"}. Wenn Sie keinen Wert für den blobIndexMatch-Filter definieren, gilt die Regel für alle Blobs innerhalb des Speicherkontos.

Aktionen

Sie müssen mindestens eine Aktion für jede Regel definieren. Aktionen werden auf die gefilterten Blobs angewandt, wenn die Ausführungsbedingung erfüllt ist. Weitere Informationen zu Ausführungsbedingungen finden Sie im Abschnitt " Aktionsausführungsbedingungen " in diesem Artikel. In der folgenden Tabelle werden die einzelnen Aktionen beschrieben, die in einer Richtliniendefinition verfügbar sind.

Maßnahme	BESCHREIBUNG
TierToCool	Legen Sie einen Blob auf die kalte Zugriffsebene fest. Wird bei Anfügeblobs, Seitenblobs oder Blobs in einem Premium-Blockblob-Speicherkonto nicht unterstützt.
TierToCold	Legen Sie einen Blob auf die kalte Zugriffsebene fest. Wird bei Anfügeblobs, Seitenblobs oder Blobs in einem Premium-Blockblob-Speicherkonto nicht unterstützt.
TierToArchive	Setzen Sie ein Blob auf die Zugriffsstufe "Archiv". Durch die Aktivierung eines Blobs wird die Eigenschaft der letzten Änderung oder der letzten Zugriffszeit des Blobs nicht aktualisiert. Daher kann diese Aktion aktivierte Blobs zurück in die Archivebene verschieben. Um dies zu verhindern, fügen Sie dieser Aktion die `daysAfterLastTierChangeGreaterThan` Bedingung hinzu. Diese Aktion wird nicht für Anfügeblobs, Seitenblobs oder für Blobs in einem Premium-Blockblob-Speicherkonto unterstützt. Sie wird auch nicht für Blobs unterstützt, die einen Verschlüsselungsbereich verwenden oder für Blobs in Konten, die für zonenredundant Speicher (ZRS), geozonenredundante Speicher (GZRS)/geozonenredundante Speicher mit Lesezugriff (RA-GZRS) konfiguriert sind.
enableAutoTierToHotFromCool	Wenn ein Blob auf die coole Ebene festgelegt ist, verschiebt diese Aktion dieses Blob automatisch in die heiße Ebene, wenn auf das Blob zugegriffen wird. Diese Aktion ist nur verfügbar, wenn sie mit der Ausführungsbedingung daysAfterLastAccessTimeGreaterThan verwendet wird. Diese Aktion hat keine Auswirkungen auf Blobs, die vor dem Aktivieren dieser Aktion in einer Regel auf die kalte Ebene festgelegt wurden. Diese Aktion verschiebt Blobs nur einmal in 30 Tagen von kühl auf heiß. Dieser Schutz wird eingerichtet, um vor mehreren vorzeitigen Löschungsstrafen zu schützen, die dem Konto in Rechnung gestellt werden. Wird bei früheren Versionen oder Momentaufnahmen nicht unterstützt.
Löschen	Löscht ein Blob. Wird bei Seitenblobs oder Blobs in einem unveränderlichen Container nicht unterstützt.

Wenn Sie mehrere Aktionen für dasselbe Blob definieren, wendet die Lebenszyklusverwaltung die am wenigsten kostspielige Aktion auf das Blob an. Eine Löschaktion ist z. B. günstiger als die Aktion "tierToArchive ", und die Aktion "tierToArchive " ist günstiger als die tierToCool-Aktion .

Löschen einer Aktion in Konten mit einem hierarchischen Namespace

Wenn sie auf ein Konto mit aktiviertem hierarchischen Namespace angewendet wird, entfernt eine Löschaktion leere Verzeichnisse. Wenn das Verzeichnis nicht leer ist, werden Objekte, die die Bedingungen der Richtlinie erfüllen, innerhalb des ersten Ausführungszyklus der Lebenszyklusrichtlinie gelöscht. Wenn diese Aktion zu einem leeren Verzeichnis führt, das ebenfalls die Bedingungen der Richtlinie erfüllt, wird dieses Verzeichnis innerhalb des nächsten Ausführungszyklus entfernt usw.

Löschen einer Aktion für Blobs mit Versionen und Momentaufnahmen

Eine Lifecycle-Verwaltungsrichtlinie löscht die aktuelle Version eines Blobs erst, wenn frühere Versionen oder Momentaufnahmen, die diesem Blob zugeordnet sind, gelöscht wurden. Wenn Blobs in Ihrem Speicherkonto über frühere Versionen oder Momentaufnahmen verfügen, müssen Sie frühere Versionen und Momentaufnahmen einschließen, wenn Sie eine Löschaktion als Teil der Richtlinie angeben.

Aktionsausführungsbedingung

Alle Ausführungsbedingungen sind zeitbasiert. Wenn die Anzahl der Tage, die vergangen sind, die Anzahl überschreitet, die für die Bedingung angegeben ist, kann die zugeordnete Aktion ausgeführt werden. Richtlinienbedingungen werden für jedes Objekt nur einmal während einer Richtlinienausführung bewertet. In einigen Fällen kann ein Objekt die Bedingung erfüllen, nachdem es bereits von einer Ausführung bewertet wurde. Solche Objekte werden in nachfolgenden Ausführungen verarbeitet.

Aktuelle Versionen verwenden den Zeitpunkt der letzten Änderung oder des letzten Zugriffs, vorherige Versionen verwenden den Erstellungszeitpunkt der Version, und Blobmomentaufnahmen verwenden den Erstellungszeitpunkt der Momentaufnahme, um das Alter nachzuverfolgen.

In der folgenden Tabelle werden die einzelnen Aktionsausführungsbedingungen beschrieben.

Bedingungsname	Typ	BESCHREIBUNG
daysAfterModificationGreaterThan	Ganze Zahl	Das Alter in Tagen nach dem letzten geänderten Zeitblob. Gilt für Aktionen in einer aktuellen Version eines Blobs.
daysAfterCreationGreaterThan	Ganze Zahl	Das Alter in Tagen nach der Erstellungszeit. Gilt für Aktionen auf der aktuellen Version eines Blobs, der vorherigen Version eines Blobs oder einer Blob-Momentaufnahme.
daysAfterLastAccessTimeGreaterThan	Ganze Zahl	Das Alter in Tagen seit der letzten Zugriffszeit oder in einigen Fällen seit dem Datum, an dem die Richtlinie aktiviert wurde. Weitere Informationen finden Sie im Abschnitt zur Zeitverfolgung in Access weiter unten. Gilt für Aktionen auf der aktuellen Version eines Blobs, sobald die Zugriffsnachverfolgung aktiviert ist.
daysAfterLastTierChangeGreaterThan	Ganze Zahl	Das Alter in Tagen nach der letzten Änderung der Blobebene. Die Mindestdauer in Tagen, in denen ein aktivierter Blob in heißen, kühlen oder kalten Ebenen aufbewahrt wird, bevor er in die Archivebene zurückgegeben wird. Gilt nur für tierToArchive-Aktionen .

Zugriffszeiterfassung

Sie können die Zugriffszeitverfolgung aktivieren, um aufzuzeichnen, wann Ihr Blob zuletzt gelesen oder geschrieben wurde, und als Filter zur Verwaltung der Dateneinstufung und Aufbewahrung Ihrer BLOB-Daten verwenden.

Wenn Sie die Zugriffszeitnachverfolgung aktivieren, wird eine BLOB-Eigenschaft namens LastAccessTime aktualisiert, sobald ein Blob gelesen oder geschrieben wird. Die Vorgänge "Blob abrufen " und "Put Blob " sind Zugriffsvorgänge und aktualisieren die Zugriffszeit eines Blobs. Die Get Blob-Eigenschaften, Get Blob Metadata und Get Blob Tags sind jedoch keine Zugriffsvorgänge. Diese Vorgänge aktualisieren nicht die Zugriffszeit eines Blobs.

Wenn Sie die Ausführungsbedingung daysAfterLastAccessTimeGreaterThan auf eine Richtlinie anwenden, wird LastAccessTime verwendet, um zu bestimmen, ob diese Bedingung erfüllt ist.

Wenn Sie die Ausführungsbedingung daysAfterLastAccessTimeGreaterThan auf eine Richtlinie anwenden, aber die Zugriffszeiterfassung nicht aktiviert haben, dann wird LastAccessTime nicht verwendet. Das Datum, an dem die Lifecycle-Richtlinie aktiviert wurde, wird stattdessen verwendet. Tatsächlich wird das Datum, an dem die Lifecycle-Richtlinie aktiviert wurde, in jeder Situation verwendet, in der die LastAccessTime Eigenschaft des Blobs ein NULL-Wert ist. Dies kann sogar dann geschehen, wenn Sie die Verfolgung der Zugriffszeiten aktiviert haben, in Fällen, in denen auf ein Blob seit der Aktivierung nicht zugegriffen wurde.

Hinweis

Um die Auswirkungen auf die Lesezugriffswartezeit zu minimieren, wird die Uhrzeit des letzten Zugriffs nur beim ersten Lesezugriff der letzten 24 Stunden aktualisiert. Bei nachfolgenden Lesezugriffen innerhalb desselben 24-Stunden-Zeitraums wird die Uhrzeit des letzten Zugriffs nicht aktualisiert. Wenn ein Blob zwischen zwei Lesezugriffen geändert wird, ist die Uhrzeit des letzten Zugriffs die aktuellere der beiden Werte.

Informationen zum Aktivieren der Zugriffszeitverfolgung finden Sie unter Optional aktivieren Sie die Zugriffszeitverfolgung.

Freigeben über