Copie d'un objet blob

Article
02/13/2024

L'opération Copy Blob copie un objet blob vers une destination au sein du compte de stockage.

Dans les versions 2012-02-12 et ultérieures, la source d’une Copy Blob opération peut être un objet blob validé dans n’importe quel compte de stockage Azure.

À compter de la version 2015-02-21, la source d’une Copy Blob opération peut être un fichier Azure dans n’importe quel compte de stockage Azure.

Notes

Seuls les comptes de stockage créés à partir du 7 juin 2012 autorisent l’opération Copy Blob à copier à partir d’un autre compte de stockage.

Requête

Vous pouvez construire la Copy Blob requête comme suit. Nous recommandons HTTPS. Remplacez myaccount par le nom de votre compte de stockage, mycontainer par le nom de votre conteneur et myblob par le nom de votre objet blob de destination.

À compter de la version 2013-08-15, vous pouvez spécifier une signature d’accès partagé (SAP) pour l’objet blob de destination s’il se trouve dans le même compte que l’objet blob source. À compter de la version 2015-04-05, vous pouvez également spécifier une signature d’accès partagé pour l’objet blob de destination s’il se trouve dans un autre compte de stockage.

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

URI pour le 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 de stockage émulé :

URI de requête de méthode PUT	Version HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	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 les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre	Description
`timeout`	facultatif. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définir 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 requête obligatoires et 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. 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 aucune paire nom/valeur n’est spécifiée, l’opération copie les métadonnées de l’objet blob ou du fichier source vers l’objet blob de destination. Si une ou plusieurs paires nom/valeur sont spécifiées, l’objet blob de destination 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 ou du fichier source. À compter de la version 2009-09-19, les noms de métadonnées doivent respecter les règles de nommage des identificateurs C#. Pour plus d’informations, consultez Affectation de noms et référencement de conteneurs, d’objets blob et de métadonnées.
`x-ms-tags`	facultatif. Définit les balises encodées en chaîne de requête sur l’objet blob. Les balises ne sont pas copiées à partir de la source de copie. Pour plus d’informations, consultez Remarques. Pris en charge dans la version 2019-12-12 et ultérieure.
`x-ms-source-if-modified-since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob source a été modifié depuis la date/l'heure indiquées. Si l’objet blob source n’a pas été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
`x-ms-source-if-unmodified-since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob source n'a pas été modifié depuis la date/l'heure indiquées. Si l’objet blob source a été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
`x-ms-source-if-match`	facultatif. Valeur `ETag`. Spécifiez cet en-tête conditionnel pour copier l’objet blob source 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). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
`x-ms-source-if-none-match`	facultatif. Valeur `ETag`. Spécifiez cet en-tête conditionnel pour copier 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). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
`If-Modified-Since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob de destination a été modifié depuis la date/l'heure indiquées. Si l’objet blob de destination 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 copier l'objet blob uniquement si l'objet blob de destination n'a pas été modifié depuis la date/l'heure indiquées. Si l’objet blob de destination 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 copier l’objet blob uniquement si la valeur spécifiée `ETag` correspond à la `ETag` valeur d’un objet blob de destination existant. 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` ou caractère générique (). Spécifiez une `ETag` valeur pour cet en-tête conditionnel afin de copier l’objet blob uniquement si la valeur spécifiée `ETag` ne correspond pas à la `ETag` valeur de l’objet blob de destination. Spécifiez le caractère générique () pour effectuer l’opération uniquement si l’objet blob de destination n’existe pas. Si la condition spécifiée n’est pas remplie, le Stockage Blob retourne status code 412 (Échec de la condition préalable).
`x-ms-copy-source:name`	Obligatoire. Spécifie le nom du fichier ou de l’objet blob source. À compter de la version 2012-02-12, cette valeur peut être une URL d’une longueur maximale de 2 kibioctets (Kio) qui spécifie un objet blob. La valeur doit être encodée dans l’URL telle qu’elle apparaît dans un URI de requête. L’opération de lecture sur un objet blob source dans le même compte de stockage peut être autorisée via une clé partagée. À compter de la version 2017-11-09, vous pouvez également utiliser Microsoft Entra ID pour autoriser l’opération de lecture sur l’objet blob source. Toutefois, si la source est un objet blob dans un autre compte de stockage, l’objet blob source doit être public ou l’accès à celui-ci doit être autorisé via une signature d’accès partagé. Si l’objet blob source est public, aucune autorisation n’est requise pour effectuer l’opération de copie. À compter de la version 2015-02-21, l’objet source peut être un fichier dans Azure Files. Si l’objet source est un fichier qui sera copié dans un objet blob, le fichier source doit être autorisé par le biais d’une signature d’accès partagé, qu’il réside dans le même compte ou dans un compte différent. Seuls les comptes de stockage créés à partir du 7 juin 2012 autorisent l’opération `Copy Blob` à copier à partir d’un autre compte de stockage. Voici quelques exemples d’URL d’objet source : - `https://myaccount.blob.core.windows.net/mycontainer/myblob` - `https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>` - `https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>` Lorsque l’objet source est un fichier dans Azure Files, l’URL source utilise le format suivant. Notez que l’URL doit inclure un jeton SAS valide pour le fichier. - `https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken` Dans les versions antérieures à 2012-02-12, les objets blob ne peuvent être copiés que dans le même compte, et un nom de source peut utiliser les formats suivants : - Blob dans le conteneur nommé : `/accountName/containerName/blobName` - Capture instantanée dans le conteneur nommé : `/accountName/containerName/blobName?snapshot=<DateTime>` - Blob dans le conteneur racine : `/accountName/blobName` - Capture instantanée dans le conteneur racine : `/accountName/blobName?snapshot=<DateTime>`
`x-ms-lease-id:<ID>`	Obligatoire si l'objet blob de destination a un bail actif. L'ID de bail spécifié pour cet en-tête doit correspondre à l'ID de bail de l'objet blob de destination. Si la demande n’inclut pas l’ID de bail ou si l’ID n’est pas valide, l’opération échoue avec status code 412 (Échec de la condition préalable). Si cet en-tête est spécifié et que l’objet blob de destination n’a pas de bail actif, l’opération échoue avec status code 412 (échec de la condition préalable). Dans les versions 2012-02-12 et ultérieures, cette valeur doit spécifier un bail infini actif pour un objet blob loué. Un ID de bail à durée finie échoue avec status code 412 (échec de la condition préalable).
`x-ms-source-lease-id: <ID>`	Facultatif pour les versions antérieures à 2012-02-12 (non pris en charge dans 2012-02-12 et versions ultérieures). Spécifiez cet en-tête pour effectuer l’opération `Copy Blob` uniquement si l’ID de bail fourni correspond à l’ID de bail actif de l’objet blob source. Si cet en-tête est spécifié et que l’objet blob source n’a pas de bail actif, l’opération é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 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.
`x-ms-access-tier`	facultatif. Spécifie le niveau à définir sur l’objet blob cible. Cet en-tête est destiné aux objets blob de pages sur un compte Premium uniquement avec la version 2017-04-17 et les versions ultérieures. Pour obtenir la liste complète des niveaux pris en charge, consultez Stockage Premium hautes performances et disques managés pour machines virtuelles. Cet en-tête est pris en charge sur la version 2018-11-09 et ultérieure pour les objets blob de blocs. La hiérarchisation d’objets blob de blocs est prise en charge sur les comptes Stockage Blob ou usage général v2. Les valeurs valides sont `Hot`, `Cool`et `ColdArchive`. Note:`Cold` le niveau est pris en charge pour la version 2021-12-02 et ultérieure. Pour plus d’informations sur la hiérarchisation des objets blob de blocs, consultez Niveaux de stockage chaud, froid et archive.
`x-ms-rehydrate-priority`	facultatif. Indique la priorité avec laquelle réalimenter un objet blob archivé. Cet en-tête est pris en charge sur la version 2019-02-02 et ultérieure pour les objets blob de blocs. Les valeurs valides sont `High` et `Standard`. Vous ne pouvez définir la priorité sur un objet blob qu’une seule fois. Cet en-tête sera ignoré lors des demandes ultérieures adressées au même objet blob. La priorité par défaut sans cet en-tête est `Standard`.
`x-ms-seal-blob`	facultatif. Pris en charge sur la version 2019-12-12 ou ultérieure. Cet en-tête est valide uniquement pour les objets blob d’ajout. Il scelle l’objet blob de destination une fois l’opération de copie terminée.
`x-ms-immutability-policy-until-date`	Version 2020-06-12 et ultérieures. Spécifie la date de rétention jusqu’à définir sur l’objet blob. Il s’agit de la date jusqu’à laquelle l’objet blob peut être protégé contre toute modification ou suppression. Il suit RFC1123 format.
`x-ms-immutability-policy-mode`	Version 2020-06-12 et ultérieures. Spécifie le mode de stratégie d’immuabilité à définir sur l’objet blob. Les valeurs valides sont `unlocked` et `locked`. Une `unlocked` valeur indique que l’utilisateur peut modifier la stratégie en augmentant ou en diminuant la date de rétention jusqu’à. Une `locked` valeur indique que ces actions sont interdites.
`x-ms-legal-hold`	Version 2020-06-12 et ultérieures. Spécifie la conservation légale à définir sur l’objet blob. Les valeurs valides sont `true` et `false`.

