Snapshot Blob

Article
04/06/2023

L'opération Snapshot Blob crée un instantané en lecture seule d'un objet blob.

Requête

Vous pouvez construire la Snapshot Blob requête comme suit. HTTPS est recommandé. Remplacez moncompte par le nom de votre compte de stockage :

URI de requête de méthode PUT	Version HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=snapshot`	HTTP/1.1

URI du service de stockage émulé

Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et Stockage Blob Azure port comme 127.0.0.1:10000, suivis du nom du compte émulé :

URI de requête de méthode PUT	Version HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=snapshot`	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier le paramètre supplémentaire suivant sur l’URI de la demande.

Paramètre	Description
`timeout`	facultatif. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définition des délais d’expiration pour les opérations de stockage Blob.

En-têtes de requête

Le tableau suivant décrit les en-têtes de demande obligatoires ou facultatifs.

En-tête de requête	Description
`Authorization`	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
`Date` ou `x-ms-date`	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
`x-ms-version`	Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
`x-ms-meta-name:value`	facultatif. Spécifie une paire nom-valeur définie par l’utilisateur associée à l’objet blob. Si vous ne spécifiez aucune paire nom-valeur, l’opération copie les métadonnées de l’objet blob de base dans le instantané. Si vous spécifiez une ou plusieurs paires nom-valeur, le instantané est créé avec les métadonnées spécifiées et les métadonnées ne sont pas copiées à partir de l’objet blob de base. Notez qu’à compter de la version 2009-09-19, les noms de métadonnées doivent respecter les règles d’affectation de noms pour les identificateurs C#. Pour plus d’informations, consultez Nommage et référencement de conteneurs, d’objets blob et de métadonnées .
`If-Modified-Since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour prendre une instantané de l’objet blob, uniquement s’il a été modifié depuis la date/heure spécifiée. Si l’objet blob de base n’a pas été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable).
`If-Unmodified-Since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour prendre une instantané de l’objet blob, uniquement s’il n’a pas été modifié depuis la date/heure spécifiée. Si l’objet blob de base a été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable).
`If-Match`	facultatif. Valeur `ETag`. Spécifiez une `ETag` valeur pour cet en-tête conditionnel afin de prendre une instantané de l’objet blob, uniquement si sa `ETag` valeur correspond à la valeur spécifiée. Si les valeurs ne correspondent pas, le Stockage Blob retourne status code 412 (échec de la condition préalable).
`If-None-Match`	facultatif. Valeur `ETag`. Spécifiez une `ETag` valeur pour cet en-tête conditionnel afin de prendre une instantané de l’objet blob, uniquement si sa `ETag` valeur ne correspond pas à la valeur spécifiée. Si les valeurs sont identiques, le Stockage Blob retourne status code 412 (échec de la condition préalable).
`x-ms-encryption-scope`	facultatif. Indique l’étendue de chiffrement à utiliser pour chiffrer le contenu de la demande. Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
`x-ms-lease-id:<ID>`	facultatif. Si vous spécifiez cet en-tête, l’opération est effectuée uniquement si les deux conditions suivantes sont remplies : - Le bail de l’objet blob est actuellement actif. - L’ID de bail spécifié dans la demande correspond à celui de l’objet blob. Si cet en-tête est spécifié et que l’une de ces conditions n’est pas remplie, la demande échoue. L’opération `Snapshot Blob` échoue avec status code 412 (échec de la condition préalable).
`x-ms-client-request-id`	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

Cette opération prend également en charge l’utilisation d’en-têtes conditionnels pour exécuter l’opération, uniquement si une condition spécifiée est remplie. Pour plus d’informations, consultez Spécification d’en-têtes conditionnels pour les opérations de stockage Blob.

En-têtes de requête (clés de chiffrement fournies par le client)

À compter de la version 2019-02-02, vous pouvez spécifier les en-têtes suivants sur la demande de chiffrement d’un objet blob avec une clé fournie par le client. Le chiffrement avec une clé fournie par le client (et l’ensemble d’en-têtes correspondant) est facultatif. Si un objet blob a été précédemment chiffré avec une clé fournie par le client, ces en-têtes doivent être inclus dans la demande pour terminer correctement l’opération de lecture.

