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 contrôle de version du stockage d’objets blob pour gérer 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 réduire les coûts, utilisez une stratégie de gestion du cycle de vie pour supprimer automatiquement les anciennes versions. Pour plus d’informations sur la gestion du cycle de vie, consultez Optimisez les coûts en automatisant des niveaux d’accès Stockage Blob Azure.
Fonctionnement du contrôle de version des objets blob
La version capture l’état de l’objet blob à un moment donné. Chaque version est identifiée par un ID de version. Lorsque le contrôle de version d’objet blob est activé pour un compte de stockage, stockage Azure crée automatiquement une nouvelle version avec un ID unique lorsqu’un objet blob est créé pour la première fois et chaque fois que l’objet blob est ensuite modifié.
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.
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 la façon dont les versions sont créées lors d’opérations d’écriture et dont une version antérieure peut être promue en version actuelle :
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 conserver moins de 1 000 versions par objet blob. Vous pouvez utiliser la gestion de cycle de vie pour supprimer automatiquement les anciennes versions. Pour plus d’informations sur la gestion du cycle de vie, consultez Optimisez les coûts en automatisant des niveaux d’accès Stockage Blob Azure.
Les versions d’objets blob sont immuables. Vous ne pouvez pas modifier le contenu ou les métadonnées d’une version existante de l’objet blob.
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.
Important
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 appelez une opération d’écriture pour créer ou modifier un objet blob, stockage Azure retourne l’en-tête x-ms-version-id dans la réponse. Cet en-tête contient l’ID de version de la version actuelle du blob 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
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. Pour capturer les modifications de ces opérations, créez un instantané manuel :
- Put Page (objet blob de pages)
- Append Block (objet blob d’ajouts)
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 appelez l’opération Delete Blob sans spécifier un ID de version, la version actuelle devient une version antérieure, puis 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é, utilisez la gestion du cycle de vie des blobs. Pour plus d’informations sur la gestion du cycle de vie, voir Gérer le cycle de vie du stockage Azure Blob.
Activer/désactiver le contrôle de version des objets blob
Pour savoir comment activer le contrôle de version des objets blob, consultez Activer et gérer le contrôle de version 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. Lorsque vous désactivez le contrôle de version des objets blob, toutes les versions existantes restent accessibles dans votre compte de stockage. Aucune nouvelle version n’est créée par la suite.
Une fois le contrôle de version désactivé, la modification de la version actuelle crée un objet 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.
Contrôle de version des objets blob et suppression réversible
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 le contrôle de version des objets blob et la suppression réversible d’objets blob sont tous deux activés sur un compte de stockage, alors le remplacement d’un objet blob crée automatiquement une nouvelle version. La nouvelle version n’est pas supprimée de manière réversible et n’est pas supprimée à l’expiration de la période de conservation de la suppression réversible. Aucun instantané supprimé de manière réversible n’est créé.
Suppression d’un objet blob ou d’une version
Si vous activez la version et la suppression douce 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 de versions d’objet blob. Lorsque vous supprimez une version précédente du blob, cette version est supprimée en douceur. La version supprimée en douceur est conservée jusqu’à la fin de la période de rétention pour suppression douce, puis elle est supprimée définitivement.
Pour supprimer une version antérieure d’un blob, appelez l’opération Delete Blob et spécifiez l’ID de version.
Le diagramme suivant montre ce qui se passe lorsque vous supprimez un objet blob ou une version d’un objet blob.
Restauration d’une version supprimée de manière réversible
Vous pouvez utiliser l’opération Annuler la suppression d’un objet blob pour restaurer des versions supprimées 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.
Le schéma suivant montre comment restaurer les versions de blob supprimés en douce en utilisant l’opération Undelete Blob , et comment restaurer la version actuelle de l’blob en utilisant l’opération Copy Blob .
À la fin de la période de rétention de suppression réversible, toutes les versions d’objet blob supprimées de manière réversible sont définitivement supprimées.
Contrôle de version des objets blob et instantanés d’objets blob
Un instantané d’objet blob est une copie en lecture seule d’un objet blob prise à un instant donné. Les instantanés blob et les versions blob sont similaires, mais vous ou votre application créez manuellement un snapshot, tandis qu’une version blob est créée automatiquement lors d’une opération d’écriture ou de suppression lorsque vous activez la version blob pour votre compte de stockage.
Important
Microsoft recommande qu'une fois que vous avez activé le contrôle de version des blobs, vous mettiez également à jour votre application pour arrêter de prendre des instantanés des blobs de blocs. Si vous activez le contrôle de version pour votre compte de stockage, il capture et conserve toutes les mises à jour et suppressions d’objets blob de blocs à l’aide de versions. Prendre des instantanés n’apporte aucune protection supplémentaire à vos données de blobs de blocs si le versionnement des blobs est activé, et cela peut augmenter les coûts et la complexité des applications.
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.
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. |
Tarification et facturation
Activer la version des blobs peut entraîner des frais supplémentaires de stockage de données sur votre compte. Lors de la conception de votre application, soyez conscient de la manière dont ces charges peuvent s’accumuler afin de minimiser les coûts.
Les versions d’objets blob, comme celles des instantanés d’objets blob, sont facturées au même tarif que les données actives. La façon dont vous payez les versions dépend du fait que vous définissez explicitement le niveau pour les versions actuelles ou précédentes d’un blob (ou des 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 payez pour les blocs de données uniques de cet objet blob, de ses versions et de tous les instantanés éventuels. 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 payez pour l’objet entier, qu’ils se retrouvent ou non ensuite dans le même niveau. Pour plus d’informations, voir Facturation lorsque le niveau blob est explicitement défini.
Remarque
L’activation du contrôle de version pour des données fréquemment remplacées peut augmenter les frais de capacité de stockage et la latence pendant les opérations d’énumération. Vous pouvez limiter ces problèmes en stockant les données fréquemment remplacées dans un compte de stockage distinct avec contrôle de version désactivé.
L’activation des versions sur les comptes de stockage sauvegardés fréquemment peut déclencher des frais de récupération de données lorsque les versions sont stockées sur des niveaux d’accès froid 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 explicitement le niveau d’aucune version d’un objet blob, vous payez pour les blocs ou pages uniques de toutes les versions et de tous les instantanés éventuels. Vous payez pour les 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, et vous payez pour les données uniques par bloc ou page.
Quand vous remplacez un bloc dans un blob, vous payez pour ce bloc en tant que 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. Après avoir validé à nouveau le bloc, il diverge de son homologue de la version précédente, et vous payez 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 vous payez pour des blocs uniques, gardez à l’esprit que mettre à jour un blob lorsque le versioning est activé entraîne plus de blocs uniques 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. 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, vous mettez à jour un bloc (le bloc 3 du diagramme) dans le blob. 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. En conséquence, vous payez pour quatre blocs.
Scénario 3
Dans le scénario 3, vous mettez à jour le blob, mais pas la version. Vous remplacez le bloc 3 par le bloc 4 dans la masse actuelle, mais la version précédente reflète toujours le bloc 3. En conséquence, vous payez pour quatre blocs.
Scénario 4
Dans le scénario 4, vous mettez complètement à jour la version actuelle et elle ne contient aucun de ses blocs originaux. En conséquence, vous payez 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 lorsque le niveau de l’objet blob est explicitement défini
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, même s’il partage 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 sur une version, actuelle ou précédente | 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 |
| Pour archiver | Longueur totale du contenu de toutes les versions et tous les 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 la façon dont les objets sont facturés quand un objet blob avec contrôle de version est déplacé 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 remplacez une version actuelle dont le niveau est explicitement défini, les versions précédentes de l’objet blob supprimé de manière réversible vous sont facturées sur la base de leur longueur de contenu totale. Pour plus d’informations sur la manière dont le contrôle de version d’objet blob et de la suppression réversible fonctionnent ensemble, consultez Contrôle de version des objets blob et suppression réversible.
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 versionnement n'est pas pris en charge pour les blobs que vous téléchargez en utilisant les API de Data Lake Storage.