Cette opération prend en charge les x-ms-if-tags en-têtes conditionnels et x-ms-source-if-tags pour réussir uniquement si la condition spécifiée est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de stockage Blob.

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

Dans les versions 2012-02-12 et ultérieures, une opération réussie retourne status code 202 (Accepté).

Dans les versions antérieures au 12/02/2012, une opération réussie retourne un code d'état 201 (Créée).

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.

En-tête de réponse	Description
`ETag`	Dans les versions 2012-02-12 et ultérieures, si la copie est terminée, cet en-tête contient la `ETag` valeur de l’objet blob de destination. Si la copie n’est pas terminée, l’en-tête contient la `ETag` valeur de l’objet blob vide créé au début de l’opération de copie. Dans les versions antérieures à 2012-02-12, cet en-tête retourne la `ETag` valeur de l’objet blob de destination. Dans les versions 2011-08-18 et ultérieures, la `ETag` valeur est entre guillemets.
`Last-Modified`	Retourne la date/heure de fin de l’opération de copie dans l’objet blob de destination.
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée. Vous pouvez utiliser cet en-tête pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
`x-ms-version`	Indique la version de Stockage Blob utilisée pour exécuter la requête. 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 le service a envoyé la réponse.
`x-ms-copy-id: <id>`	Version 2012-02-12 et versions ultérieures. Fournit un identificateur de chaîne pour cette opération de copie. Utilisez avec `Get Blob` ou `Get Blob Properties` pour case activée la status de cette opération de copie, ou passez à `Abort Copy Blob` pour annuler une opération de copie en attente.
`x-ms-copy-status: <success ¦ pending>`	Version 2012-02-12 et versions ultérieures. Indique l’état de l’opération de copie, avec les valeurs suivantes : - `success`: l’opération s’est terminée avec succès. - `pending`: l’opération est en cours.
`x-ms-version-id: <DateTime>`	Version 2019-12-12 et ultérieures. Identifie de manière unique l’objet blob par sa version. Vous pouvez utiliser cette valeur opaque dans les requêtes suivantes pour accéder à cette version de l’objet blob.
`x-ms-client-request-id`	Peut être utilisé pour résoudre les problèmes liés aux demandes et aux réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête `x-ms-client-request-id` , si elle est présente dans la requête et que 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, cet en-tête ne sera pas présent dans la réponse.

