Azure Storage-Blobbestand

Das Azure Storage Blob-Inventar listet die Container, Blobs, Blob-Versionen, Snapshots und zugehörigen Eigenschaften in Ihrem Speicherkonto auf. Der Dienst erstellt täglich oder wöchentlich Berichte im Komma-getrennten Wertenformat (CSV) oder im Apache-Parquet-Format.

Verwenden Sie Bestandsberichte, um die Aufbewahrung, den rechtlichen Halt oder den Verschlüsselungsstatus Ihres Speicherkontos zu überprüfen. Sie können außerdem die Gesamtgröße, das Alter, die Stufenverteilung und andere Attribute Ihrer Daten analysieren.

Blob-Inventory kann Geschäftsabläufe vereinfachen und die Datenverarbeitung beschleunigen. Sie bietet die zeitgesteuerte Automatisierung der APIs List Containers und List Blobs. Inventarregeln filtern den Inhalt nach Blob-Typ, Präfix oder ausgewählten Blob-Eigenschaften.

Die Azure Storage Blob-Inventarisierung ist für die folgenden Arten von Speicherkonten verfügbar:

• Standard Allzweck v2
• Premium Blockblobspeicher
• Blobspeicher

Inventarfunktionen

Das Azure Storage Blob-Inventar unterstützt die folgenden Features und Funktionen.

• Bestandsberichte für Blobs und Container

  Sie können Inventurberichte für Blobs und Container erstellen. Ein Bericht für Blobs kann Basis-Blobs, Schnappschüsse, Inhaltslänge, Blob-Versionen und deren zugehörige Eigenschaften wie Erstellungszeit und letzte Änderungszeit enthalten. Der Bericht listet keine leeren Behälter auf. Ein Bericht zu Containern beschreibt Container und ihre zugeordneten Eigenschaften wie den Status der Richtlinie für die Unveränderlichkeit und den Legal-Hold-Status.

• Benutzerdefiniertes Schema

  Sie können auswählen, welche Felder im Bericht enthalten sind. Wählen Sie diese aus einer Liste unterstützter Felder aus. Die Liste finden Sie weiter unten in diesem Artikel.

• CSV- und Apache Parquet-Ausgabeformat

  Sie können den Inventurbericht entweder in einem CSV- oder einem Apache Parquet-Ausgabeformat erstellen.

• Manifestdatei und Azure Event Grid-Ereignis pro Inventurbericht

  Der Dienst generiert für jeden Inventarbericht eine Manifestdatei und ein Azure Event Grid-Ereignis. Der Artikel beschreibt diese Gegenstände später.

Aktivieren von Inventurberichten

Sie aktivieren Blobinventurberichte, indem Sie Ihrem Speicherkonto eine Richtlinie mit mindestens einer Regel hinzufügen. Weitere Anweisungen dazu finden Sie unter Aktivieren von Azure Storage-Blobinventurberichten.

Aktualisieren einer Inventurrichtlinie

Wenn Sie das Azure Storage Blob-Inventar vor Juni 2021 konfiguriert haben, laden Sie die Richtlinie ein, nehmen Sie alle notwendigen Änderungen vor und speichern Sie sie dann. Wenn Sie die Richtlinie neu laden, belegt der Dienst das regelbezogene Ziel, die Manifestdatei und die Azure Event Grid-Ereigniseinstellungen mit Standardwerten. Du kannst diese Werte ändern.

• Jede Regel unterstützt einen Zielcontainer, anstatt auf Richtlinienebene ein Ziel zu teilen.

• Der Dienst erzeugt für jede Regel eine Manifestdatei und ein Azure Event Grid-Ereignis statt für die Richtlinie.

Inventurrichtlinie

Um Inventarberichte zu konfigurieren, fügen Sie eine Bestandsrichtlinie mit einer oder mehreren Regeln zu einem JSON-Dokument hinzu.

