Inventaire des objets blob du Stockage Azure

Article
2024-04-12

L’inventaire des objets blob Stockage Azure fournit une liste des conteneurs, des objets blob, des versions d’objets blob et des captures instantanées de votre compte de stockage, ainsi que ses propriétés associées. Il génère un rapport de sortie au format CSV (Valeurs séparées par des virgules) ou au format Apache Parquet sur une base quotidienne ou hebdomadaire. Vous pouvez utiliser le rapport pour auditer une rétention, une conservation légale ou un état de chiffrement du contenu de votre compte de stockage, ou vous pouvez l’utiliser pour comprendre la taille totale des données, l’âge, la distribution de niveaux ou d’autres attributs de vos données. Vous pouvez également utiliser un inventaire d’objets blob pour simplifier vos flux de travail d’entreprise ou accélérer des travaux de traitement des données, en utilisant l’inventaire d’objets blob comme automatisation planifiée des API Répertorier les conteneurs et Répertorier les objets blob. Les règles d’inventaire d’objets blob vous permettent de filtrer le contenu du rapport par type d’objet blob, préfixe ou en sélectionnant les propriétés d’objet blob à inclure dans le rapport.

L’inventaire des objets blob stockage Azure est disponible pour les types de comptes de stockage suivants :

Usage général v2 Standard
Stockage d’objets blob de blocs Premium
Stockage d'objets blob

Fonctionnalités de l’inventaire

La liste suivante décrit les fonctionnalités et capacités disponibles dans la version actuelle de l’inventaire de blobs de Stockage Azure.

Rapports d’inventaire pour les blobs et les conteneurs

Vous pouvez générer des rapports d’inventaire pour les blobs et les conteneurs. Un rapport sur les blobs peut contenir les blobs de base, la durée du contenu, les instantanés, les versions de blobs et leurs propriétés associées telles que l’heure de création ou l’heure de dernière modification. Les conteneurs vides ne sont pas répertoriés dans le rapport d’inventaire de blobs. Un rapport sur les conteneurs décrit les conteneurs et leurs propriétés associées telles que l’état de la stratégie d’immuabilité ou l’état de conservation légale.
Schéma personnalisé

Vous pouvez choisir les champs à afficher dans les rapports. Faites votre choix parmi une liste de champs pris en charge. Cette liste apparaît plus loin dans cet article.
Format de sortie CSV et Apache Parquet

Vous pouvez générer un rapport d’inventaire au format de sortie CSV ou Apache Parquet.
Fichier manifeste et événement Azure Event Grid par rapport d’inventaire

Un fichier manifeste et un événement Azure Event Grid sont générés par rapport d’inventaire. Ils sont décrits plus loin dans cet article.

Activation des rapports d’inventaire

Activez les rapports d’inventaire des blobs en ajoutant une stratégie comprenant une ou plusieurs règles à votre compte de stockage. Pour obtenir une aide, consultez Activer les rapports d’inventaire des blobs de Stockage Azure.

Mise à niveau d’une stratégie d’inventaire

Si vous êtes un utilisateur actuel de l’inventaire des objets blob du Stockage Azure, et que vous avez configuré votre inventaire avant juin 2021, vous pouvez commencer à utiliser les nouvelles fonctionnalités en chargeant la stratégie, puis en réenregistrant la stratégie après avoir apporté des modifications. Lorsque vous rechargez la stratégie, les nouveaux champs de la stratégie sont renseignés avec les valeurs par défaut. Vous pouvez modifier ces valeurs si vous le souhaitez. En outre, les deux fonctionnalités suivantes seront disponibles.

Un conteneur de destination est désormais pris en charge pour chaque règle au lieu d’être simplement pris en charge pour la stratégie.
Un fichier manifeste et un événement Azure Event Grid sont désormais générés par règle et non plus par stratégie.

Stratégie d’inventaire