Response body

Aucun.

Exemple de réponse

Le code suivant est un exemple de réponse pour une demande de copie d’un objet blob :

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: pending
x-ms-version-id: <DateTime>  
Date: <date>

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Le tableau suivant décrit comment les objets de destination et source d’une Copy Blob opération peuvent être autorisés :

Type d’objet	autorisation Microsoft Entra ID	Autorisation signature d’accès partagé (SAP)	Autorisation de clé partagée (ou Clé partagée Lite)
Objet blob de destination	Oui	Oui	Oui
Objet blob source dans le même compte de stockage	Oui	Oui	Oui
Objet blob source dans un autre compte de stockage	Non	Oui	Non

Si une demande spécifie des balises dans l’en-tête de la x-ms-tags demande, l’appelant doit répondre aux exigences d’autorisation de l’opération Définir des balises blob .

Vous pouvez autoriser l’opération Copy Blob comme décrit ci-dessous. Notez qu’un objet blob source dans un autre compte de stockage doit être autorisé séparément via le jeton SAP avec l’autorisation Lecture (r). Pour plus d’informations sur l’autorisation d’objet blob source, consultez les détails de l’en-tête x-ms-copy-sourcede demande .

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érationCopy Blob, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Objet blob de destination

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (pour l’écriture dans un objet blob existant) ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (pour écrire un nouvel objet blob dans la destination)
Rôle intégré le moins privilégié :Contributeur aux données blob de stockage

