Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez activer le versioning des blobs pour maintenir automatiquement les versions précédentes d’un objet. Lorsque vous activez la version des blobs, vous pouvez accéder aux versions antérieures d’un blob pour récupérer vos données si elles sont modifiées ou supprimées.
Attention
Après que vous avez activé le contrôle de version d’objet blob pour un compte de stockage, chaque opération d’écriture sur un objet blob dans ce compte entraîne la création d’une nouvelle version. Pour cette raison, activer la version des blobs pourrait entraîner des coûts supplémentaires. Pour minimiser les coûts, utilisez une politique de gestion du cycle de vie ou une tâche Storage Actions pour supprimer automatiquement les versions précédentes.
Configuration recommandée de la protection des données
La version des blobs est l’une des nombreuses fonctionnalités de protection des données. Le choix de la bonne fonctionnalité ou combinaison dépend de votre charge de travail et de ce contre quoi vous vous protégez. Pour en savoir plus sur les recommandations de Microsoft en matière de protection des données, consultez Aperçu de la protection des données.
Versions et instantanés
Une version blob est similaire à un snapshot, mais les deux diffèrent par leur création et leur utilité. Une version est automatique et gérée par le système : stockage Azure crée une nouvelle version à chaque écriture ou suppression lorsque le contrôle de version des objets blob est activé, sans logique d’application. Un instantané est manuel et piloté par l’application : vous créez explicitement une copie à un instant donné lorsque votre application juge qu’un instantané est nécessaire.
Utilisez le versionnement lorsque vous souhaitez une protection automatique et continue contre les écrasements et suppressions accidentels ou malveillants. Utilisez des instantanés lorsque vous souhaitez des copies à un instant donné, comme un point de contrôle fiable avant une mise à jour planifiée. Microsoft recommande d’arrêter de prendre des instantanés des objets blob de blocs une fois le contrôle de version activé.
Fonctionnement du contrôle de version des objets blob
La version capture l’état de l’objet blob à un moment donné. Chaque version possède un identifiant de version. Lorsque vous activez le versioning des blobs pour un compte de stockage, stockage Azure crée automatiquement une nouvelle version avec un ID unique lors de la création initiale d’un blob et à chaque modification du blob.
Un ID de version peut identifier la version actuelle ou une version antérieure. Un blob ne peut avoir qu’une seule version actuelle à la fois, c’est-à-dire son état actuel. Un blob peut avoir plusieurs versions précédentes.
Lorsque vous créez un blob, une seule version existe et cette version est la version actuelle. Lorsque vous modifiez un blob existant, la version actuelle devient une version antérieure. Une nouvelle version est créée pour capturer l’état mis à jour, et cette nouvelle version est la version actuelle. Lorsque vous supprimez un objet blob, la version actuelle de l’objet blob devient la version antérieure et il n’y a plus de version actuelle. Toutes les versions antérieures du blob sont conservées.
Le diagramme suivant montre comment les versions sont créées lors des opérations d’écriture, et comment une version précédente peut être promue vers la version actuelle :
Les versions précédentes des blobs sont immuables, ce qui signifie que vous ne pouvez pas modifier le contenu ou les métadonnées.
Important
Le fait de disposer d’un grand nombre de versions par blob peut augmenter la latence des opérations de listage des blobs. Microsoft recommande de maintenir moins de 1 000 versions par blob. Vous pouvez utiliser une stratégie Lifecycle Management ou une tâche Storage Actions pour supprimer automatiquement les anciennes versions.
Le versionnement blob ne peut pas vous aider à récupérer après la suppression accidentelle d’un compte de stockage ou d’un conteneur. Pour empêcher toute suppression accidentelle du compte de stockage, configurez un verrou sur la ressource du compte de stockage. Pour plus d’informations sur le verrouillage d’un compte de stockage, consultez Appliquer un verrou Azure Resource Manager à un compte de stockage.
ID de version
Chaque version en blob a un ID de version unique. La valeur de l’ID de version correspond à l’horodatage de la mise à jour du blob. Vous attribuez l’ID de version lors de la création.
Vous pouvez lire ou supprimer une version spécifique d’un blob en utilisant son identifiant de version. Si vous n’incluez pas l’ID de version, l’opération cible la version actuelle.
Lorsque vous effectuez une opération d’écriture pour créer ou modifier un blob, stockage Azure renvoie l’en-tête x-ms-version-id dans la réponse. Cet en-tête contient l’ID de version de la version du blob actuelle créée par l’opération d’écriture.
L’identifiant de la version reste le même pendant toute la durée de vie de la version.
Contrôle de version sur les opérations d’écriture
Lorsque vous activez la version des blobs, chaque opération d’écriture sur un blob crée une nouvelle version. Les opérations d’écriture incluent Put Blob, Put block List, Copy Blobet Set Blob Metadata.
Si l’opération d’écriture crée un nouveau blob, le blob résultant est la version actuelle du blob. Si l’opération d’écriture modifie un blob existant, la version actuelle devient une version précédente, et une nouvelle version actuelle capture le blob mis à jour.
Le diagramme suivant montre comment les opérations d’écriture affectent les versions d’objets blob. Pour simplifier, les diagrammes de cet article affichent l’ID de version comme une simple valeur entière. En réalité, l’ID de version est un horodateur. La version actuelle est affichée en bleu et les versions précédentes sont affichées en gris.
Remarque
Un blob que vous avez créé avant que le versioning ne soit activé pour le compte de stockage n’a pas d’ID de version. Lorsque vous modifiez ce blob, le blob modifié devient la nouvelle version actuelle, et l’état du blob avant la mise à jour devient une version précédente. La version actuelle se voit attribuer un identifiant de version correspondant à son moment de création.
Lorsque vous activez la version des blobs pour un compte de stockage, toutes les opérations d’écriture sur les blobs de bloc déclenchent la création d’une nouvelle version, sauf l’opération Put Block .
Pour les objets blob de pages et les objets blob d’ajout, seul un sous-ensemble de pages d’opérations d’écriture déclenche la création d’une version. Ces opérations comprennent :
Les opérations suivantes ne déclenchent pas la création d’une nouvelle version :
- Put Page (objet blob de pages)
- Append Block (objet blob d’ajouts)
Pour capturer les changements issus de ces opérations, prenez un instantané manuel. Pour plus d’informations, voir instantanés de blob.
Toutes les versions d’un blob doivent avoir le même type de blob. Si un objet blob a des versions antérieures, vous ne pouvez pas remplacer un objet blob d’un type par un autre type, sauf si vous supprimez d’abord l’objet blob et toutes ses versions.
Contrôle de version sur les opérations de suppression
Lorsque vous effectuez l’opération Supprimer le Blob sans spécifier d’identifiant de version, la version actuelle devient une version précédente, et il n’y a plus de version actuelle. L’opération préserve toutes les versions existantes du blob.
Le diagramme suivant montre l’effet d’une opération de suppression sur un objet blob avec contrôle de version :
Pour supprimer la version spécifique d’un blob, indiquez l’ID de cette version sur l’opération de suppression. Si vous activez également la suppression réversible des blobs pour le compte de stockage, le système conserve la version jusqu’à l’expiration de la période de rétention de la suppression réversible.
L’écriture de nouvelles données dans le blob crée une nouvelle version actuelle de ce blob. Cette action n’affecte aucune version existante, comme le montre le schéma suivant.
Niveaux d’accès
Vous pouvez déplacer n’importe quelle version d’un objet blob de blocs, y compris la version actuelle, vers un autre niveau d’accès en appelant l’opération Set Blob Tier. En déplaçant les anciennes versions d’un blob vers le niveau froid ou archivé, vous pouvez profiter d’une tarification de capacité plus basse. Pour plus d’informations, consultez Niveaux d’accès chaud, sporadique, froid et archive pour les données de blob.
Pour automatiser le déplacement des blobs de blocs vers le niveau approprié, créez une stratégie Lifecycle Management, créez une tâche Storage Actions ou activez le Smart Tier.
Activer/désactiver le contrôle de version des objets blob
Pour des instructions sur la façon d’activer ou de désactiver la gestion de versions des objets blob, voir Activer et gérer la gestion de versions des objets blob.
La désactivation du contrôle de version blob ne supprime pas les objets blob, les versions ou les instantanés existants. Quand vous désactivez le versioning des blobs, vous ne pouvez pas créer de nouvelles versions.
Après avoir désactivé la gestion des versions, modifier la version actuelle crée un blob qui n’est pas une version. Toutes les mises à jour ultérieures de l’objet blob remplacent ses données sans enregistrer l’état précédent. Toutes les versions existantes sont persistantes en tant que versions précédentes.
Vous pouvez lire ou supprimer des versions en utilisant l’identifiant de version après la désactivation du versioning. Vous pouvez également répertorier les versions d’un objet blob après la désactivation du contrôle de version.
La réplication d’objets s’appuie sur le contrôle de version blob. Avant de pouvoir désactiver le contrôle de version blob, vous devez supprimer toutes les stratégies de réplication d’objet sur le compte. Pour plus d’informations sur la réplication d’objets, consultez Réplication d’objets pour les objets Blob de blocs.
Le diagramme suivant montre comment la modification d’un objet blob après la désactivation du contrôle de version crée un objet blob sans contrôle de version. Toutes les versions existantes associées à l’objet blob sont conservées.
Prise en charge des fonctionnalités
La prise en charge de cette fonctionnalité peut être affecté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 la prise en charge des fonctionnalités de Stockage Blob dans les comptes stockage Azure pour évaluer la prise en charge de cette fonctionnalité.
Le contrôle de version des blobs est disponible pour les comptes de stockage Blob hérités, les comptes d’objets blobs de blocs Premium et les comptes v2 universels Standard. Les comptes de stockage avec un espace de noms hiérarchique activé pour une utilisation avec Azure Data Lake Storage ne sont actuellement pas pris en charge.
La version 2019-10-10 et ultérieure de l’API REST stockage Azure prend en charge le versionnement des blobs.
Le versionnement n'est pas pris en charge pour les blobs que vous téléchargez en utilisant les API de Data Lake Storage.
Autoriser des opérations sur des versions d’objets blob
Vous pouvez autoriser l’accès aux versions blob en utilisant l’une des approches suivantes :
- Utilisez le contrôle d’accès basé sur les rôles Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité Microsoft Entra. Microsoft recommande d’utiliser Microsoft Entra ID pour une sécurité et une facilité d’utilisation supérieures. Pour plus d’informations sur l’utilisation de Microsoft Entra ID avec des opérations sur les objets blob, consultez Autoriser l'accès aux données dans stockage Azure.
- Utilisez une signature d’accès partagé (SAS) pour déléguer l’accès aux versions de blob. Spécifier l’ID de version pour le type
bvde ressource signé, qui représente une version blob, afin de créer un jeton SAS pour les opérations sur une version spécifique. Pour plus d’informations sur les signatures d’accès partagé, consultez Accès limité aux ressources stockage Azure à l’aide de signatures d’accès partagé (SAP). - Utilisez les clés d’accès au compte pour autoriser les opérations contre les versions blob en utilisant la clé partagée. Pour plus d’informations, consultez Autoriser avec une clé partagée.
Le contrôle de version des objets blob est conçu pour protéger vos données contre toute suppression accidentelle ou malveillante. Pour améliorer la protection, la suppression d’une version d’objet blob nécessite des autorisations spéciales. Les sections suivantes décrivent les autorisations nécessaires pour supprimer une version d’objet blob.
Action RBAC Azure pour supprimer une version d’objet blob
Le tableau suivant indique quelles actions Azure RBAC prennent en charge la suppression d’un objet blob ou d’une version d’objet blob.
| Descriptif | Opération de service d’objet blob | Action sur les données RBAC Azure requise | Prise en charge de rôle intégré Azure |
|---|---|---|---|
| Suppression de la version actuelle | Delete Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete | Contributeur aux données Blob du stockage |
| Suppression d’une version précédente | Delete Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Propriétaire des données Blob du stockage |
Paramètres de la signature d’accès partagé (SAP)
La ressource signée pour une version d’objet blob est bv. Pour en savoir plus, consultez Créer une SAP de service ou Créer une SAP de délégation d’utilisateur.
Le tableau suivant présente l’autorisation requise sur une SAP pour supprimer une version d’objet blob.
| Autorisation | Symbole d’URI | Opérations autorisées |
|---|---|---|
| DELETE | x | Supprimez une version d’objet blob. |
Considérations sur la charge de travail existante
Supprimer un blob ne libère plus d’espace. Lorsque vous activez le versionnage, supprimer un blob ne supprime pas ses données. La version actuelle devient une version précédente qui persiste et continue d’entraîner des frais. Les workloads qui reposent sur des opérations de suppression pour récupérer du stockage continuent à entraîner des frais jusqu’à ce que vous supprimiez explicitement ces versions.
Les charges de travail avec beaucoup de remplacements peuvent accumuler les versions. Les versions persistent jusqu’à ce que vous les supprimiez explicitement. Cette persistance peut entraîner une accumulation de versions si vous ne les gérez pas correctement. Pour réduire les coûts, apportez des modifications au niveau du bloc afin qu’elles soient facturées au niveau du bloc sur l’ensemble des versions, minimisant ainsi les coûts par version.
Interactions entre les fonctionnalités
Suppression temporaire
Le contrôle de version d’objets blob et la suppression réversible d’objets blob font partie de la configuration recommandée de protection des données pour les comptes de stockage. Pour plus d'informations sur les recommandations de Microsoft pour la protection des données, consultez la vue d'ensemble de la protection des données.
Remplacement d’un blob
Si vous activez à la fois le contrôle de version des objets blob et leur suppression réversible pour un compte de stockage, le remplacement d’un objet blob crée automatiquement une nouvelle version précédente qui reflète l’état de l’objet blob avant l’opération d’écriture. La nouvelle version n’est pas supprimée de façon réversible et persiste jusqu’à suppression explicite. Aucun instantané supprimé de manière réversible n’est créé.
Suppression d’un objet blob ou d’une version
Si vous activez à la fois la gestion des versions et la suppression réversible pour un compte de stockage, lorsque vous supprimez un blob, la version actuelle du blob devient une version précédente. L’opération ne crée pas de nouvelle version ni d’instantanés supprimés de manière réversible. La période de rétention de suppression réversible ne s’applique pas à l’objet blob supprimé.
La suppression réversible offre une protection supplémentaire lors de la suppression des versions blob. Lorsque vous supprimez une version précédente du blob, l’opération supprime de façon réversible cette version. La version supprimée de manière réversible est conservée jusqu’à ce que la période de rétention de la suppression réversible soit écoulée, après quoi elle est définitivement supprimée.
Pour supprimer une version antérieure d’un blob, appelez l’opération Delete Blob et spécifiez l’ID de version.
Restauration d’une version supprimée de manière réversible
Utilisez l’opération Undelete Blob pour restaurer les versions supprimées de façon réversible pendant la période de rétention de la suppression réversible. L’opération Annuler la suppression d’un objet blob restaure toujours toutes les versions supprimées de manière réversible de l’objet blob. Vous ne pouvez pas restaurer une seule version supprimée de manière réversible.
La restauration de versions supprimées de manière réversible à l’aide de l’opération Restaurer l’objet blob ne promeut aucune version comme version actuelle. Pour restaurer la version actuelle, restaurez tout d’abord toutes les versions supprimées de manière réversible, puis utilisez l’opération Copy Blob pour copier une version antérieure vers une nouvelle version actuelle.
Après la période de rétention de suppression réversible, le système supprime définitivement toutes les versions de blob supprimées de manière réversible.
Instantanés d’objet blob
Un instantané d’objet blob est une copie en lecture seule d’un objet blob prise à un instant donné. Les instantanés de blob et les versions blob sont similaires, mais vous ou votre application créez manuellement un snapshot, tandis qu’une version blob est automatiquement créée lors d’une opération d’écriture ou de suppression lorsque vous activez le versioning des objets blob pour votre compte de stockage.
Important
Après avoir activé le contrôle de version des blobs, mettez à jour votre application pour qu’elle arrête de prendre des instantanés des blobs de blocs. Si vous activez la gestion des versions pour votre compte de stockage, les versions capturent et conservent toutes les mises à jour et suppressions d’objets blob de blocs. Prendre des instantanés n’offre aucune protection supplémentaire aux données d’objet blob de blocs si la gestion des versions des objets blob est activée, et cela peut augmenter les coûts et la complexité de l’application.
Instantané d’un objet blob lorsque le contrôle de version est activé
Bien que cela ne soit pas recommandé, vous pouvez prendre un instantané d’un objet blob qui fait également l’objet d’un contrôle de version. Si vous ne pouvez pas mettre à jour votre application pour arrêter de créer des instantanés d’objets blob lorsque vous activez le contrôle de version, votre application peut prendre en charge les instantanés et les versions.
Lorsque vous prenez un instantané d’un blob versionné, vous créez une nouvelle version en même temps que l’instantané. Vous créez aussi une nouvelle version actuelle lors de la prise de photo.
Le diagramme suivant montre ce qui se passe lorsque vous créez un instantané d’un objet blob avec contrôle de version. Dans le diagramme, les versions des objets blob et des instantanés avec l’ID de version 2 et 3 contiennent les mêmes données.
Limitations connues
Non pris en charge sur les comptes d’espaces de noms hiérarchiques (Azure Data Lake Storage), ni pour les blobs chargés via les API de Data Lake Storage.
Cela ne protège pas contre la suppression de conteneurs ou de comptes. Le versionnement fonctionne uniquement au niveau du blob. Supprimer un conteneur supprime tous les blobs et leurs versions. Pour récupérer après cette suppression, il faut la suppression réversible du conteneur. La protection contre la suppression du compte nécessite un verrouillage de ressource.
Les versions sont immuables. Vous ne pouvez pas modifier le contenu ou les métadonnées d’une version existante.
Toutes les versions d’un blob doivent avoir le même type de blob. Vous ne pouvez pas remplacer un blob par un blob d’un type différent s’il existe des versions antérieures, sauf si vous supprimez d’abord le blob et toutes ses versions.
Toutes les écritures ne créent pas une version. Consultez les informations précédemment présentées dans cet article détaillant les exceptions. Pour capturer ces états, utilisez un instantané manuel.
Impossible de désactiver le versioning tant que des politiques de réplication d’objets existent sur le compte. Vous devez d’abord supprimer toutes les politiques de réplication d’objets.
Undelete Blobrestaure toutes les versions supprimées de manière réversible d’un blob, pas une seule. Vous ne pouvez pas restaurer sélectivement une version supprimée. Undelete ne promeut jamais une version comme version actuelle.Plafond recommandé de 1 000 versions par blob. Dépasser cette limite dégrade les performances du listage des blobs.
Tarification et facturation
Lorsque vous activez le contrôle de version des blobs, des frais supplémentaires de stockage des données peuvent s’appliquer. Lorsque vous concevez votre application, réfléchissez à la manière dont ces frais pourraient s’accumuler afin de maintenir les coûts bas.
Vous êtes facturé pour les versions blob, comme les instantanés de blob, au même rythme que les données actives. La façon dont vous êtes facturé pour les versions varie selon que vous avez défini explicitement le niveau pour les versions actuelles ou précédentes d’un blob (ou instantanés). Pour plus d’informations sur les niveaux des blobs, consultez Niveaux d’accès chaud, sporadique, froid et archive pour les données de blob.
Si vous ne modifiez pas le niveau d’un objet blob ou d’une version, vous êtes facturé pour des blocs de données uniques sur cet objet blob, ses versions et ses éventuels instantanés. Pour plus d’informations, voir Facturation lorsque le niveau blob n’est pas explicitement défini.
Si vous modifiez le niveau d’un objet blob ou d’une version, vous êtes facturé pour l’intégralité de l’objet, que l’objet blob et sa version se retrouvent ou non dans le même niveau. Pour plus d’informations, voir Facturation lorsque le niveau blob est explicitement défini.
Remarque
Si vous activez la gestion des versions pour les données que vous écrasez fréquemment, vous pourriez constater une augmentation des charges de capacité de stockage et une latence accrue lors des opérations de listage. Pour répondre à ces préoccupations, stockez les données fréquemment écrasées dans un compte de stockage séparé avec le versionnement désactivé.
Si vous activez des versions sur des comptes de stockage souvent sauvegardés, vous pourriez déclencher des frais de récupération de données lorsque les versions sont stockées sur des niveaux d’accès cool ou froid.
Pour plus d’informations sur les détails de facturation des captures instantanées d’objets blob, consultez Captures instantanées d’objets blob.
Pour les comptes de stockage qui utilisent le niveau intelligent, les versions et les instantanés vous sont facturés sur la base de la taille totale du contenu. Pour plus d’informations, consultez Optimiser les coûts avec le niveau intelligent.
Facturation lorsque vous ne définissez pas explicitement le niveau de l’objet blob
Si vous ne définissez pas explicitement le niveau d’objet blob pour une version donnée d’un objet blob, vous êtes facturé pour les blocs ou pages uniques dans toutes les versions, ainsi que pour tous les instantanés qu’il pourrait avoir. Vous êtes facturé pour des données partagées entre les versions blob une seule fois. Lorsque vous mettez à jour un blob, les données de la nouvelle version actuelle divergent de celles stockées dans les versions précédentes, donc vous êtes facturé pour les données uniques par bloc ou page.
Lorsque vous remplacez un bloc dans un blob de blocs, vous êtes facturé pour ce bloc comme un bloc unique. Cette règle s’applique même si le bloc a le même identifiant de bloc et les mêmes données que dans la version précédente. Une fois que vous revalidez le bloc, il diffère de son homologue dans la version précédente et vous êtes facturé pour ses données. La même règle s’applique à une page dans un blob de pages que vous mettez à jour avec des données identiques.
Le stockage en blob n’a pas de moyen de déterminer si deux blocs contiennent des données identiques. Chaque bloc que vous téléchargez et commoutez est traité comme unique, même s’il a les mêmes données et le même identifiant de bloc. Comme on vous facture pour des blocs uniques, gardez à l’esprit que mettre à jour un blob lorsque le versioning est activé entraîne des blocs uniques supplémentaires et des frais supplémentaires.
Lorsque vous activez la version des blobs, appelez les opérations de mise à jour sur les blobs de blocs afin qu’ils mettent à jour le moins de blocs possible. Les opérations d’écriture qui permettent un contrôle plus précis des blocs sont Put Block et Put Block List. Put Block prépare les changements, mais la modification réelle et la création de la version se font lors de l’opération Put Block List. L’opération Put Blob , en revanche, remplace l’intégralité du contenu d’un blob et peut donc entraîner des charges supplémentaires.
Les scénarios suivants montrent comment les charges s’accumulent pour un blob de blocs et ses versions lorsque vous ne définissez pas explicitement le tier du blob.
Scénario 1
Dans le scénario 1, l’objet blob a une version antérieure. Le blob n’a pas été mis à jour depuis que la version a été créée. Des frais ne vous sont donc facturés que pour les blocs uniques 1, 2 et 3.
Scénario 2
Dans le scénario 2, un bloc (bloc 3 dans le schéma) dans le blob est mis à jour. Bien que le bloc mis à jour contienne les mêmes données et le même ID, il est différent du bloc 3 de la version précédente. Par conséquent, des frais pour quatre blocs sont facturés au compte.
Scénario 3
Dans le scénario 3, le blob est mis à jour, mais la version ne l’est pas. Le bloc 3 est remplacé par le bloc 4 dans le blob actuel, mais la version précédente reflète toujours le bloc 3. Par conséquent, des frais pour quatre blocs sont facturés au compte.
Scénario 4
Dans le scénario 4, la version actuelle est complètement mise à jour et ne contient aucun de ses blocs originaux. En conséquence, le compte est facturé pour les huit blocs uniques – quatre dans la version actuelle, et quatre combinés dans les deux versions précédentes. Ce scénario peut se produire si vous écrivez sur un blob en utilisant l’opération Put Blob , car elle remplace l’intégralité du contenu du blob.
Facturation lors de la définition explicite du niveau du blob
Si vous définissez explicitement le niveau de blob pour un blob, une version ou un instantané, vous payez pour la longueur totale du contenu de l’objet dans le nouveau tier, qu’il partage ou non des blocs avec un objet du tier d’origine. Vous payez aussi pour la longueur complète du contenu de la version la plus ancienne du palier original. Pour toute autre version antérieure ou tout instantané antérieur qui reste dans le niveau d’origine, vous payez pour les blocs uniques qu’ils ont en commun, comme décrit dans Facturation lorsque le niveau du blob n’est pas défini explicitement.
Déplacement d’un objet blob vers un nouveau niveau
Le tableau suivant décrit le comportement de facturation d’un blob ou d’une version lorsque vous le déplacez vers un nouveau niveau.
| Lorsque vous définissez le niveau de l’objet blob… | Nous vous facturons... |
|---|---|
| Explicitement défini sur une version, qu’elle soit actuelle ou antérieure | Longueur totale du contenu de cette version. Les versions qui n’ont pas de niveau explicitement défini sont facturées uniquement pour les blocs uniques.1 |
| Définir sur archive | La longueur complète du contenu de toutes les versions et instantanés. 1 |
1S’il y a d’autres versions ou snapshots précédents que vous n’avez pas déplacés de leur tier d’origine, ces versions ou snapshots sont facturés en fonction du nombre de blocs uniques qu’ils contiennent, comme décrit dans la facturation lorsque le tier blob n’est pas explicitement défini.
Le diagramme suivant illustre comment les objets sont facturés lorsque vous déplacez un blob versionné vers un autre niveau.
Vous ne pouvez pas annuler explicitement la définition du niveau pour un blob, une version ou un instantané. Si vous déplacez un blob vers un nouveau niveau puis le remettez à son niveau d’origine, vous payez pour la longueur totale du contenu de l’objet même s’il partage des blocs avec d’autres objets du palier d’origine.
Les opérations qui définissent explicitement le niveau d’un objet blob, d’une version ou d’une capture instantanée sont les suivantes :
- Définir un niveau d’objet blob
- Placer l’objet blob avec le niveau spécifié
- Placer la liste de blocs avec le niveau spécifié
- Copier l’objet blob avec le niveau spécifié
Suppression d’un objet blob quand la suppression réversible est activée
Lorsque vous activez la suppression douce des blobs, vous payez pour toutes les entités supprimées au même taux que les données en direct. Si vous supprimez ou écrasez une version actuelle pour laquelle vous avez explicitement défini le niveau, vous payez pour toutes les versions précédentes du blob supprimé de manière réversible sur la base de la taille totale du contenu. Pour plus d’informations sur la façon dont la version des blobs et la suppression douce fonctionnent ensemble, voir Interactions de fonctionnalités.
Surveillance et dépannage
Ma politique LCM ne supprime pas les versions quand je m’attends à : L’âge d’une version est basé sur le moment où vous avez initialement écrit ses données, et non sur le moment où elle est devenue une version précédente. Le chronomètre commence à la création du blob, pas à l’écrasement qui l’a poussé dans l’historique des versions. En conséquence, un blob qui est resté à jour longtemps avant d’être écrasé peut produire une version précédente qui dépasse déjà votre
daysAfterCreationGreaterThanseuil dès sa création, ce qui la fait supprimer presque immédiatement. Inversement, les versions de blobs récemment créés peuvent persister plus longtemps que prévu. Pour confirmer, vérifiez l’horodatage réel de création sur les versions plutôt que de supposer qu’il correspond à l’heure d’écrasement. Si vous devez baser la rétention sur le moment où une version est devenue non actuelle ou si vous souhaitez un contrôle plus granulaire que ce que permettent les seuils journaliers de la gestion du cycle de vie, envisagez d'utiliser stockage Azure Actions à la place. Pour plus d’informations, voir Actions de stockage.Ma facture reste élevée après avoir désactivé les versions : Les versions existantes restent jusqu’à ce que vous les supprimiez manuellement.
Je ne peux pas désactiver la gestion des versions. La réplication d’objets peut être configurée sur le compte. Supprimez d’abord toutes les politiques de réplication d’objets, puis désactivez la gestion des versions. Sinon, une politique d’immutabilité (WORM) peut exister sur un conteneur ou sur un compte dont le versionnement ne peut pas être désactivé.