{
  "enabled": true,
  "rules": [
  {
    "enabled": true,
    "name": "inventoryrule1",
    "destination": "inventory-destination-container",
    "definition": {
      "filters": {
        "blobTypes": ["blockBlob"]
      },
      "format": "csv",
      "objectType": "blob",
      "schedule": "daily",
      "schemaFields": ["Name"]
    }
  },
  {
    "enabled": true,
    "name": "inventoryrule2",
    "destination": "inventory-destination-container",
    "definition": {
      "filters": {},
      "format": "csv",
      "objectType": "container",
      "schedule": "weekly",
      "schemaFields": ["Name"]
    }
  }]
}

Sie können das JSON für eine Inventurrichtlinie anzeigen, indem Sie im Azure-Portal im Abschnitt Blobinventur die Registerkarte Codeansicht auswählen.

Parametername	Parametertyp	Notizen	Erforderlich?
enabled	boolean	Dient zum Deaktivieren der gesamten Richtlinie. Wenn auf true gesetzt, überschreibt das Feld auf Regelebene enabled diesen Parameter. Wenn deaktiviert, ist das Inventar für alle Regeln deaktiviert.	Ja
rules	Ein Array von Regelobjekten	Eine Richtlinie muss mindestens eine Regel enthalten. Pro Richtlinie werden bis zu 100 Regeln unterstützt.	Ja

Inventurregeln

Eine Regel erfasst die Filterbedingungen und Ausgabeparameter zum Erstellen eines Bestandsberichts. Jede Regel erstellt einen Bestandsbericht. Regeln können überlappende Präfixe aufweisen. Ein Blob kann abhängig von den Regeldefinitionen auch in mehreren Beständen enthalten sein.

Jede Regel in der Richtlinie umfasst mehrere Parameter:

Parametername	Parametertyp	Notizen	Erforderlich?
name	string	Ein Regelname kann bis zu 256 alphanumerische Zeichen (Groß-/Kleinschreibung beachten) enthalten. Der Name muss innerhalb einer Richtlinie eindeutig sein.	Ja
enabled	boolean	Ein Flag, um eine Regel zu aktivieren oder zu deaktivieren. Der Standardwert lautet true.	Ja
definition	JSON-Definition der Inventurregel	Jede Definition beinhaltet einen Regelfiltersatz.	Ja
destination	string	Der Zielcontainer, in dem der Dienst alle Inventardateien erzeugt. Der Zielcontainer muss bereits vorhanden sein.

Das globale Flag Blob inventory enabled (Blobinventur aktiviert) hat Vorrang vor dem enabled-Parameter in einer Regel.

Regeldefinition

Parametername	Parametertyp	Notizen	Erforderlich
filters	JSON	Filter bestimmen, ob ein Blob oder Container Teil des Inventars ist.	Ja
format	string	Bestimmt das Ausgabeformat der Inventardatei. Gültige Werte sind csv (für CSV-Format) und parquet (für Apache Parquet-Format).	Ja
objectType	string	Gibt an, ob die Inventarregel für Blobs oder Container gilt. Gültige Werte sind blob und container.	Ja
schedule	string	Legt fest, wann die Regel ausgeführt werden soll. Gültige Werte sind daily und weekly.	Ja
schemaFields	JSON-Array	Listet die Schema-Felder auf, die im Inventar aufgenommen werden sollen.	Ja

Regelfilter

Verwenden Sie die folgenden Filter, um einen Blob-Inventarbericht anzupassen:

Name des Filters	Filtertyp	Notizen	Erforderlich?
blobTypes	Array von vordefinierten Enum-Werten	Gültige Werte sind blockBlob und appendBlob für hierarchische, namensraumfähige Konten und blockBlob, appendBlob, sowie pageBlob für andere Konten. Dieses Feld gilt nicht für das Containerinventar (objectType: container).	Ja
creationTime	Number	Gibt an, vor wie vielen Tagen der Blob erstellt wurde. Zum Beispiel enthält ein Wert von 3 nur Blobs, die in den letzten drei Tagen erstellt wurden.	Nein
prefixMatch	Array mit bis zu 10 Zeichenfolgen	Wenn du prefixMatch nicht definierst oder ein leeres Präfix angibst, gilt die Regel für alle Blobs im Speicherkonto. Bei dem Präfix muss es sich um das Präfix eines Containernamens oder um einen Containernamen handeln. Zum Beispiel: container oder container1/foo.	Nein
excludePrefix	Array mit bis zu 10 Zeichenfolgen	Gibt die Blobpfade an, die aus dem Bestandsbericht ausgeschlossen werden sollen. Ein excludePrefix muss ein Containername-Präfix oder ein Containername sein. Mit einem leeren excludePrefixSymbol listet der Bericht alle Blobs mit Namen auf, die mit einer beliebigen Zeichenkette prefixMatch übereinstimmen. Um ein Präfix einzufügen, aber eine bestimmte Teilmenge auszuschließen, verwenden Sie den Filter excludePrefix . Zum Beispiel: Um alle Blobs unter container-a mit Ausnahme derer unter container-a/folder einzuschließen, setzen Sie prefixMatch auf container-a und excludePrefix auf container-a/folder.	Nein
includeSnapshots	boolean	Gibt an, ob das Inventar Schnappschüsse enthält. Der Standardwert lautet false. Dieses Feld gilt nicht für das Containerinventar (objectType: container).	Nein
includeBlobVersions	boolean	Gibt an, ob das Inventar Blob-Versionen enthält. Der Standardwert lautet false. Dieses Feld gilt nicht für das Containerinventar (objectType: container).	Nein
includeDeleted	boolean	Gibt an, ob das Inventar gelöschte Blobs enthält. Der Standardwert lautet false. In Konten mit hierarchischem Namensraum umfasst dieser Filter Ordner und Blobs im Soft-Deleted-Zustand. Nur explizit gelöschte Ordner und Dateien erscheinen in den Berichten. Unterordner und Dateien, die infolge des Löschens eines übergeordneten Ordners gelöscht wurden, sind nicht enthalten.	Nein

Sie zeigen den JSON-Code für Inventurrichtlinien an, indem Sie im Azure-Portal im Abschnitt Blob Inventory (Blobbestand) die Registerkarte Codeansicht auswählen. Du spezifizierst Filter innerhalb einer Regeldefinition.

{
  "destination": "inventory-destination-container",
  "enabled": true,
  "rules": [
  {
    "definition": {
      "filters": {
        "blobTypes": ["blockBlob", "appendBlob", "pageBlob"],
        "prefixMatch": ["inventorytestcontainer1", "inventorytestcontainer2/abcd", "etc"],
        "excludePrefix": ["inventorytestcontainer10", "etc/logs"],
        "includeSnapshots": false,
        "includeBlobVersions": true
      },
      "format": "csv",
      "objectType": "blob",
      "schedule": "daily",
      "schemaFields": ["Name", "Creation-Time"]
    },
    "enabled": true,
    "name": "blobinventorytest",
    "destination": "inventorydestinationContainer"
  },
  {
    "definition": {
      "filters": {
        "prefixMatch": ["inventorytestcontainer1", "inventorytestcontainer2/abcd", "etc"]
      },
      "format": "csv",
      "objectType": "container",
      "schedule": "weekly",
      "schemaFields": ["Name", "HasImmutabilityPolicy", "HasLegalHold"]
    },
    "enabled": true,
    "name": "containerinventorytest",
    "destination": "inventorydestinationContainer"
    }
  ]
}

Benutzerdefinierte Schemafelder, die für die Blobinventur unterstützt werden

Hinweis

Die Spalte Data Lake Storage zeigt Unterstützung in Konten, bei denen das Feature „hierarchischer Namespace“ aktiviert wurde.