Objet blob source dans le même compte de stockage

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Rôle intégré le moins privilégié :Lecteur de 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 Copy 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 Copy Blob d’un jeton SAP délégué à une ressource d’objet blob nécessite l’autorisation suivante dans le cadre du jeton SAP de délégation utilisateur.

Opération	Type d’objet	Autorisation signée
Copie d'un objet blob	Objet blob de destination (nouveau)	Créer (c) ou Écrire (w)
Copie d'un objet blob	Objet blob de destination (existant)	Écriture (w)
Copie d'un objet blob	Objet blob source (dans le même compte de stockage)	Lecture (r)
Copie d'un objet blob	Objet blob source (dans un compte de stockage différent)	Lecture (r)

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.

L’appel de l’opération à l’aide Copy Blob d’un jeton SAP délégué à une ressource d’objet blob nécessite l’autorisation suivante dans le cadre du jeton SAP de service.

Opération	Type d’objet	Autorisation signée
Copie d'un objet blob	Objet blob de destination (nouveau)	Créer (c) ou Écrire (w)
Copie d'un objet blob	Objet blob de destination (existant)	Écriture (w)
Copie d'un objet blob	Objet blob source (dans le même compte de stockage)	Lecture (r)
Copie d'un objet blob	Objet blob source (dans un compte de stockage différent)	Lecture (r)

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	Type d’objet	Service signé	Type de ressource signé	Autorisation signée
Copie d'un objet blob	Objet blob de destination (nouveau)	Objet blob (b)	Objet (o)	Créer (c) ou Écrire (w)
Copie d'un objet blob	Objet blob de destination (existant)	Blob (b)	Objet (o)	Écriture (w)
Copie d'un objet blob	Objet blob source (dans le même compte de stockage)	Blob (b)	Objet (o)	Lecture (r)
Copie d'un objet blob	Objet blob source (dans un compte de stockage différent)	Blob (b)	Objet (o)	Lecture (r)

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

L’opération Copy Blob prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée pour 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

Dans les versions 2012-02-12 et ultérieures, l’opération Copy Blob peut se terminer de manière asynchrone. Cette opération retourne un ID de copie que vous pouvez utiliser pour case activée ou annuler l’opération de copie. En raison de la nature asynchrone de l’opération de copie, le Stockage Blob copie les objets blob au mieux. Le service Blob copie les objets blob lorsque les ressources du serveur ne sont pas utilisées par d’autres tâches. Il n’est donc pas garanti qu’une copie démarre immédiatement ou se termine dans un laps de temps spécifié.

L’objet blob source d’une opération de copie peut être un objet blob de blocs, un objet blob d’ajout, un objet blob de pages ou un instantané. Si l’objet blob de destination existe déjà, il doit être du même type d’objet blob que l’objet blob source. Tout objet blob de destination existant sera remplacé. Vous ne pouvez pas modifier l’objet blob de destination tant qu’une opération de copie est en cours.

Dans les versions 2015-02-21 et ultérieures, la source de l’opération de copie peut également être un fichier dans Azure Files. Si la source est un fichier, la destination doit être un objet blob de blocs.

Plusieurs opérations Copy Blob en attente au sein d'un compte peuvent être traitées de façon séquentielle. Un objet blob de destination ne peut avoir qu’une seule opération en attente Copy Blob . En d’autres termes, un objet blob ne peut pas être la destination de plusieurs opérations en attente Copy Blob . Une tentative de copie d’un objet blob vers un objet blob de destination qui a déjà une opération de copie en attente échoue avec status code 409 (conflit).

Seuls les comptes de stockage créés à partir du 7 juin 2012 autorisent l’opération Copy Blob à copier à partir d’un autre compte de stockage. Une tentative de copie à partir d’un autre compte de stockage vers un compte créé avant le 7 juin 2012 échoue avec status code 400 (Demande incorrecte).

L’opération Copy Blob copie toujours l’intégralité du fichier ou de l’objet blob source. La copie d’une plage d’octets ou d’un ensemble de blocs n’est pas prise en charge.

Une opération Copy Blob peut prendre l'une des formes suivantes :

