Copie d'un objet blob
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 demande 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, suivi du nom du compte de stockage émulé :
| URI de demande 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 Nommer et référencer des conteneurs, des objets blob et des métadonnées. |
x-ms-tags |
facultatif. Définit les balises encodées par la 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 les versions 2019-12-12 et ultérieures. |
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é, 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é, 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, 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, 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é, 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é, 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 pour 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, 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 pour 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, 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?sastokenDans 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, Coolet 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 .
Important
Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes à Stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.
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, une identité managée 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.
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, Stockage Blob copie les objets blob au mieux. Le service Blob copie les objets blob lorsque les ressources 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 délai spécifié.
L’objet blob source d’une opération de copie peut être un objet blob de bloc, un objet blob d’ajout, un objet blob de page 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 pendant 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 (requête incorrecte).
L’opération Copy Blob copie toujours l’intégralité de l’objet blob ou du fichier 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 qui a un autre nom. 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 efficacement 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 qui a un autre nom. 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, Stockage Blob crée un objet blob de page de destination de la longueur de l’objet blob source. Initialement, l’objet blob de page 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 bloc ou un objet blob d’ajout, 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 blocs 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 le 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 page change lorsque l’opération Copy Blob démarre, et elle continue de 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 de propriétés, d’étiquettes et de métadonnées d’objets 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-TypeContent-EncodingContent-LanguageContent-LengthCache-ControlContent-MD5Content-Dispositionx-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 pour 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 par 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 les balises d’objets 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 limitée, cet appel échoue avec un code status 412 (Échec de la condition préalable). Lorsque 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 manière pendant l’opération de copie, que vous copiez sur 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 ayez promu 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, 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 de captures instantanées d’objets blob
Lorsqu’un objet blob source est copié, les captures instantanées ou versions de l’objet blob source ne sont pas copiées dans la destination. Lorsqu’un objet blob de destination est remplacé par une copie, les captures instantanées ou versions associées à l’objet blob de destination restent intactes 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 (comptede 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 source2) | Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard |
Lire les opérations |
1Le compte de destination est facturé pour une transaction pour lancer l’écriture.
2Lorsque 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