La configuration d’un rapport d’inventaire s’effectue en ajoutant une stratégie d’inventaire avec une ou plusieurs règles. Une stratégie d’inventaire est un ensemble de règles dans un document JSON.

{
  "enabled": true,
  "rules": [
  {
    "enabled": true,
    "name": "inventoryrule1",
    "destination": "inventory-destination-container",
    "definition": {. . .}
  },
  {
    "enabled": true,
    "name": "inventoryrule2",
    "destination": "inventory-destination-container",
    "definition": {. . .}
  }]
}

Pour afficher le code JSON d’une stratégie d’inventaire, sélectionnez l’onglet Mode Code dans la section Inventaire des objets blob du Portail Azure.

Nom du paramètre	Type de paramètre	Notes	Requis ?
enabled	boolean	Paramètre permettant de désactiver l’intégralité de la stratégie. Lorsqu’il a la valeur true, le champ de niveau règle activé remplace ce paramètre. Quand il est désactivé, l’inventaire est désactivé pour toutes les règles.	Yes
rules	Tableau d’objets de règle	Une stratégie requiert au moins une règle. Jusqu’à 100 règles sont prises en charge par stratégie.	Yes

Règles d’inventaire

Une règle capture les conditions de filtrage et les paramètres de sortie associés à la génération d’un rapport d’inventaire. Chaque règle crée un rapport d’inventaire. Les règles peuvent comporter des préfixes qui se chevauchent. Il peut arriver qu’un objet blob apparaisse dans plusieurs inventaires en fonction des définitions de règles.

Chaque règle au sein de la stratégie a plusieurs paramètres :

Nom du paramètre	Type de paramètre	Notes	Requis ?
name	string	Un nom de règle peut comporter jusqu’à 256 caractères alphanumériques sensibles à la casse. Il doit être unique dans une stratégie.	Yes
enabled	boolean	Indicateur permettant l’activation et la désactivation d’une règle. La valeur par défaut est true.	Yes
Définition	Définition de règle d’inventaire JSON	Chaque définition se compose d’un ensemble de filtres de règle.	Yes
destination	string	Le conteneur de destination dans lequel tous les fichiers d’inventaire sont générés. Il doit déjà exister.

L’indicateur global Inventaire des objets blob activé est prioritaire sur le paramètre activé dans une règle.

Définition de la règle

Nom du paramètre	Type de paramètre	Notes	Obligatoire
filtres	json	Les filtres déterminent si un blob ou un conteneur fait partie de l’inventaire ou non.	Yes
format	string	Détermine la sortie du fichier d’inventaire. Les valeurs valides sont `csv` (pour le format CSV) et `parquet` (pour le format Apache Parquet).	Yes
objectType	string	Indique s’il s’agit d’une règle d’inventaire pour les blobs ou les conteneurs. Les valeurs valides sont `blob` et `container`.	Yes
schedule	string	Calendrier d’exécution de cette règle. Les valeurs valides sont `daily` et `weekly`.	Yes
schemaFields	Tableau JSON	Liste des champs de schéma devant faire partie de l’inventaire.	Yes

Filtres de règle

Plusieurs filtres sont disponibles pour personnaliser un rapport d’inventaire d’objets blob :