Vous pouvez copier un objet blob source dans un objet blob de destination dont le nom est différent. L’objet blob de destination peut être un objet blob existant du même type d’objet blob (bloc, ajout ou page), ou il peut s’agir d’un nouvel objet blob créé par l’opération de copie.
Vous pouvez copier un objet blob source dans un objet blob de destination portant le même nom, en remplaçant l’objet blob de destination. Une telle opération de copie supprime tous les blocs non valides et remplace les métadonnées de l'objet blob.
Vous pouvez copier un fichier source dans Azure Files dans un objet blob de destination. L’objet blob de destination peut être un objet blob de blocs existant ou un nouvel objet blob de blocs créé par l’opération de copie. La copie de fichiers vers des objets blob de pages ou d’ajout n’est pas prise en charge.
Vous pouvez copier un instantané sur son objet blob de base. En plaçant un instantané à la place d'un objet blob de base, vous pouvez restaurer une version antérieure de l’objet blob.
Vous pouvez copier un instantané dans un objet blob de destination dont le nom est différent. L’objet blob de destination obtenu est un objet blob modifiable et non pas un instantané.

Lorsque vous copiez à partir d’un objet blob de pages, le Stockage Blob crée un objet blob de pages de destination de la longueur de l’objet blob source. Initialement, l’objet blob de pages contient tous les zéros. Puis les plages de pages source sont énumérées, et des plages non vides sont copiées.

Pour un objet blob de blocs ou un objet blob d’ajout, le Stockage Blob crée un objet blob validé de longueur nulle avant de revenir à partir de cette opération.

Lorsque vous copiez à partir d’un objet blob de blocs, tous les blocs validés et leurs ID de bloc sont copiés. Les blocs non validés ne sont pas copiés. À la fin de l’opération de copie, l’objet blob de destination a le même nombre de blocs validés que la source.

Lorsque vous copiez à partir d’un objet blob d’ajout, tous les blocs validés sont copiés. À la fin de l’opération de copie, l’objet blob de destination aura moins ou le même nombre de blocs validés que l’objet blob source.

Pour tous les types d’objets blob, vous pouvez appeler Get Blob ou Get Blob Properties sur l’objet blob de destination pour case activée la status de l’opération de copie. L’objet blob final est validé à la fin de l’opération de copie.

Lorsque la source d’une opération de copie fournit des ETag valeurs, toute modification apportée à la source pendant que l’opération de copie est en cours entraîne l’échec de cette opération. Une tentative de modification de l’objet blob de destination alors qu’une copie est en cours échoue avec status code 409 (conflit). Si l'objet blob de destination a un bail infini, l'ID de bail doit être passé à Copy Blob. Les baux à durée fixe ne sont pas autorisés.

La ETag valeur d’un objet blob de blocs change au démarrage de l’opération Copy Blob et à la fin de l’opération. La ETag valeur d’un objet blob de pages change au démarrage de l’opération Copy Blob , et elle continue à changer fréquemment pendant l’opération de copie. Le contenu d’un objet blob de blocs n’est visible via une Get commande qu’une fois l’opération de copie complète terminée.

Copie des propriétés, des étiquettes et des métadonnées d’objet blob

Lorsqu’un objet blob est copié, les propriétés système suivantes sont copiées dans l’objet blob de destination qui a les mêmes valeurs :

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition
x-ms-blob-sequence-number (pour les objets blob de pages uniquement)
x-ms-committed-block-count (pour les objets blob d’ajout uniquement et pour la version 2015-02-21 uniquement)

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

L’objet blob de destination a toujours la même taille que l’objet blob source. La valeur de l’en-tête Content-Length de l’objet blob de destination correspond à la valeur de cet en-tête pour l’objet blob source.

Lorsque l'objet blob source et l'objet blob de destination sont identiques, Copy Blob supprime tous les blocs non validés. Si les métadonnées sont spécifiées dans ce cas, les métadonnées existantes sont remplacées par les nouvelles métadonnées.

Si l’en-tête x-ms-tags fournit des balises pour l’objet blob de destination, elles doivent être encodées sous forme de chaîne de requête. Les clés et les valeurs de balise doivent être conformes aux exigences de nommage et de longueur, comme spécifié dans Définir des balises d’objet blob.

L’en-tête x-ms-tags peut contenir jusqu’à 2 kilobits de balises. Si vous avez besoin d’autres balises, utilisez l’opération Set Blob Tags .

Si l’en-tête x-ms-tags ne fournit pas d’étiquettes, les balises ne sont pas copiées à partir de l’objet blob source.

Copie d’un objet blob loué