En-tête de requête	Description
`x-ms-encryption-key`	Obligatoire. Clé de chiffrement AES-256 encodée en Base64.
`x-ms-encryption-key-sha256`	Obligatoire. Hachage SHA256 codé en Base64 de la clé de chiffrement.
`x-ms-encryption-algorithm: AES256`	Obligatoire. Spécifie l’algorithme à utiliser pour le chiffrement. La valeur de cet en-tête doit être définie `AES256`.

Corps de la demande

Aucun.

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie renvoie le code d'état 201 (Créé). Pour plus d’informations sur les codes status, consultez Codes d’état et d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

Syntaxe	Description
`x-ms-snapshot: <DateTime>`	Retourne une `DateTime` valeur qui identifie de manière unique le instantané. La valeur de cet en-tête indique la version instantané et vous pouvez l’utiliser dans les demandes suivantes pour accéder au instantané. Notez que cette valeur est opaque.
`ETag`	du `ETag` instantané. Si la version de la demande est 2011-08-18 ou version ultérieure, la `ETag` valeur sera entre guillemets. Notez qu’un instantané ne peut pas être écrit dans, de sorte que le `ETag` d’un instantané particulier ne change jamais. Toutefois, le `ETag` du instantané sera différent de celui de l’objet blob de base si de nouvelles métadonnées sont fournies avec la `Snaphot Blob` requête. Si aucune métadonnées n’est spécifiée avec la demande, le `ETag` du instantané sera identique à celui de l’objet blob de base, au moment où le instantané a été pris.
`Last-Modified`	Heure de la dernière modification de l'instantané. Pour plus d’informations, consultez Représentation de valeurs date-heure dans les en-têtes. Notez qu’un instantané ne peut pas être écrit dans, de sorte que l’heure de la dernière modification d’un instantané ne change jamais. Toutefois, l’heure de la dernière modification du instantané sera différente de celle de l’objet blob de base si de nouvelles métadonnées sont fournies avec la `Snaphot Blob` requête. Si aucune métadonnées n’est spécifiée avec la demande, l’heure de la dernière modification de l’instantané sera identique à celle de l’objet blob de base, au moment où le instantané a été effectué.
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour la résolution des problèmes de la demande. Pour plus d’informations, consultez Résolution des problèmes liés aux opérations d’API.
`x-ms-version`	Indique la version du Stockage Blob qui a été utilisée pour exécuter la demande. Cet en-tête est renvoyé pour les demandes effectuées avec la version 2009-09-19 ou une version ultérieure.
`Date`	Valeur de date/heure UTC qui indique l’heure à laquelle la réponse a été lancée. Le service génère cette valeur.
`x-ms-request-server-encrypted: true/false`	Version 2019-02-02 ou ultérieure. La valeur de cet en-tête est définie sur `true`, si le contenu de la demande est correctement chiffré à l’aide de l’algorithme spécifié. Sinon, la valeur est `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 ou ultérieure. Retourné si la demande a utilisé une clé fournie par le client pour le chiffrement. Le client peut s’assurer que le contenu de la demande est correctement chiffré à l’aide de la clé fournie.
`x-ms-encryption-scope`	Version 2019-02-02 ou ultérieure. Retourné si la demande utilisait une étendue de chiffrement. Le client peut s’assurer que le contenu de la demande est correctement chiffré à l’aide de l’étendue de chiffrement.
`x-ms-version-id: <DateTime>`	Version 2019-12-12 et ultérieures. Retourne une valeur opaque `DateTime` qui identifie de manière unique l’objet blob. La valeur de cet en-tête indique la version de l’objet blob et vous pouvez l’utiliser dans les demandes suivantes pour accéder à l’objet blob.
`x-ms-client-request-id`	Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête `x-ms-client-request-id` , s’il est présent dans la demande. La valeur est au maximum de 1 024 caractères ASCII visibles. Si l’en-tête `x-ms-client-request-id` n’est pas présent dans la demande, il ne sera pas présent dans la réponse.

Response body

Aucun.

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Snapshot Blob comme décrit ci-dessous.

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe ou un principal de service Microsoft Entra appelle l’opérationSnapshot Blob, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Rôle intégré le moins privilégié :Contributeur aux données blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour l’accès aux données d’objets blob.

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la SAP.

L’opération Snapshot Blob prend en charge trois types de signatures d’accès partagé : sas de délégation d’utilisateur, SAP de service et SAP de compte.

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser Microsoft Entra informations d’identification plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez Microsoft Entra informations d’identification pour créer une sap de délégation d’utilisateur, si possible.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de service ou un jeton SAP de compte ne sont pas autorisés lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de délégation d’utilisateur

Une sap de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra ainsi que par les autorisations spécifiées pour la sap.

L’appel de l’opération à l’aide Snapshot Blob d’un jeton SAP délégué à un conteneur ou à une ressource blob nécessite l’autorisation Créer (c) ou Écrire (w) dans le cadre du jeton SAP de délégation utilisateur.

Pour en savoir plus sur la sap de délégation d’utilisateur, consultez Créer une sap de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une sap de service délègue l’accès à une ressource dans un seul service Stockage Azure, tel que le stockage blob.

Pour en savoir plus sur la SAP de service, consultez Créer une SAP de service.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Snapshot Blob	Objet blob (b)	Objet (o)	Créer (c) ou Écrire (w)

Pour en savoir plus sur la SAP de compte, consultez Créer une SAP de compte.

L’opération Snapshot Blob prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée dans la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

Les instantanés fournissent des versions en lecture seule des objets blob. Après avoir créé un instantané, vous pouvez le lire, le copier ou le supprimer, mais vous ne pouvez pas le modifier.

Un instantané fournit un moyen pratique pour sauvegarder les données d'objets blob. Vous pouvez utiliser un instantané pour restaurer un objet blob vers une version antérieure en appelant Copy Blob, pour remplacer un objet blob de base avec son instantané.

Lorsque vous créez un instantané, Stockage Blob retourne une DateTime valeur qui identifie de manière unique le instantané par rapport à son objet blob de base. Utilisez cette valeur pour exécuter d'autres opérations sur l'instantané. Notez que vous devez traiter cette DateTime valeur comme opaque.

La DateTime valeur identifie le instantané sur l’URI. Par exemple, un objet blob de base et ses instantanés ont des URI semblables à ce qui suit :

Objet blob de base : http://myaccount.blob.core.windows.net/mycontainer/myblob
Instantané: http://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>

Notez que chaque fois que vous appelez l’opérationSnapshot Blob, vous créez un instantané, avec une valeur uniqueDateTime. Un objet blob peut prendre en charge plusieurs instantanés. Les instantanés existants ne sont jamais remplacés. Vous les supprimez explicitement en appelant Supprimer l’objet blob et en définissant l’en-tête x-ms-include-snapshots sur la valeur appropriée.

Un appel réussi à Snapshot Blob retourne une DateTime valeur dans l’en-tête de x-ms-snapshot réponse. Vous pouvez ensuite utiliser cette DateTime valeur pour effectuer des opérations de lecture, de suppression ou de copie sur une version de instantané particulière. Vous pouvez appeler n’importe quelle opération de stockage Blob valide pour une instantané en spécifiant ?snapshot=<DateTime> après le nom de l’objet blob.

Quand vous créez un instantané d'un objet blob, les propriétés système suivantes sont copiées dans l'instantané avec les mêmes valeurs :

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
x-ms-blob-sequence-number (pour les objets blob de pages uniquement)
x-ms-blob-committed-block-count (pour les objets blob d’ajout uniquement)
x-ms-copy-id (version 2012-02-12 et ultérieure)
x-ms-copy-status (version 2012-02-12 et ultérieure)
x-ms-copy-source (version 2012-02-12 et ultérieure)
x-ms-copy-progress (version 2012-02-12 et ultérieure)
x-ms-copy-completion-time (version 2012-02-12 et ultérieure)
x-ms-copy-status-description (version 2012-02-12 et ultérieure)

La liste de blocs validée de l’objet blob de base est également copiée dans le instantané, si l’objet blob est un objet blob de blocs. Les blocs non validés ne sont pas copiés.

L’objet blob instantané a toujours la même taille que l’objet blob de base au moment où le instantané est pris. La valeur de l’en-tête Content-Length de l’objet blob instantané sera la même que celle de l’objet blob de base.

Vous pouvez spécifier une ou plusieurs nouvelles valeurs de métadonnées pour l'instantané en spécifiant l'en-tête x-ms-meta-name:value dans la demande. Si cet en-tête n’est pas spécifié, les métadonnées associées à l’objet blob de base sont copiées dans le instantané.

Toutes les étiquettes associées à l’objet blob de base sont copiées dans le instantané. Il n’est pas possible de définir de nouvelles valeurs d’étiquette pour le instantané.

Vous pouvez spécifier des en-têtes conditionnels sur la demande pour prendre une instantané de l’objet blob uniquement si une condition est remplie. Si la condition spécifiée n’est pas remplie, le instantané n’est pas créé. Le service retourne status code 412 (Échec de la condition préalable), ainsi que des informations d’erreur supplémentaires sur la condition non remplie.

Si l’objet blob de base a un bail actif, vous pouvez prendre une instantané de l’objet blob tant que l’une des conditions suivantes est vraie de la demande :

L'en-tête conditionnel x-ms-lease-id est spécifié et l'ID du bail actif pour l'objet blob de base est inclus dans la demande. Cette condition spécifie que le instantané être créé uniquement si le bail est actif et que l’ID de bail spécifié correspond à celui associé à l’objet blob.
L’en-tête x-ms-lease-id n’est pas spécifié du tout, auquel cas le bail en écriture exclusive est ignoré.

Notez qu’un bail associé à l’objet blob de base n’est pas copié dans le instantané. Les instantanés ne peuvent pas être loués.

Lorsque vous copiez un objet blob de base à l’aide de l’opération Copier l’objet blob , les instantanés de l’objet blob de base ne sont pas copiés dans l’objet blob de destination. Quand un objet blob de destination est remplacé par une copie, tous les instantanés associés à l'objet blob de destination restent intacts sous son nom.

Vous pouvez copier un objet blob instantané dans son objet blob de base pour restaurer une version antérieure d'un objet blob. L'instantané est conservé, mais l'objet blob de base est remplacé par une copie qui peut être lue et modifiée.

Notes

La promotion d’un instantané n’entraîne pas de frais supplémentaires pour les ressources de stockage. Cela est dû au fait que les blocs ou les pages sont partagés entre le instantané et l’objet blob de base.

Vous pouvez définir un niveau d’objet blob sur un instantané, à compter de la version REST 2019-12-12. Si un niveau est défini sur un objet blob racine, tous les instantanés héritent du niveau de l’objet blob de base. L’instantané sur un objet blob archivé échoue. La définition explicite du niveau sur un objet entraîne la facturation de la taille complète de l’objet. L’utilisation d’une instantané d’un objet blob qui a le jeu de niveaux entraîne la facturation de la copie complète de l’objet blob racine et de l’instantané. Pour plus d’informations sur la hiérarchisation au niveau des objets blob de blocs, consultez Niveaux de stockage chaud, froid et archive.

Il existe quelques différences entre les comptes Azure Stockage Premium et les comptes de stockage standard, en termes d’instantanés :

Le nombre d’instantanés par objet blob de page dans un compte Stockage Premium est limité à 100. Si cette limite est dépassée, l’opération retourne le Snapshot Blob code d’erreur 409 (Nombre d’instantanés dépassé).
Vous pouvez prendre une instantané d’un objet blob de page dans un compte Stockage Premium une fois toutes les dix minutes. Si ce taux est dépassé, l’opération retourne le Snapshot Blob code d’erreur 409 (Taux d’opération d’instantané dépassé).
Vous ne pouvez pas lire un instantané d’un objet blob de pages dans un compte Stockage Premium à l’aide de Get Blob. Dans ce cas, le service retourne le code d’erreur 400 (Opération non valide). Toutefois, vous pouvez appeler Get Blob Properties et Get Blob Metadata sur un instantané.

Pour lire un instantané, vous pouvez utiliser l’opération Copier un objet blob pour copier un instantané dans un autre objet blob de page dans le compte. L’objet blob de destination pour l'opération de copie ne doit pas avoir d'instantanés. Si l'objet blob de destination contient un ou plusieurs instantanés, l'opération Copy Blob renvoie le code d'erreur 409 (SnapshotsPresent).

Pour plus d’informations, consultez Utilisation des opérations de stockage Blob avec Azure Stockage Premium.

Lorsque le contrôle de version est activé, la création d’un instantané d’un objet blob génère également une nouvelle version et enregistre la version précédente de l’objet blob de base. Le x-ms-version-id paramètre retourne une valeur opaque DateTime pour la nouvelle version de l’objet blob.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes cumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture sont comptabilisées dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour Snapshot Blob les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Snapshot Blob	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Lire les opérations

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez Stockage Blob Azure Tarification.

Voir aussi

Création d’un instantané d’objet blob

Autoriser les demandes à Stockage Azure

Codes d’état et d’erreur

Codes d’erreur Stockage Blob