Nom du filtre	Type de filtre	Notes	Requis ?
blobTypes	Tableau de valeurs enum prédéfinies	Les valeurs valides sont `blockBlob` et `appendBlob` pour les comptes avec espace de noms hiérarchique, et `blockBlob`, `appendBlob` et `pageBlob` pour les autres. Ce champ n’est pas applicable à l’inventaire d’un conteneur (objectType : `container`).	Oui
creationTime	Numéro	Spécifie le nombre de jours depuis la création du blob. Par exemple, la valeur `3` inclut uniquement dans le rapport les blobs créés au cours des trois derniers jours.	Non
prefixMatch	Tableau pouvant comporter jusqu’à 10 chaînes pour les préfixes à mettre en correspondance	Si vous ne définissez pas prefixMatch ou que vous indiquez un préfixe vide, la règle s’applique à tous les objets blob du compte de stockage. Un préfixe doit être un préfixe de nom de conteneur ou un nom de conteneur. Par exemple, `container`, `container1/foo`.	Non
excludePrefix	Tableau pouvant comporter jusqu’à 10 chaînes pour les préfixes à exclure.	Spécifie les chemins des objets blob à exclure du rapport d’inventaire. Un excludePrefix doit être un préfixe de nom de conteneur ou un nom de conteneur. Un excludePrefix vide signifierait que tous les objets blob avec des noms correspondant à n’importe quelle chaîne prefixMatch seront listés. Si vous souhaitez inclure un certain préfixe mais exclure un sous-ensemble spécifique de celui-ci, vous pouvez utiliser le filtre excludePrefix. Par exemple, si vous souhaitez inclure tous les objets blob sous `container-a` excepté ceux qui sont sous le dossier `container-a/folder`, prefixMatch doit être défini sur `container-a` et excludePrefix doit être défini sur `container-a/folder`.	No
includeSnapshots	boolean	Spécifie si l’inventaire doit inclure les instantanés. La valeur par défaut est `false`. Ce champ n’est pas applicable à l’inventaire d’un conteneur (objectType : `container`).	No
includeBlobVersions	boolean	Spécifie si l’inventaire doit inclure les versions d’objets blob. La valeur par défaut est `false`. Ce champ n’est pas applicable à l’inventaire d’un conteneur (objectType : `container`).	No
includeDeleted	boolean	Spécifie si l’inventaire doit inclure les objets blob supprimés. La valeur par défaut est `false`. Dans les comptes qui ont un espace de noms hiérarchique, ce filtre inclut les dossiers et englobe également les objets blob qui sont dans un état supprimé de manière réversible. Seuls les dossiers et fichiers (objets blob) explicitement supprimés apparaissent dans les rapports. Les dossiers et fichiers enfants qui sont supprimés à la suite de la suppression d’un dossier parent ne sont pas inclus dans le rapport.	No

Pour afficher le code JSON de règles d’inventaire, sélectionnez l’onglet Mode Code dans la section Inventaire des objets blob du Portail Azure. Les filtres sont spécifiés au sein d’une définition de règle.

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

Champs de schéma personnalisés pris en charge pour l’inventaire des blobs

Remarque

La colonne Data Lake Storage montre la prise en charge dans les comptes où la fonctionnalité d’espace de noms hiérarchique est activée.

Champ	Stockage Blob (prise en charge par défaut)	Data Lake Storage
Name (obligatoire)
Creation-Time
Last-Modified
LastAccessTime¹
ETag
Content-Length
Content-Type
Content-Encoding
Content-Language
Content-CRC64
Content-MD5
Cache-Control
Cache-Disposition
BlobType
AccessTier
AccessTierChangeTime
LeaseStatus
LeaseState
ServerEncrypted
CustomerProvidedKeySHA256
Métadonnées
Expiry-Time
hdi_isfolder
Propriétaire
Groupe
Autorisations
Acl
Snapshot (disponible et obligatoire lorsque vous choisissez d’inclure des instantanés dans votre rapport)
Deleted
DeletedId
DeletedTime
RemainingRetentionDays
VersionId (disponible et obligatoire lorsque vous choisissez d’inclure des versions de blobs dans votre rapport)
IsCurrentVersion (disponible et obligatoire lorsque vous choisissez d’inclure des versions de blobs dans votre rapport)
TagCount
Étiquettes
CopyId
CopySource
CopyStatus
CopyProgress
CopyCompletionTime
CopyStatusDescription
ImmutabilityPolicyUntilDate
ImmutabilityPolicyMode
LegalHold
RehydratePriority
ArchiveStatus
EncryptionScope
IncrementalCopy
x-ms-blob-sequence-number

¹ Désactivé par défaut. Activer éventuellement le suivi du temps d'accès.

