Optimieren von Kosten durch automatisches Verwalten des Datenlebenszyklus

Datasets haben eindeutige Lebenszyklen. Früh im Lebenszyklus greifen Benutzer häufig auf einige Daten zu. Aber häufig sinkt der Zugriffsbedarf mit zunehmendem Alter der Daten drastisch. Außerdem gibt es Daten, die in der Cloud lediglich vorgehalten werden und auf die nach der Speicherung nur selten zugegriffen wird. Einige Daten laufen Tage oder Monate nach der Erstellung ab, während andere Daten im Verlauf ihrer gesamten Lebensdauer aktiv gelesen und geändert werden. Die Azure Storage-Lebenszyklusverwaltung bietet eine regelbasierte Richtlinie, mit deren Hilfe Sie den Übergang von Blob-Daten auf die optimalen Zugriffsebenen und den Ablauf der Daten am Ende des Datenlebenszyklus umsetzen können.

Hinweis

Jede letzte Aktualisierung zur Zugriffszeit wird als „andere Transaktion“ höchstens einmal alle 24 Stunden pro Objekt selbst dann in Rechnung gestellt, wenn an einem Tag 1.000 mal darauf zugegriffen wird. Dies erfolgt getrennt von den Gebühren für Lesetransaktionen.

Mit der Richtlinie für die Lebenszyklusverwaltung können Sie die folgenden Aufgaben ausführen:

  • Sofortiger Übergang von kalten zu heißen Blobs, wenn darauf zugegriffen wird, um die Leistung zu optimieren.
  • Übergang von aktuellen Blobversionen, vorherigen Blobversionen oder Blobmomentaufnahmen zu einer kälteren Speicherebene, wenn für einen bestimmten Zeitraum nicht darauf zugegriffen wurde bzw. keine Änderungen vorgenommen wurden, um die Kosten zu optimieren. In diesem Szenario kann die Lebenszyklusverwaltungsrichtlinie Objekte von „Heiß“ zu „Kalt“, von „Heiß“ in „Archiv“ oder von „Kalt“ in „Archiv“ verschieben.
  • Löschen von aktuellen Blobversionen, vorherigen Blobversionen oder Blobmomentaufnahmen am Ende ihres Lebenszyklus.
  • Definieren von Regeln, die einmal täglich auf Speicherkontoebene ausgeführt werden
  • Anwendung von Regeln auf Container oder eine Teilmenge von Blobs (mit Namenspräfixen oder Blob-Indextags als Filter).

Stellen Sie sich ein Szenario vor, bei dem in den frühen Stages des Lebenszyklus häufig auf Daten zugegriffen wird, nach zwei Wochen aber nur noch gelegentlich. Nach dem ersten Monat wird auf das Dataset nur noch selten zugegriffen. In diesem Szenario empfiehlt sich in den frühen Phasen heißer Speicher. Die kalte Speicherebene eignet sich am besten für den gelegentlichen Zugriff. Die Archivspeicherebene ist die beste Option, wenn die Daten mehr als einen Monat alt sind. Indem Sie Daten basierend auf ihrem Alter mit Richtlinienregeln für die Lebenszyklusverwaltung auf die entsprechende Speicherebene verschieben, können Sie die kostengünstigste Lösung für Ihre Anforderungen entwerfen.

Lebenszyklusverwaltungsrichtlinien werden für Blockblobs und Anfügeblobs in Konten vom Typ „Allgemein v2“, „Premium-Blockblob“ und „Blob Storage“ unterstützt. Die Lebenszyklusverwaltung hat keinen Einfluss auf Systemcontainer wie die $logs oder $web-Container.

Wichtig

Wenn ein DataSet lesbar sein muss, legen Sie keine Richtlinie zum Verschieben von Blobs auf die Archivebene fest. Blobs auf der Archivebene können nur gelesen werden, wenn sie zum ersten Mal aktiviert werden. Dies ist ein Prozess, der zeitaufwändig und teuer sein kann. Weitere Informationen finden Sie unter Übersicht über die Aktivierung von Blobs aus der Archivebene.