Feld	Blob Storage (Standardunterstützung)	Data Lake-Speicher
Name (Erforderlich)
Erstellungszeit
Zuletzt geändert
LastAccessTime1
ETag
Inhaltslänge
Inhaltstyp
Inhaltscodierung
Inhaltssprache
Content-CRC64
Content-MD5
Cachesteuerung
Cache-Disposition
BlobType
AccessTier
AccessTierChangeTime
LeaseStatus
LeaseState
Serververschlüsselt
CustomerProvidedKeySHA256
Metadaten
Ablaufzeit
hdi_isfolder
Besitzer
Gruppe
Berechtigungen
Acl
Momentaufnahme (verfügbar und erforderlich, wenn Sie Momentaufnahmen in Ihren Bericht integrieren möchten)
Gelöscht
DeletionId
DeletedTime
Verbleibende Aufbewahrungstage
VersionID (verfügbar und erforderlich, wenn Sie Blobversionen in Ihren Bericht integrieren möchten)
IsCurrentVersion (verfügbar und erforderlich, wenn Sie Blobversionen in Ihren Bericht integrieren möchten)
TagCount
Stichwörter
CopyId
CopySource
Kopierstatus
CopyProgress
CopyCompletionTime
Beschreibung des Kopierstatus
UnveränderlichkeitsrichtlinieBisDatum
ImmutabilityPolicyMode
LegalHold
Rehydrierungspriorität
Archiv-Status
EncryptionScope (Englisch)
Inkrementelles Kopieren
x-ms-blob-sequence-number

¹ Standardmäßig deaktiviert. Aktivieren Sie optional die Nachverfolgung der Zugriffszeit.

Benutzerdefinierte Schemafelder, die für die Containerinventur unterstützt werden

Hinweis

Die Spalte Data Lake Storage zeigt Unterstützung in Konten, bei denen das Feature „hierarchischer Namespace“ aktiviert wurde.

Feld	Blob Storage (Standardunterstützung)	Data Lake-Speicher
Name (Erforderlich)
Zuletzt geändert
ETag
LeaseStatus
LeaseState
Mietdauer
Metadaten
Öffentlicher Zugang
Standardverschlüsselungsbereich
DenyEncryptionScopeOverride
HasImmutabilityPolicy
HasLegalHold
ImmutableStorageWithVersioningEnabled
Gelöscht (wird nur angezeigt, wenn „Gelöschte Container einschließen“ ausgewählt ist)
Version (nur angezeigt, wenn „Include deleted containers“ (Gelöschte Container einschließen) ausgewählt wurde)
DeletedTime (wird nur angezeigt, wenn „include deleted containers“ ausgewählt wurde)
RemainingRetentionDays (Erscheint nur, wenn die Option „Gelöschte Container einschließen“ ausgewählt ist)

Inventurausführung

Wenn du eine Regel so konfigurierst, dass sie täglich läuft, läuft sie jeden Tag. Wenn du eine Regel so einstellst, dass sie wöchentlich läuft, läuft sie jeden Sonntag in UTC.

Ein Inventurdurchlauf kann bis zu sechs Tage dauern, bevor er scheitert. Um mehr über Faktoren zu erfahren, die die Laufzeit beeinflussen, siehe Blob Inventory Performance Characteristics.

Die Durchläufe überlappen sich nicht, daher muss ein Durchlauf abgeschlossen werden, bevor ein weiterer Durchlauf derselben Regel beginnen kann. Wenn zum Beispiel der Lauf der Tagesregel vom Vortag noch läuft, startet der Dienst an diesem Tag keinen neuen Lauf. Die wöchentlichen Regeln werden jeden Sonntag ausgeführt, unabhängig davon, ob eine vorherige Ausführung erfolgreich ist oder fehlschlägt. Wenn ein Durchlauf nicht erfolgreich abgeschlossen wird, überprüfe die folgenden Durchläufe, bevor du den Support kontaktierst. Die Leistung des Laufs kann variieren, daher kann ein weiterer Durchlauf erfolgreich abgeschlossen werden.

Bestandsrichtlinien werden vollständig gelesen oder geschrieben. Teilaktualisierungen werden nicht unterstützt. Bestandsregeln werden täglich ausgewertet. Wenn Sie eine Regeldefinition ändern, nachdem der Service die Policy für diesen Tag bewertet hat, bewertet der Service Ihre Aktualisierungen am nächsten Tag.

Inventurabschlussereignis

Das BlobInventoryPolicyCompleted-Ereignis wird erstellt, sobald die Inventur für eine Regel abgeschlossen wurde. Dieses Ereignis tritt auch auf, wenn der Inventurlauf aufgrund eines Benutzerfehlers fehlschlägt, bevor er startet. Zum Beispiel löst eine ungültige Richtlinie oder ein fehlender Zielcontainer das Ereignis aus. Das folgende JSON zeigt ein Beispielereignis BlobInventoryPolicyCompleted .