Champs de schéma personnalisés pris en charge pour l’inventaire des conteneurs

Remarque

La colonne Data Lake Storage montre la prise en charge dans les comptes où la fonctionnalité d’espace de noms hiérarchique est activée.

Champ	Stockage Blob (prise en charge par défaut)	Data Lake Storage
Name (obligatoire)
Last-Modified
ETag
LeaseStatus
LeaseState
LeaseDuration
Métadonnées
PublicAccess
DefaultEncryptionScope
DenyEncryptionScopeOverride
HasImmutabilityPolicy
HasLegalHold
ImmutableStorageWithVersioningEnabled
Deleted (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée)
Version (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée)
DeletedTime (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée)
RemainingRetentionDays (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée)

Exécution d’un inventaire

Si vous configurez une règle pour qu’elle s’exécute quotidiennement, son exécution est planifiée tous les jours. Si vous configurez une règle pour qu’elle s’exécute toutes les semaines, elle est planifiée pour s’exécuter chaque semaine à l’heure UTC du dimanche.

La plupart des exécutions d’inventaire se terminent dans les 24 heures. Pour les comptes dotés d’un espace de noms hiérarchique, une exécution peut durer jusqu’à deux jours et, selon le nombre de fichiers traités, l’exécution peut ne pas se terminer à la fin de ces deux jours. La durée maximale pendant laquelle une exécution peut se terminer avant d’échouer est de six jours.

Les exécutions ne se chevauchent pas, de sorte qu’une exécution doit se terminer avant qu’une autre exécution de la même règle puisse commencer. Par exemple, si une règle est planifiée pour s’exécuter quotidiennement, mais que l’exécution du jour précédent de cette même règle est toujours en cours, une nouvelle exécution n’est pas lancée ce jour-là. Les règles qui sont planifiées pour s’exécuter chaque semaine s’exécutent chaque dimanche, que l’exécution précédente réussisse ou échoue. Si une exécution ne se termine pas correctement, vérifiez les exécutions suivantes pour voir si elles se terminent avant de contacter le support. Les performances d’une exécution peuvent varier. Par conséquent, si une exécution ne se termine pas, il est possible que les exécutions suivantes, elles, se terminent.

Les stratégies d’inventaire sont lues ou écrites en entier. Les mises à jour partielles ne sont pas prises en charge. Les règles d’inventaire sont évaluées quotidiennement. Par conséquent, si vous modifiez la définition d’une règle, mais que les règles d’une stratégie ont déjà été évaluées pour ce jour-là, vos mises à jour ne seront évaluées que le jour suivant.

Événement d’inventaire terminé

L’événement BlobInventoryPolicyCompleted est généré lorsque l’exécution de l’inventaire est terminée pour une règle. Cet événement se produit également si l’exécution de l’inventaire rencontre une erreur utilisateur avant de commencer. Par exemple, une stratégie non valide ou une erreur qui se produit lorsqu’un conteneur de destination n’est pas présent déclenchera l’événement. Le json suivant montre un exemple d’événement 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"
}

Le tableau suivant décrit le schéma de l’événement BlobInventoryPolicyCompleted.

Champ	Type	Description
scheduleDateTime	string	Heure à laquelle la règle d’inventaire a été planifiée.
accountName	string	nom du compte de stockage.
ruleName	string	Nom de la règle.
policyRunStatus	string	État de l’exécution de l’inventaire. Les valeurs possibles sont `Succeeded`, `PartiallySucceeded` et `Failed`.
policyRunStatusMessage	string	Message d’état pour l’exécution de l’inventaire.
policyRunId	string	ID d’exécution de la stratégie pour l’exécution de l’inventaire.
manifestBlobUrl	string	URL du blob pour le fichier manifeste pour l’exécution de l’inventaire.

Sortie de l’inventaire

Chaque règle d’inventaire génère un ensemble de fichiers dans le conteneur de destination des inventaires spécifié pour cette règle. La sortie d’inventaire est générée dans le chemin https://<accountName>.blob.core.windows.net/<inventory-destination-container>/YYYY/MM/DD/HH-MM-SS/<ruleName, où :