Definition der Richtlinie zur Lebenszyklusverwaltung

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": {...}
    }
  ]
}

Eine Richtlinie ist eine Sammlung von Regeln, wie in der folgenden Tabelle beschrieben:

Parametername Parametertyp Notizen
rules 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 Parametertyp Notizen Erforderlich
name String Ein Regelname kann bis zu 256 alphanumerische Zeichen enthalten. Bei Regelnamen wird die Groß-/Kleinschreibung unterschieden. Er muss innerhalb einer Richtlinie eindeutig sein. True
enabled Boolean Ein optionaler boolescher Wert, über den eine Regel temporär deaktiviert werden kann. Der Standardwert ist „True“, wenn dieser Wert nicht festgelegt wurde. False
type Ein Enumerationswert Aktuell ist Lifecycle der gültige Typ. True
definition Ein Objekt, das die Lebenszyklusregel definiert Jede Definition beinhaltet einen Filtersatz und einen Aktionssatz. True

Definition der Lebenszyklusverwaltungsregel

Jede Regeldefinition innerhalb einer Richtlinie enthält einen Filtersatz und einen Aktionssatz. Der Filtersatz schränkt Regelaktionen auf eine bestimmte Menge von Objekten innerhalb eines Containers oder auf Objektnamen ein. Der Aktionssatz wendet die Ebenen- oder Löschaktionen auf den gefilterten Satz von Objekten an.

Beispielregel