{
  "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/BlobInventory/providers/Microsoft.EventGrid/topics/BlobInventoryTopic",
  "subject": "BlobDataManagement/BlobInventory",
  "eventType": "Microsoft.Storage.BlobInventoryPolicyCompleted",
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "data": {
    "scheduleDateTime": "2021-05-28T03:50:27Z",
    "accountName": "testaccount",
    "ruleName": "Rule_1",
    "policyRunStatus": "Succeeded",
    "policyRunStatusMessage": "Inventory run succeeded, refer manifest file for inventory details.",
    "policyRunId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "manifestBlobUrl": "https://testaccount.blob.core.windows.net/inventory-destination-container/2021/05/26/13-25-36/Rule_1/Rule_1-manifest.json"
  },
  "dataVersion": "1.0",
  "metadataVersion": "1",
  "eventTime": "2021-05-28T15:03:18Z"
}

In folgender Tabelle wird das Schema des BlobInventoryPolicyCompleted-Ereignisses beschrieben.

Feld	Typ	BESCHREIBUNG
scheduleDateTime	string	Zeitpunkt, zu dem die Bestandsregel geplant wurde.
Kontoname	string	Der Name des Speicherkontos.
RegelName	string	Name der Regel
policyRunStatus	string	Status der Inventurausführung Mögliche Werte sind Succeeded, PartiallySucceeded und Failed.
policyRunStatusMessage	string	Die Statusmeldung des Inventurlaufs.
policyRunId	string	Richtlinienausführungs-ID für die Inventurausführung
manifestBlobUrl	string	Die Blob-URL der Manifestdatei für den Inventurlauf

Inventurausgabe

Jede Inventarregel erstellt für die jeweilige Regel eine Reihe von Dateien im angegebenen Ziel-Container für Inventardaten. Die Bestandsausgabe ist unter folgendem Pfad verfügbar: https://<accountName>.blob.core.windows.net/<inventory-destination-container>/YYYY/MM/DD/HH-MM-SS/<ruleName> wobei:

• accountName ist der Name Ihres Azure Blob Storage-Kontos.
• inventory-destination-container ist der in Ihrer Inventurregel angegebene Zielcontainer.
• YYYY/MM/DD/HH-MM-SS ist die Zeit, zu der das Inventar begann.
• ruleName ist der Name der Inventurregel.

Inventurdateien

Bei jeder Inventur für eine Regel werden die folgenden Dateien generiert:

• Inventurdatei: Eine Inventurausführung für eine Regel generiert Dateien im CSV- oder Apache Parquet-Format. Jede dieser Dateien enthält die übereinstimmenden Objekte und ihre Metadaten.

  Wichtig

  Inventarläufe erzeugen mehrere Dateien, wenn die Objektanzahl groß ist. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Ausgabe mehrerer Inventurdateien.

  Berichte im Apache Parquet-Format präsentieren Termine im folgenden Format: timestamp_millis [number of milliseconds since 1970-01-01 00:00:00 UTC]. Die erste Zeile in einer CSV-Datei enthält immer das Schema. Die folgende Abbildung zeigt eine in Microsoft Excel geöffnete CSV-Bestandsdatei.

  

  Wichtig

  Die Blobpfade in einer Inventurdatei werden möglicherweise in keiner bestimmten Reihenfolge angezeigt.

• Prüfsummendatei: Eine Prüfsummendatei enthält die MD5-Prüfsumme des Inhalts der manifest.json Datei. Der Name der Prüfsummendatei lautet <ruleName>-manifest.checksum. Die Generierung der Prüfsummendatei kennzeichnet den Abschluss der Ausführung einer Inventurregel.