accountName est le nom du compte Stockage Blob Azure ;
inventory-destination-container est le conteneur de destination que vous avez spécifié dans la règle d’inventaire ;
YYYY/MM/DD/HH-MM-SS est l’heure à laquelle l’inventaire a commencé à s’exécuter ;
ruleName est le nom de la règle d’inventaire.

Fichiers d’inventaire

Chaque exécution d’inventaire pour une règle génère les fichiers suivants :

Fichier d’inventaire : L’exécution d’un inventaire pour une règle génère un fichier au format CSV ou Apache Parquet. Chacun de ces fichiers contient les objets mis en correspondance et leurs métadonnées.

Important

À compter d’octobre 2023, les exécutions d’inventaire produisent plusieurs fichiers, si le nombre d’objets est volumineux. Pour plus d’informations, consultez FAQ sur les sorties de plusieurs fichiers d’inventaire.

Les rapports au format Apache Parquet présentent les dates au format suivant : timestamp_millis [number of milliseconds since 1970-01-01 00:00:00 UTC]. Pour un fichier au format CSV, la première ligne est toujours celle du schéma. Voici un fichier CSV d’inventaire ouvert dans Microsoft Excel.

Important

Les chemins d’accès des blobs qui apparaissent dans un fichier d’inventaire peuvent ne pas apparaître dans un ordre particulier.
Fichier de somme de contrôle : Un fichier de somme de contrôle contient la somme de contrôle MD5 du contenu du fichier manifest.json. Le nom du fichier de somme de contrôle est <ruleName>-manifest.checksum. La génération du fichier de somme de contrôle marque la fin de l’exécution d’une règle d’inventaire.

Fichier manifeste : Un fichier manifest.json contient les détails du ou des fichiers d’inventaire générés pour cette règle. Le nom du fichier est <ruleName>-manifest.json. Ce fichier capture également la définition de règle fournie par l’utilisateur et le chemin vers l’inventaire pour cette règle. Le code JSON suivant montre le contenu d’un exemple de fichier 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"
}

Ce fichier est créé au démarrage de l’exécution. Le champ status de ce fichier est défini sur Pending jusqu’à la fin de l’exécution. Une fois l’exécution terminée, ce champ est défini sur un état d’achèvement (par exemple : Succeeded ou Failed).

Tarification et facturation

La tarification de l’inventaire est basée sur le nombre de blobs et de conteneurs analysés au cours de la période de facturation. La page de tarification du stockage Blob Azure affiche le prix par million d’objets analysés. Par exemple, si le prix de l’analyse d’un million d’objets est de $0.003, que votre compte contient trois millions d’objets et que vous produisez quatre rapports mensuels, votre facture serait de 4 * 3 * $0.003 = $0.036.

Après la création des fichiers d’inventaire, des frais standard supplémentaires de stockage de données et d’exploitation seront encourus pour le stockage, la lecture et l’écriture des fichiers générés par l’inventaire dans le compte.

Si une règle contient un préfixe qui chevauche le préfixe d’une autre règle, le même blob peut apparaître dans plusieurs rapports d’inventaire. Dans ce cas, les deux instances vous sont facturées. Par exemple, supposons que l’élément prefixMatch d’une règle est défini sur ["inventory-blob-1", "inventory-blob-2"] et que l’élément prefixMatch d’une autre règle est défini sur ["inventory-blob-10", "inventory-blob-20"]. Un objet nommé inventory-blob-200 apparaît dans les deux rapports d’inventaire.

Les instantanés et les versions d’un blob sont également pris en compte dans la facturation, même si vous avez défini les filtres includeSnapshots et includeVersions sur false. Ces valeurs de filtre sont sans effet sur la facturation. Vous pouvez les utiliser uniquement pour filtrer ce qui apparaît dans le rapport.