Mit der folgenden Beispielregel wird das Konto so gefiltert, dass Aktionen für Objekte ausgeführt werden, die sich in sample-container befinden und mit blob1 beginnen.

  • Blob 30 Tage nach der letzten Änderung in die kalte Ebene verschieben
  • Blob 90 Tage nach der letzten Änderung in die Archivebene verschieben
  • Blob 2.555 Tage (sieben Jahre) nach der letzten Änderung löschen
  • Löschen vorheriger Versionen 90 Tage nach der Erstellung
{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

Hinweis

Das Element baseBlob in einer Richtlinie für die Lebenszyklusverwaltung bezieht sich auf die aktuelle Version eines Blobs. Das Element version verweist auf eine vorherige Version.

Regelfilter

Filter schränken Regelaktionen auf eine Teilmenge der Blobs innerhalb des Speicherkontos ein. Wenn mehrere Filter definiert sind, wird ein logisches AND für alle Filter ausgeführt.

Filter umfassen Folgendes:

Filtername Filtertyp Notizen Ist erforderlich
blobTypes Ein Array von vordefinierten Enumerationswerten. In der aktuellen Version werden blockBlob und appendBlob unterstützt. Für appendBlob werden nur Blobs zum Löschen unterstützt, festgelegte Ebenen dagegen nicht. Ja
prefixMatch Ein Array von Zeichenfolgen für Präfixe, die abgeglichen werden sollen. Jede Regel kann bis zu zehn Präfixe definieren, bei denen die Groß- und Kleinschreibung beachtet wird. Eine Präfixzeichenfolge muss mit einem Containernamen beginnen. Wenn Sie für eine Regel beispielsweise eine Übereinstimmung mit allen Blobs unter „https://myaccount.blob.core.windows.net/sample-container/blob1/...“ erzielen möchten, lautet der prefixMatch-Wert sample-container/blob1. Wenn Sie prefixMatch nicht definieren, gilt die Regel für alle Blobs im Speicherkonto. Nein
blobIndexMatch Ein Array von Wörterbuchwerten, die aus dem Blobindextag-Schlüssel und den Wertbedingungen bestehen, die abgeglichen werden sollen. In jeder Regel können bis zu 10 Blobindextag-Bedingungen definiert werden. Wenn Sie beispielsweise alle Blobs mit Project = Contoso unter https://myaccount.blob.core.windows.net/ für eine Regel abgleichen möchten, lautet der blobIndexMatch-Wert {"name": "Project","op": "==","value": "Contoso"}. Wenn Sie blobIndexMatch nicht definieren, gilt die Regel für alle Blobs im Speicherkonto. Nein

Weitere Informationen zum Blob-Index-Feature sowie zu bekannten Problemen und Einschränkungen finden Sie unter Verwalten und Suchen von Daten in Azure Blob Storage mit Blob-Index.

Regelaktionen

Aktionen werden auf die gefilterten Blobs angewandt, wenn die Ausführungsbedingung erfüllt ist.

Die Lebenszyklusverwaltung unterstützt das Tiering und das Löschen von aktuellen Versionen, vorherigen Versionen und Blobmomentaufnahmen. Definieren Sie mindestens eine Aktion für jede Regel.

Hinweis

Das Tiering wird in einem Premium-Blockblob-Speicherkonto noch nicht unterstützt. Für alle anderen Konten ist das Tiering nur für Blockblobs und nicht für Anfüge- und Seitenblobs zulässig.

Aktion Aktuelle Version Momentaufnahme Frühere Versionen
tierToCool Unterstützt für blockBlob Unterstützt Unterstützt
enableAutoTierToHotFromCool Unterstützt für blockBlob Nicht unterstützt Nicht unterstützt
tierToArchive Unterstützt für blockBlob Unterstützt Unterstützt
Löschen1 Für blockBlob und appendBlob unterstützt Unterstützt Unterstützt

1 Wenn ein Konto mit einem hierarchischen Namespace aktiviert ist, entfernt eine Löschaktion leere Verzeichnisse. Wenn das Verzeichnis nicht leer ist, werden die Objekte, die die Bedingungen der Richtlinie erfüllen, innerhalb des ersten 24-Stunden-Zyklus 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 24-Stunden-Zyklus entfernt, und so weiter.

Hinweis

Wenn für das gleiche Blob mehrere Aktionen definiert sind, wendet die Lebenszyklusverwaltung die am wenigsten teure Aktion auf das Blob an. Beispielsweise ist die Aktion delete kostengünstiger als die Aktion tierToArchive. Die Aktion tierToArchive ist kostengünstiger als die Option tierToCool.

Die Ausführungsbedingungen basieren auf dem Alter. 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.

Aktionsausführungsbedingung Wert der Bedingung BESCHREIBUNG
daysAfterModificationGreaterThan Ganzzahliger Wert, der das Alter in Tagen angibt Die Bedingung für Aktionen für eine aktuelle Version eines Blobs
daysAfterCreationGreaterThan Ganzzahliger Wert, der das Alter in Tagen angibt Die Bedingung für Aktionen für eine vorherige Version eines Blobs oder einer Blobmomentaufnahme
daysAfterLastAccessTimeGreaterThan Ganzzahliger Wert, der das Alter in Tagen angibt Die Bedingung für eine aktuelle Version eines Blobs, wenn die Zugriffsnachverfolgung aktiviert ist
daysAfterLastTierChangeGreaterThan Ganzzahliger Wert, der das Alter in Tagen nach der letzten Änderungszeit für die Blobebene angibt Diese Bedingung gilt nur für tierToArchive-Aktionen und kann nur bei der Bedingung daysAfterModificationGreaterThan verwendet werden.

Beispiele für Richtlinien für den Lebenszyklus

Die folgenden Beispiele veranschaulichen die Behandlung von gängigen Szenarien mithilfe von Regeln zur Lebenszyklusverwaltung.

Verschieben von alternden Daten auf eine kühlere Ebene

Dieses Beispiel zeigt den Übergang von Blockblobs mit dem Präfix sample-container/blob1 oder container2/blob2. Die Richtlinie überführt Blobs, die mehr als 30 Tage nicht verändert wurden, in den kalten Speicher und Blobs, die in 90 Tagen nicht verändert wurden, in die Archivebene:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Verschieben von Daten basierend auf dem Datum des letzten Zugriffs

Sie können die Nachverfolgung des letzten Zugriffs aktivieren, um zu erfassen, wann Ihr Blob zuletzt gelesen oder geschrieben wurde, und als Filter zum Verwalten des Tierings und der Aufbewahrung Ihrer Blobdaten. Informationen zum Aktivieren der Nachverfolgung des letzten Zugriffs finden Sie unter Optionales Aktivieren der Nachverfolgung der Zugriffszeit.

Wenn die Zeitüberwachung für den letzten Zugriff aktiviert ist, wird die Blobeigenschaft, mit der LastAccessTime aufgerufen wird, aktualisiert, wenn ein Blob gelesen oder beschrieben wird. Dabei gilt der Vorgang Get Blob als Zugriff. Get Blob Properties, Get Blob Metadata und Get Blob Tags gelten nicht als Zugriff. Daher wird bei diesen Vorgängen die Uhrzeit des letzten Zugriffs nicht aktualisiert.

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.

Im nachstehenden Beispiel werden Blobs in den kalten Speicher verschoben, wenn auf sie während 30 Tagen nicht zugegriffen wurde. Bei der enableAutoTierToHotFromCool-Eigenschaft handelt es sich um einen booleschen Wert, der angibt, ob für einen Blob automatisch ein Tiering von der kalten Ebene zurück zur heißen Ebene durchgeführt werden soll, wenn nach dem Tiering auf die kalte Ebene noch mal auf den Blob zugegriffen wird.

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

Archivieren von Daten nach der Erfassung

Außerdem gibt es Daten, die in der Cloud lediglich vorgehalten werden und auf die nur sehr selten oder gar nicht zugegriffen wird. Die folgende Lebenszyklusrichtlinie ist so konfiguriert, dass Daten kurz nach der Erfassung archiviert werden. In diesem Beispiel werden Blockblobs im Container archivecontainer an eine Archivebene überführt. Der Übergang wird durch Ausführung der Aktion für Blobs 0 Tage nach dem Zeitpunkt der letzten Änderung erreicht.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

Hinweis

Microsoft empfiehlt, Ihre Blobs aus Effizienzgründen direkt auf die Archivebene hochzuladen. Sie können die Archivebene im Header x-ms-access-tier für den Vorgang Put Blob (Blob festlegen) oder Put Block List (Blockliste festlegen) angeben. Der Header x-ms-access-tier wird von der REST-Version 2018-11-09 und höher oder den neuesten Blobspeicher-Clientbibliotheken unterstützt.

Ablauf von Daten nach dem Alter

Für einige Daten wird erwartet, dass sie einige Tage oder Monate nach der Erstellung ablaufen. Sie können eine Richtlinie zur Lebenszyklusverwaltung so einrichten, dass Daten durch Löschung auf der Grundlage ihres Alters ablaufen. Das folgende Beispiel zeigt eine Richtlinie, die alle Blockblobs löscht, die in den letzten 365 Tagen nicht geändert wurden.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Löschen von Daten mit Blobindextags

Einige Daten sollten nur ablaufen, wenn sie explizit zur Löschung gekennzeichnet sind. Sie können eine Lebenszyklusverwaltungsrichtlinie so konfigurieren, dass Daten ablaufen, die mit Schlüssel-Wert-Attributen für den Blobindex gekennzeichnet sind. Im folgenden Beispiel ist eine Richtlinie dargestellt, mit der alle Blockblobs gelöscht werden, die mit Project = Contoso gekennzeichnet sind. Weitere Informationen zum Blobindex finden Sie unter Verwalten und Suchen von Daten in Azure Blob Storage mit dem Blobindex.

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Verwalten früherer Versionen

Für Daten, die während ihrer gesamten Lebensdauer regelmäßig geändert werden und auf die regelmäßig zugegriffen wird, können Sie die Blob Storage-Versionsverwaltung aktivieren, um frühere Versionen eines Objekts automatisch zu verwalten. Sie können eine Richtlinie erstellen, um frühere Versionen Ebenen zuzuordnen oder zu löschen. Das Alter der Version wird durch Auswertung der Erstellungszeit der Version bestimmt. Entsprechend dieser Richtlinienregel werden frühere Versionen innerhalb des Containers activedata, die 90 Tage oder älter sind (nach der Versionserstellung), der Ebene „kalt“ zugeordnet und frühere Versionen, die 365 Tage oder älter sind, gelöscht.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata"
          ]
        }
      }
    }
  ]
}

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 Unterstützung von Blob Storage-Features in Azure Storage-Konten, um die Unterstützung für dieses Feature zu bewerten.