• Manifestdatei: Eine Datei enthält die Details der für manifest.json diese Regel generierten Inventardateien. Der Name der Datei lautet <ruleName>-manifest.json. Diese Datei erfasst außerdem die Regeldefinition und den Pfad zum Inventar dieser Regel. Das folgende JSON zeigt den Inhalt einer Beispieldatei manifest.json .

  {
  "destinationContainer" : "inventory-destination-container",
  "endpoint" : "https://testaccount.blob.core.windows.net",
  "files" : [
    {
      "blob" : "2021/05/26/13-25-36/Rule_1/Rule_1.csv",
      "size" : 12710092
    }
  ],
  "inventoryCompletionTime" : "2021-05-26T13:35:56Z",
  "inventoryStartTime" : "2021-05-26T13:25:36Z",
  "ruleDefinition" : {
    "filters" : {
      "blobTypes" : [ "blockBlob" ],
      "includeBlobVersions" : false,
      "includeSnapshots" : false,
      "prefixMatch" : [ "penner-test-container-100003" ]
    },
    "format" : "csv",
    "objectType" : "blob",
    "schedule" : "daily",
    "schemaFields" : [
      "Name",
      "Creation-Time",
      "BlobType",
      "Content-Length",
      "LastAccessTime",
      "Last-Modified",
      "Metadata",
      "AccessTier"
    ]
  },
  "ruleName" : "Rule_1",
  "status" : "Succeeded",
  "summary" : {
    "objectCount" : 110000,
    "totalObjectSize" : 23789775
  },
  "version" : "1.0"
  }
  

  Diese Datei wird erstellt, wenn die Ausführung beginnt. Das Feld status dieser Datei ist auf Pending festgelegt, bis die Ausführung abgeschlossen ist. Nach Abschluss des Laufs wird dieses Feld auf einen Vervollständigungsstatus gesetzt (zum Beispiel: Succeeded oder Failed).

Preise und Abrechnung

Die Preisgestaltung des Inventars basiert auf der Anzahl der Blobs und Container, die Sie während des Abrechnungszeitraums scannen. Auf der Preisseite von Azure Blob Storage wird der Preis pro eine Million überprüfter Objekte angezeigt. Wenn der Preis für die Überprüfung einer Million Objekte beispielsweise $0.003 beträgt, Ihr Konto drei Millionen Objekte enthält und Sie vier Berichte pro Monat erstellen, dann würde Ihre Rechnung 4 * 3 * $0.003 = $0.036 betragen.

Nachdem Sie Inventardateien erstellt haben, fallen zusätzliche Standard-Datenspeicher- und Betriebsgebühren für das Speichern, Lesen und Schreiben der inventargenerierten Dateien im Konto an.

Wenn eine Regel ein Präfix enthält, das sich mit einem Präfix einer anderen Regel überschneidet, kann derselbe Blob in mehr als einem Inventarbericht erscheinen. In diesem Fall zahlen Sie für beide Fälle. Gehen wir z. B. davon aus, dass das Element prefixMatch einer Regel auf ["inventory-blob-1", "inventory-blob-2"] festgelegt ist, und dass das Element prefixMatch einer anderen Regel auf ["inventory-blob-10", "inventory-blob-20"] festgelegt ist. Ein Objekt mit dem Namen inventory-blob-200 wird in beiden Inventurberichten erscheinen.

Schnappschüsse und Versionen eines Blobs werden ebenfalls in Rechnung gestellt, auch wenn Sie die Filter includeSnapshots und includeBlobVersions auf false festlegen. Diese Filterwerte haben keinen Einfluss auf die Abrechnung. Sie können sie nur verwenden, um zu filtern, welche Elemente im Bericht erscheinen.

Weitere Informationen zu den Preisen für die Azure Storage-Blobinventur finden Sie auf der Seite Preise für Azure Blob Storage.

Unterstützte Funktionen

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 bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Einschränkungen und bekannte Probleme

In diesem Abschnitt werden Einschränkungen und bekannte Probleme des Azure Storage-Blobbestandsfeatures beschrieben.

Inventarbericht, Objektanzahl und Datengröße sollten nicht mit der Abrechnung verglichen werden

Ein Inventarbericht enthält keine Metadaten, Systemprotokolle und Eigenschaften, daher sollte man ihn nicht mit der Anzahl der abgerechneten Objekte und der Datengröße des Speicherkontos vergleichen.