Pour plus d’informations sur la tarification de l’inventaire de blobs Stockage Azure, consultez Tarification Stockage Blob Azure.

Prise en charge des fonctionnalités

La prise en charge de cette fonctionnalité peut être impactée par l’activation de Data Lake Storage Gen2, du protocole NFS (Network File System) 3.0 ou du protocole SFTP (SSH File Transfer Protocol). Si vous avez activé l’une de ces fonctionnalités, consultez Prise en charge des fonctionnalités Stockage Blob dans les comptes Stockage Azure pour évaluer la prise en charge de cette fonctionnalité.

Problèmes connus et limitations

Cette section décrit les limitations et les problèmes connus de la fonctionnalité d’inventaire des objets blob du service Stockage Azure.

Le nombre d'objets et la taille des données du rapport d'inventaire ne doivent pas être comparés à la facturation

Un rapport d'inventaire n'inclut pas les métadonnées, les journaux système et les propriétés. Il ne doit donc pas être comparé au nombre d'objets facturés et à la taille des données pour le compte de stockage.

Les travaux d’inventaire prennent plus de temps dans certains cas

Un travail d’inventaire peut prendre plus de temps dans les cas suivants :

Une grande quantité de nouvelles données est ajoutée
Une règle ou un ensemble de règles est en cours d’exécution pour la première fois

L’exécution d’inventaire peut prendre plus de temps que les exécutions d’inventaire suivantes.
L’exécution d’un inventaire consiste à traiter une grande quantité de données dans des comptes activés par l’espace de noms hiérarchique

Un travail d’inventaire peut prendre plus d’un jour pour les comptes avec espace de noms hiérarchique qui ont des centaines de millions d’objets blob. Parfois, le travail d’inventaire échoue et ne crée pas de fichier d’inventaire. Si un travail ne se termine pas correctement, vérifiez les travaux suivants pour voir s’ils se terminent avant de contacter le support.
Il n’existe aucune option permettant de générer un rapport de manière rétrospective à une date donnée.

Les travaux d’inventaire ne peuvent pas écrire de rapports dans des conteneurs qui ont une stratégie de réplication d’objet

Une stratégie de réplication d’objet peut empêcher un travail d’inventaire d’écrire des rapports d’inventaire dans le conteneur de destination. D’autres scénarios peuvent archiver les rapports ou rendre les rapports immuables lorsqu’ils sont partiellement terminés, ce qui peut entraîner l’échec des travaux d’inventaire.

Inventaire et stockage immuable

Vous ne pouvez pas configurer une stratégie d’inventaire dans le compte si la prise en charge de l’immuabilité au niveau de la version est activée sur ce compte, ou si la prise en charge de l’immuabilité au niveau de la version est activée sur le conteneur de destination défini dans la stratégie d’inventaire.

Les rapports peuvent exclure des objets BLOB supprimés de manière réversible dans les comptes qui ont un espace de noms hiérarchique

Si un conteneur ou un répertoire est supprimé avec la suppression réversible activée, le conteneur ou le répertoire et tout son contenu sont marqués comme supprimés de manière réversible. Toutefois, seul le conteneur ou le répertoire (signalé en tant qu’objet BLOB de longueur nulle) apparaît dans un rapport d’inventaire et non dans les objets BLOB supprimés de manière réversible dans ce conteneur ou répertoire, même si vous définissez le champ includeDeleted de la stratégie sur true. Cela peut entraîner une différence entre ce qui apparaît dans les métriques de capacité que vous obtenez dans le Portail Azure et ce qui est signalé par un rapport d’inventaire.

Seuls les objets BLOB qui sont supprimés explicitement apparaissent dans les rapports. Par conséquent, pour obtenir une liste complète de tous les objets BLOB supprimés de manière réversible (répertoire et tous les objets BLOB enfants), les charges de travail doivent supprimer chaque objet BLOB d’un répertoire avant de supprimer le répertoire lui-même.

Partager via