Regionale Verfügbarkeit und Preise

Die Funktion zur Lebenszyklusverwaltung ist in allen Azure-Regionen verfügbar.

Richtlinien für die Lebenszyklusverwaltung sind kostenlos. Kunden werden die regulären Betriebskosten für die Set Blob Tier (Blobebene festlegen)-API-Aufrufe in Rechnung gestellt. Löschvorgänge sind kostenfrei. Andere Azure-Dienste und -Dienstprogramme wie Microsoft Defender für Storage können jedoch Vorgänge berechnen, die über eine Lebenszyklusrichtlinie verwaltet werden.

Jede Aktualisierung der letzten Zugriffszeit auf einen Blob wird unter der Kategorie andere Vorgänge abgerechnet.

Weitere Informationen zu den Preisen finden Sie unter Preise für Blockblobs.

Häufig gestellte Fragen

Ich habe eine neue Richtlinie erstellt. Warum werden die Aktionen nicht sofort ausgeführt?

Die Plattform führt die Lebenszyklusrichtlinie ein Mal täglich aus. Nachdem Sie eine Richtlinie konfiguriert haben, kann es bis zu 24 Stunden dauern, bis sie wirksam wird. Sobald die Richtlinie gültig ist, kann es bis zu 24 Stunden dauern, bis alle Aktionen zum erstem Mal ausgeführt werden.