L’opération Copy Blob lit uniquement à partir de l’objet blob source, de sorte que l’état de bail de l’objet blob source n’a pas d’importance. Toutefois, l’opération Copy Blob enregistre la ETag valeur de l’objet blob source au démarrage de l’opération de copie. Si la ETag valeur change avant la fin de l’opération de copie, l’opération échoue. Vous pouvez éviter les modifications à l'objet blob source en le louant pendant l'opération de copie.

Si l'objet blob de destination a un bail infini actif, vous devez spécifier son ID de bail dans l'appel à l'opération Copy Blob. Si le bail que vous spécifiez est un bail actif à durée finie, cet appel échoue avec un status code 412 (échec de la condition préalable). Pendant que l’opération de copie est en attente, toute opération de bail sur l’objet blob de destination échoue avec status code 409 (Conflit). Un bail infini sur l’objet blob de destination est verrouillé de cette façon pendant l’opération de copie, que vous copiez vers un objet blob de destination dont le nom est différent de celui de la source, que vous copiez vers un objet blob de destination portant le même nom que la source ou que vous promouviez un instantané sur son objet blob de base.

Si le client spécifie un ID de bail sur un objet blob qui n’existe pas encore, le Stockage Blob retourne status code 412 (Échec de la condition préalable) pour les demandes effectuées sur les versions 2013-08-15 et ultérieures. Pour les versions antérieures, Stockage Blob retourne status code 201 (Créé).

Copie d’instantanés d’objets blob

Lorsqu’un objet blob source est copié, les instantanés ou versions de l’objet blob source ne sont pas copiés vers la destination. Lorsqu’un objet blob de destination est remplacé par une copie, les instantanés ou versions associés à l’objet blob de destination restent intacts sous son nom.

Vous pouvez effectuer une opération de copie pour promouvoir un instantané sur son objet blob de base, tant qu’il se trouve dans un niveau en ligne (chaud ou froid). De cette façon, vous pouvez restaurer une version antérieure d’un objet blob. L'instantané est conservé, mais sa destination est remplacée par une copie qui peut être lue et modifiée.

Copie des versions d’objets blob

Vous pouvez effectuer une opération de copie pour promouvoir une version sur son objet blob de base, à condition qu’elle se trouve dans un niveau en ligne (chaud ou froid). De cette façon, vous pouvez restaurer une version antérieure d’un objet blob. La version reste, mais sa destination est remplacée par une copie qui peut être à la fois lue et écrite.

Copie d’un objet blob archivé

À compter de la version 2018-11-09, vous pouvez copier un objet blob archivé vers un nouvel objet blob au sein du même compte de stockage. L’objet blob source reste dans le niveau archive. Lorsque l’objet blob source est un objet blob archivé, la demande doit contenir l’en-tête x-ms-access-tier , qui indique le niveau de l’objet blob de destination. L’objet blob de destination doit se trouver dans un niveau en ligne. Vous ne pouvez pas copier vers un objet blob dans le niveau archive.

À compter de la version 2021-02-12, vous pouvez copier un objet blob archivé vers un niveau en ligne dans un autre compte de stockage, à condition que le compte de destination se trouve dans la même région que le compte source.

La requête peut échouer si l’objet blob source est réhydraté.

Pour plus d’informations sur la hiérarchisation au niveau de l’objet blob de blocs, consultez Niveaux de stockage chaud, froid et archive.

Utilisation d’une opération de copie en attente (version 2012-02-12 et ultérieure)

Si l’opération Copy Blob se termine de manière asynchrone, utilisez le tableau suivant pour déterminer l’étape suivante en fonction du code status retourné :

Code d’état	Signification
202 (Acceptée), x-ms-copy-status: succès	L’opération de copie s’est terminée avec succès.
202 (Acceptée), x-ms-copy-status: en attente	L’opération de copie n’est pas terminée. Interrogez l’objet blob de destination à l’aide `Get Blob Properties` de pour examiner l’en-tête `x-ms-copy-status` jusqu’à ce que l’opération se termine ou échoue.
4xx, 500 ou 503	Échec de l’opération de copie.

Pendant et après une opération Copy Blob, les propriétés de l'objet blob de destination contiennent l'ID de copie de l'opération Copy Blob et l'URL de l'objet blob source. Une fois l’opération terminée, Stockage Blob écrit la valeur d’heure et de résultat (success, failedou aborted) dans les propriétés de l’objet blob de destination. Si l’opération a un failed résultat, l’en-tête x-ms-copy-status-description contient une chaîne de détails d’erreur.