Inventararbeiten dauern in bestimmten Fällen länger, um abgeschlossen zu werden.

Eine Inventararbeit kann in diesen Fällen länger dauern:

• Man fügt eine große Menge neuer Daten hinzu.

• Du führst zum ersten Mal eine Regel oder eine Reihe von Regeln aus.

  Der Inventarlauf kann länger dauern als spätere Durchläufe.

• Ein Inventarlauf verarbeitet eine große Menge an Daten in hierarchischen, namensraumfähigen Konten.

  Ein Inventarauftrag kann für hierarchische, namensraumfähige Konten mit Hunderten Millionen von Blobs mehr als einen Tag dauern. Mitunter schlägt der Inventurauftrag fehl, sodass keine Inventurdatei erstellt wird. Wenn ein Auftrag nicht erfolgreich abgeschlossen wird, überprüfen Sie, ob nachfolgende Aufträge abgeschlossen werden, bevor Sie sich an den Support wenden.

• Es gibt keine Möglichkeit, einen Bericht rückwirkend für ein bestimmtes Datum zu generieren.

Inventuraufträge können keine Berichte in Container schreiben, für die eine Objektreplikationsrichtlinie gilt.

Der Inventurauftrag wird möglicherweise durch eine Objektreplikationsrichtlinie daran gehindert, Inventurberichte in den Zielcontainer zu schreiben. Andere Szenarien können die Berichte archivieren oder sie unveränderlich machen, wenn sie teilweise abgeschlossen sind, was dazu führen kann, dass Inventaraufträge ausfallen.

Inventar und unveränderliche Lagerung

Man kann keine Inventarrichtlinie im Konto konfigurieren, wenn die Unterstützung für Versionsunveränderlichkeit auf diesem Konto aktiviert ist oder wenn die Unterstützung für Versionsunveränderlichkeit im Zielcontainer, den Sie in der Inventarrichtlinie definieren, aktiviert ist.

Berichte schließen vorläufig gelöschte Blobs in Konten, die über einen hierarchischen Namespace verfügen, möglicherweise aus.

Wenn Sie einen Container oder ein Verzeichnis löschen, während das Soft Delete aktiviert ist, markiert der Dienst ihn und all seinen Inhalt als weich gelöscht. In einem Inventarbericht erscheint jedoch nur der Container oder das Verzeichnis, das als Blob mit der Länge null ausgewiesen wird. Der Bericht enthält keine vorläufig gelöschten untergeordneten Blobs, selbst Sie das Feld includeDeleted der Richtlinie auf true gesetzt haben. Dieses Verhalten kann einen Unterschied zwischen den Kapazitätsmetriken im Azure-Portal und dem Inventarbericht erzeugen.

Nur Blobs, die du explizit löschst, erscheinen in den Berichten. Um eine vollständige Auflistung aller vorläufig gelöschten Blobs (Verzeichnis und alle untergeordneten Blobs) zu erhalten, sollten Workloads jeden Blob in einem Verzeichnis löschen, bevor das Verzeichnis selbst gelöscht wird.

Handhabung von Duplikaten im Blob-Inventar

Blob Inventory läuft auf einem verteilten System, was bedeutet, dass in seltenen Fällen doppelte Blob-Einträge in Ihren Berichten erscheinen können.

Wenn dein Anwendungsfall eindeutige Blob-Einträge verlangt, wenn du einen Inventarbericht nachbearbeitest, nutze das Feld Name , um nur eindeutige Blobs zurückzugeben.

Wenn Ihr Bericht Blob-Versionen enthält, verwenden Sie die Felder Name und Version ID zusammen, um ausschließlich die einzigartigen Blobs und Versionen zu identifizieren und zurückzugeben.

Nächste Schritte

• Aktivieren von Azure Storage-Blobinventurberichten
• Berechnen der Anzahl und Gesamtgröße von Blobs pro Container
• Tutorial: Analysieren von Blobinventurberichten
• Verwalten des Azure Blob Storage-Lebenszyklus
• FAQ zum Blob-Inventar