Wie lange dauert es nach dem Aktualisieren einer vorhandenen Richtlinie, bis die Aktionen ausgeführt werden?

Es dauert bis zu 24 Stunden, bis die aktualisierte Richtlinie in Kraft tritt. Sobald die Richtlinie gültig ist, kann es bis zu 24 Stunden dauern, bis die Aktionen ausgeführt werden. Daher kann der Abschluss von Richtlinieaktionen bis zu 48 Stunden dauern. Wenn das Update eine Regel deaktivieren oder löschen soll und „enableAutoTierToHotFromCool“ verwendet wurde, wird dennoch das automatische Tiering auf die heiße Speicherebene durchgeführt. Legen Sie beispielsweise basierend auf dem letzten Zugriff eine Regel einschließlich „enableAutoTierToHotFromCool“ fest. Wenn die Regel deaktiviert oder gelöscht wird, sich ein Blob derzeit auf der kalten Speicherebene befindet und dann darauf zugegriffen wird, wird er wieder auf die heiße Speicherebene zurückgesetzt, da diese für den Zugriff außerhalb der Lebenszyklusverwaltung verwendet wird. Das Blob wird dann nicht von der heißen auf die kalte Speicherebene verschoben, da die Regel für die Lebenszyklusverwaltung deaktiviert bzw. gelöscht wurde. Die einzige Möglichkeit, „autoTierToHotFromCool“ zu verhindern, besteht darin, die Nachverfolgung des letzten Zugriffszeitpunkts zu deaktivieren.

Ich habe ein archiviertes Blob aktiviert. Wie kann ich verhindern, dass es vorübergehend zurück auf die Archivspeicherebene verschoben wird?