Une opération en attente Copy Blob a un délai d’attente de deux semaines. Une tentative de copie qui n’est pas terminée au bout de deux semaines expire et laisse un objet blob vide avec le x-ms-copy-status champ défini failed sur et la x-ms-copy-status-description valeur 500 (OperationCancelled). Les erreurs intermittentes et non irrécupérables qui peuvent se produire pendant une opération de copie peuvent entraver la progression de l’opération, mais pas provoquer son échec. Dans ces cas, x-ms-copy-status-description décrit les erreurs intermittentes.

Toute tentative de modification ou de instantané l’objet blob de destination pendant l’opération de copie échoue avec status code 409 (Conflit), « Copier l’objet blob en cours ».

Si vous appelez l’opération Abort Copy Blob , un en-tête s’affiche x-ms-copy-status:aborted . L’objet blob de destination aura des métadonnées intactes et une longueur d’objet blob de 0 octet. Vous pouvez répéter l’appel d’origine à pour Copy Blob réessayer l’opération de copie.

Si l’opération Copy Blob se termine de manière synchrone, utilisez le tableau suivant pour déterminer la status de l’opération de copie :

Code d’état	Signification
202 (Acceptée), x-ms-copy-status: succès	L’opération de copie s’est terminée avec succès.
4xx, 500 ou 503	Échec de l’opération de copie.

Le niveau est hérité pour les niveaux de stockage Premium. Pour les objets blob de blocs, le remplacement de l’objet blob de destination héritera du niveau chaud ou froid de la destination si x-ms-access-tier ce n’est pas fourni. Le remplacement d’un objet blob archivé échoue. Pour plus d’informations sur la hiérarchisation au niveau de l’objet blob de blocs, consultez Niveaux de stockage chaud, froid et archive.

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 Copy Blob les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Copier un objet blob (compte^{de destination 1})	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Opérations d’écriture
Copier un objet blob (compte source²)	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Lire les opérations

¹Le compte de destination est facturé pour une transaction pour lancer l’écriture.
²Lorsque l’objet source se trouve dans un autre compte, le compte source entraîne une transaction pour chaque demande de lecture à l’objet source.

Pour en savoir plus sur la tarification pour les catégories de facturation spécifiées, consultez Stockage Blob Azure Tarification.

Le compte de destination entraîne également des coûts de transaction pour chaque demande d’annulation de l’opération de copie (voir Annuler l’objet blob de copie) ou pour case activée la status de l’opération de copie (voir Obtenir des propriétés d’objet blob ou d’obtenir des objets blob).

En outre, si les comptes source et de destination résident dans différentes régions (par exemple, USA Nord et USA Sud), la bande passante que vous utilisez pour transférer la demande est facturée au compte de stockage source en sortie. Les sorties entre les comptes au sein de la même région sont gratuits.

Lorsque vous copiez un objet blob source vers un objet blob de destination portant un nom différent dans le même compte, vous utilisez des ressources de stockage supplémentaires pour le nouvel objet blob. L’opération de copie entraîne ensuite des frais sur l’utilisation de la capacité du compte de stockage pour ces ressources supplémentaires. Toutefois, si les noms des objets blob source et de destination sont identiques dans le même compte (par exemple, lorsque vous faites la promotion d’un instantané dans son objet blob de base), aucun frais supplémentaire n’est facturé, à part les métadonnées de copie supplémentaires stockées dans la version 2012-02-12 et ultérieure.

Lorsque vous promouvez un instantané pour remplacer son objet blob de base, l'objet blob instantané et de base deviennent identiques. Ils partagent les blocs ou les pages, c'est pourquoi l'opération de copie n'entraîne pas de frais supplémentaires de l'utilisation de la capacité du compte de stockage. Toutefois, si vous copiez un instantané dans un objet blob de destination qui a un nom différent, cette opération entraîne des frais supplémentaires pour les ressources de stockage utilisées par le nouvel objet blob résultant. Deux objets blob qui ont des noms différents ne peuvent pas partager de blocs ou de pages, même s’ils sont identiques. Pour plus d’informations sur les scénarios de coût instantané, consultez Présentation de la façon dont les instantanés cumulent les frais.

Voir aussi

Autoriser les demandes à Stockage Azure
Codes d’état et d’erreur
Codes d’erreur Stockage Blob
Présentation de la façon dont les instantanés cumulent des frais
Abort Copy Blob