Wenn eine Lebenszyklusverwaltungsrichtlinie für das Speicherkonto wirksam ist, kann die Aktivierung eines Blobs durch Ändern von deren Ebene zu einem Szenario führen, bei dem die Richtlinie das Blob zurück auf die Archivspeicherebene verschiebt. Dies kann geschehen, wenn der Zeitpunkt der letzten Änderung, der Erstellungszeitpunkt oder die letzte Zugriffszeit den für die Richtlinie festgelegten Schwellenwert überschreitet. Es gibt drei Möglichkeiten, dies zu verhindern:

  • Fügen Sie die Bedingung daysAfterLastTierChangeGreaterThan zur Aktion „tierToArchive“ der Richtlinie hinzu. Diese Bedingung gilt nur für den Zeitpunkt der letzten Änderung. Lesen Sie dazu Verwenden von Richtlinien für die Lebenszyklusverwaltung zum Archivieren von Blobs.

  • Deaktivieren Sie vorübergehend die Regel, die sich auf dieses Blob auswirkt, um zu verhindern, dass es erneut archiviert wird. Aktivieren Sie die Regel erneut, wenn das Blob sicher zurück auf die Archivspeicherebene verschoben werden kann.

  • Wenn das Blob dauerhaft auf der heißen oder kalten Ebene bleiben muss, kopieren Sie es an einen anderen Speicherort, an dem die Lebenszyklusverwaltungsrichtlinie nicht wirksam ist.

Der Blob-Präfix-Match-String hat die Richtlinie nicht auf die erwarteten Blobs angewendet

Das Blobpräfix-Abgleichsfeld einer Richtlinie ist ein vollständiger oder partieller Blobpfad, der verwendet wird, um die Blobs abzugleichen, auf die die Richtlinienaktionen angewendet werden sollen. Der Pfad muss mit dem Namen des Containers beginnen. Wenn kein Präfixabgleich angegeben wird, gilt die Richtlinie für alle Blobs im Speicherkonto. Das Format der Präfix-Übereinstimmungszeichenfolge lautet [container name]/[blob name].

Beachten Sie die folgenden Punkte zum Präfix match string:

  • Eine Präfix-Übereinstimmungszeichenfolge wie container1/ gilt für alle Blobs im Container namens "container1". Eine Präfix-Übereinstimmungszeichenfolge von Container1, ohne das schräge Schrägstrichzeichen (/) gilt für alle Blobs in allen Containern, in denen der Containername mit dem Zeichenfolgencontainer1 beginnt. Das Präfix entspricht Containern namens "container11", "container1234", "container1ab" usw.
  • Eine Präfixüberstimmungszeichenfolge von container1/sub1/ gilt für alle Blobs im Container namens Container1 , die mit der Zeichenfolge sub1/beginnen. Das Präfix entspricht beispielsweise Blobs namens container1/sub1/test.txt oder container1/sub1/sub1/sub2/test.txt.
  • Das Zeichen „Sternchen“ (*) ist ein gültiges Zeichen für einen Blobnamen. Wenn das Sternchen in einem Präfix verwendet wird, stimmt das Präfix blobs mit einem Sternchen in ihren Namen überein. Das Sternchen funktioniert nicht als Wildcardzeichen.
  • Das Fragezeichen (?) ist ein gültiges Zeichen für einen Blobnamen. Wenn das Fragezeichen in einem Präfix verwendet wird, stimmt das Präfix blobs mit einem Fragezeichen in ihren Namen überein. Das Fragezeichen funktioniert nicht als Wildcardzeichen.
  • Die Präfixvergleiche betrachten nur positive (=) logische Vergleiche. Daher werden negative (!=) logische Vergleiche ignoriert.

Gibt es eine Möglichkeit, den Zeitpunkt zu identifizieren, zu dem die Richtlinie ausgeführt wird?

Leider gibt es keine Möglichkeit, den Zeitpunkt nachzuverfolgen, zu dem die Richtlinie ausgeführt wird, da es sich um einen Hintergrundplanungsprozess handelt. Die Plattform führt die Richtlinie jedoch einmal pro Tag aus.

Nächste Schritte