Exporter (0) Imprimer
Développer tout

Copy Blob

Mis à jour: novembre 2013

L'opération Copy Blob copie un objet blob vers une destination au sein du compte de stockage. À partir de la version du 12/02/2012, la source pour une opération Copy Blob peut être un objet blob validé dans un compte de stockage Azure.

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

La demande Copy Blob peut être construite comme indiqué ci-dessous. HTTPS est recommandé. Remplacez moncompte 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. À partir de la version du 15/08/2013, vous pouvez spécifier une signature d'accès partagé pour l'objet blob de destination.

 

  URI de demande de la méthode PUT Version HTTP

https://myaccount.blob.core.windows.net/mycontainer/myblob

HTTP/1.1

Lorsque vous élaborez une demande pour le service de stockage émulé, spécifiez le nom d'hôte de l'émulateur et le port de service BLOB sous la forme 127.0.0.1:10000, suivi du nom de compte de stockage émulé :

 

  URI de demande de la méthode PUT Version HTTP

http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob

HTTP/1.1

Pour plus d'informations, consultez Utilisation de l'émulateur de stockage Azure pour le développement et le test.

Les paramètres supplémentaires suivants peuvent être spécifiés dans l'URI de la demande.

 

Parameter Description

timeout

Ce paramètre est facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d'informations, consultez Définition de délais d'expiration pour les opérations du service BLOB.

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

 

En-tête de demande Description

Authorization

Obligatoire. Spécifie le schéma d'authentification, le nom du compte et la signature. Pour plus d'informations, consultez Authentification pour les services de stockage Azure.

Date - ou - x-ms-date

Obligatoire. Spécifie le temps universel coordonné (UTC) pour la demande. Pour plus d'informations, consultez Authentification pour les services de stockage Azure.

x-ms-version

Obligatoire pour toutes les demandes authentifiées. Pour plus d'informations, consultez Contrôle de version pour les services de stockage Azure.

x-ms-meta-name:value

Ce paramètre est 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 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 source.

Depuis la version du 19/09/2009, les noms de métadonnées doivent respecter les règles d'attribution de noms pour les identificateurs C#. Pour plus d'informations, consultez Affectation de noms et références aux conteneurs, objets BLOB et métadonnées.

x-ms-source-if-modified-since

Ce paramètre est 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 service BLOB retourne le code d'état 412 (Échec de la précondition).

x-ms-source-if-unmodified-since

Ce paramètre est 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 service BLOB retourne le code d'état 412 (Échec de la précondition).

x-ms-source-if-match

Ce paramètre est facultatif. Valeur d'ETag. Spécifiez cet en-tête conditionnel pour copier l'objet blob source uniquement si son ETag correspond à la valeur spécifiée. Si les valeurs d'ETag ne correspondent pas, le service BLOB retourne le code d'état 412 (Échec de la précondition).

x-ms-source-if-none-match

Ce paramètre est facultatif. Valeur d'ETag. Spécifiez cet en-tête conditionnel pour copier l'objet blob source uniquement si son ETag ne correspond pas à la valeur spécifiée. Si les valeurs sont identiques, le service BLOB retourne le code d'état 412 (Échec de la précondition).

If-Modified-Since

Ce paramètre est 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 service BLOB retourne le code d'état 412 (Échec de la précondition).

If-Unmodified-Since

Ce paramètre est 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 service BLOB retourne le code d'état 412 (Échec de la précondition).

If-Match

Ce paramètre est facultatif. Valeur d'ETag. Spécifiez une valeur d'ETag pour cet en-tête conditionnel pour copier l'objet blob uniquement si la valeur d'ETag spécifiée correspond à la valeur ETag pour un objet blob de destination existant. Si l'ETag pour l'objet blob de destination ne correspond pas à l'ETag spécifié pour If-Match, le service BLOB retourne le code d'état 412 (Échec de la précondition).

If-None-Match

Ce paramètre est facultatif. Une valeur d'ETag ou le caractère générique (*).

Spécifiez une valeur d'ETag pour cet en-tête conditionnel pour copier l'objet blob uniquement si la valeur d'ETag spécifiée ne correspond pas à la valeur d'ETag pour l'objet blob de destination.

Spécifiez le caractère générique (*) pour exécuter l'opération uniquement si l'objet blob de destination n'existe pas.

Si la condition spécifiée n'est pas remplie, le service BLOB retourne le code d'état 412 (Échec de la précondition).

x-ms-copy-source:name

Obligatoire. Spécifie le nom de l'objet blob source.

À partir de la version du 12/02/2012, cette valeur est une URL d'une longueur pouvant aller jusqu'à 2 Ko qui spécifie un objet blob. Un objet blob source dans le même compte peut être privé, mais un objet blob dans un autre compte doit être public ou accepter les informations d'identification incluses dans cette URL, telles qu'une signature d'accès partagé. Seuls les comptes de stockage créés à partir du 7 juin 2012 autorisent l'opération Copy Blob pour copier à partir d'un autre compte de stockage. Microsoft recommande d'utiliser HTTPS si possible. Exemples :

  • https://myaccount.blob.core.windows.net/mycontainer/myblob

  • https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>

Dans les versions antérieures au 12/02/2012, les objets blob ne peuvent être copiés que dans le même compte, et un nom de source peut utiliser les formats suivants :

  • Objet blob dans un conteneur nommé : /accountName/containerName/blobName

  • Instantané dans un conteneur nommé : /accountName/containerName/blobName?snapshot=<DateTime>

  • Objet blob dans un conteneur racine : /accountName/blobName

  • Instantané dans un 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 elle n'est pas valide, l'opération échoue avec un code d'état 412 (Échec de la précondition).

Si cet en-tête est spécifié et que l'objet blob de destination n'a pas actuellement un bail actif, l'opération échouera également avec un code d'état 412 (Échec de la précondition).

À partir de la version du 12/02/2012, cette valeur doit spécifier un bail actif et infini pour un objet blob loué. Un ID de bail d'une durée fixe échoue avec 412 (Échec de la précondition).

x-ms-source-lease-id: <ID>

Facultatif, versions antérieures au 12/02/2012 (non pris en charge à partir des versions du 12/02/2012). Spécifiez cet en-tête pour exécuter l'opération Copy Blob uniquement si l'ID de bail donné 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 actuellement un bail actif, l'opération échouera également avec un code d'état 412 (Échec de la précondition).

x-ms-client-request-id

Ce paramètre est facultatif. Fournit une valeur opaque générée par le client avec une limite de caractère de 1 Ko qui est enregistrée dans les journaux d'analyse quand la journalisation de l'analyse de stockage est activée. L'utilisation de cet en-tête est recommandée pour la corrélation des activités côté client avec les requêtes reçues par le serveur. Pour plus d'informations, consultez À propos de la journalisation Storage Analytics et Journalisation du stockage Windows Azure : utilisation des journaux pour suivre les demandes de stockage.

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

À partir de la version du 12/02/2012, une opération réussie retourne un code d'état 202 (Acceptée).

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 d'état, consultez Codes d'état et codes d'erreur.

La réponse de l'opération inclut les en-têtes suivants. La réponse peut aussi 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

À partir de la version du 12/02/2012, si la copie est terminée, contient l'ETag de l'objet blob de destination. Si la copie n'est pas terminée, contient l'ETag de l'objet blob vide créé au début de la copie.

Dans les versions antérieures au 12/02/2012, retourne l'ETag pour l'objet blob de destination.

À partir de la version du 18/08/2011, la valeur de l'ETag sera entre guillemets.

Last-Modified

Retourne le date/heure auxquelles l'opération de copie vers l'objet blob de destination s'est terminée.

x-ms-request-id

Cet en-tête identifie de façon unique la demande qui a été effectuée et peut être utilisé pour résoudre les problèmes de la demande. Pour plus d'informations, consultez Dépannage des opérations de l'API.

x-ms-version

Indique la version du service BLOB utilisée pour exécuter la demande. Cet en-tête est retourné pour les demandes effectuées avec la version du 19.09.09 ou ultérieure.

Date

Une valeur de date/heure UTC générée par le service qui indique le moment auquel la réponse a été initiée.

x-ms-copy-id: <id>

Version du 12/02/2012 et ultérieure. Identificateur de chaîne pour cette opération de copie. À utiliser avec Get Blob ou Get Blob Properties pour vérifier l'état de cette opération de copie ou passer à Abort Copy Blob pour annuler une copie en attente.

x-ms-copy-status: <success | pending>

Version du 12/02/2012 et ultérieure. État de l'opération de copie, avec ces valeurs :

  • success : la copie s'est terminée correctement.

  • pending : la copie est en cours.

Voici 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: Thu, 09 Feb 2012 23:30:19 GMT 
ETag: "0x8CEB669D794AFE2"
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402
x-ms-version: 2012-02-12
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5
x-ms-copy-status: pending
Date: Thu, 09 Feb 2012 23:30:18 GMT

Cette opération peut être appelée par le propriétaire du compte. Pour les demandes effectuées dans la version du 15/08/2013 et les versions ultérieures, une signature d'accès partagé qui a l'autorisation d'écrire dans l'objet blob de destination ou son conteneur est prise en charge pour les opérations de copie dans le même compte. Notez que la signature d'accès partagé spécifiée dans la demande s'applique uniquement à l'objet blob de destination. L'accès à l'objet blob source est autorisé séparément, tel que l'indique les informations d'en-tête de demande x-ms-copy-source.

À partir de la version du 12/02/2012, l'opération Copy Blob peut être exécutée de façon asynchrone. Cette opération retourne un ID de copie que vous pouvez utiliser pour vérifier ou annuler l'opération de copie. Le service BLOB copie sur une base du meilleur effort.

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

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 opération de copie d'objet blob en attente. En d'autres termes, un objet blob ne peut pas être la destination de plusieurs opérations Copy Blob en attente. Une tentative de Copy Blob vers un objet blob de destination qui a déjà une copie en attente échoue avec le code d'état 409 (Conflit).

Seuls les comptes de stockage créés à partir du 7 juin 2012 autorisent l'opération Copy Blob pour 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 le code d'état 400 (Demande incorrecte).

L'opération Copy Blob copie toujours l'intégralité 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 vers un objet blob de destination avec un nom différent. L'objet blob de destination peut être un objet blob existant du même type d'objet blob (blocs ou pages), ou peut être un nouvel objet blob créé par l'opération de copie.

  • Vous pouvez copier un objet blob source vers un objet blob de destination avec le même nom, ce qui remplace l'objet blob source. 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 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é sur un objet BLOB de destination avec un nom différent. L'objet BLOB de destination qui en découle est modifiable et n'est pas un instantané.

En copiant à partir d'un objet blob de pages, le service BLOB crée un objet blob de pages de destination de la longueur de l'objet blob source, qui contient au début tous les zéros. Puis les plages de pages source sont énumérées, et des plages non vides sont copiées. Lors de la copie à partir d'un objet blob de blocs, tous les blocs validés et leurs ID de bloc seront copiés. Les blocs non validés ne seront pas copiés. Pour un objet blob de blocs, le service BLOB crée un objet blob validé d'une longueur nulle avant de retourner une valeur à partir de cette opération. Quel que soit le type de l'objet blob, vous pouvez appeler Get Blob ou Get Blob Properties sur l'objet blob de destination pour vérifier l'état de l'opération de copie. L'objet blob final sera validé à la fin de la copie.

Lorsque la source d'une opération de copie fournit des ETag, si des modifications sont apportées à la source pendant que la copie, la copie échoue. Une tentative de modification de l'objet blob de destination pendant une copie échoue avec un 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.

L'ETag pour un objet blob de blocs change lorsque l'opération Copy Blob est initiée et lorsque la copie est terminée. L'ETag pour un objet blob de pages change lorsque l'opération Copy Blob est initiée et continue de changer pendant la copie. Le contenu d'un objet blob de blocs est visible uniquement en utilisant un GET après la fin de la copie.

Copie des propriétés et des métadonnées d'un objet blob

Quand un objet blob est copié, les propriétés système suivantes sont copiées vers l'objet blob de destination avec les mêmes valeurs :

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (for page blobs only)

La liste des blocs validés de l'objet blob source est également copiée vers 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 est toujours de la même taille que l'objet blob source, c'est pourquoi la valeur de l'en-tête Content-Length pour l'objet blob de destination correspond à celle de 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.

Copie d'un objet blob loué

L'opération Copy Blob lit uniquement à partir de l'objet blob source c'est pourquoi l'état du bail de l'objet blob source n'a pas d'importance. Toutefois, l'opération Copy Blob enregistre l'ETag de l'objet blob source quand la copie débute. Si la valeur de l'ETag change avant la fin de la copie, la copie é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 à durée fixe actif, cet appel échoue avec le code d'état 412 (Échec de la précondition). Pendant que la copie est en attente, une opération de location sur l'objet blob de destination échouera avec le code d'état 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 vers un objet blob de destination avec un nom différent de la source, que vous copiez vers un objet blob de destination avec le même nom que la source ou que vous promouviez un instantané par rapport à son objet blob de base. Si le client spécifie un ID de bail sur un objet blob qui n'existe pas encore, le service BLOB retourne le code d'état 412 (Échec de la précondition) pour les requêtes effectuées avec la version du 15/08/2013 et les versions ultérieures ; pour les versions antérieures, le service BLOB retourne le code d'état 201 (Créé).

Copie d'instantanés

Quand un objet BLOB source est copié, les instantanés de l'objet BLOB source ne sont pas copiés dans la 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 exécuter une opération de copie pour promouvoir un objet blob instantané par rapport à son objet blob de base. 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.

Utilisation d'une copie en attente (version du 12/02/2012 et ultérieures)

L'opération Copy Blob termine la copie de façon asynchrone. Utilisez le tableau suivant pour déterminer l'étape suivante en fonction du code d'état retourné par Copy Blob :

 

Code d'état Signification

202 (Acceptée), x-ms-copy-status: réussite

La copie s'est terminée correctement.

202 (Acceptée), x-ms-copy-status: en attente

500 ou 503

La copie ne s'est pas terminée. Interrogez l'objet blob de destination en utilisant Get Blob Properties pour examiner le x-ms-copy-status jusqu'à ce que la copie soit terminée ou qu'elle échoue.

4xx, 500 ou 503

Échec de la 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. Lorsque la copie est terminée, le service BLOB écrit l'heure et la valeur de résultats (success, failed, ou aborted) dans les propriétés de l'objet blob de destination. Si l'opération failed, l'en-tête x-ms-copy-status-description contient une chaîne de détail d'erreur.

Une opération Copy Blob en attente a un délai de 2 semaines. Une tentative de copie qui ne s'est pas terminée après 2 semaines dépasse le délai et laisse un objet blob vide avec le champ x-ms-copy-status défini à failed et x-ms-copy-status-description défini à 500 (OperationCancelled). Des erreurs intermittentes et récupérables qui peuvent se produire lors d'une copie peuvent empêcher la progression de la copie mais n'entraînent pas son échec. Dans ces cas, x-ms-copy-status-description décrit les erreurs intermittentes.

Toute tentative de modification ou d'instantané de l'objet blob de destination pendant la copie échoue avec Copie d'objet blob en cours 409 (Conflit).

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

Facturation

Le compte de destination d'une opération Copy Blob est facturé pour une transaction pour lancer la copie, et une transaction est également décomptée pour chaque demande d'annulation ou d'interrogation de l'état de l'opération de copie.

Lorsque l'objet blob source est dans un autre compte, le compte de source subit des frais de transaction. De plus, si les comptes source et de destination résident dans différentes régions (par exemple, Nord des États-Unis et Sud des États-Unis), la bande passante utilisée pour transférer la demande est facturée au compte de stockage source sous forme de sorties. 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 avec un nom différent au sein du même compte, vous utilisez des ressources de stockage supplémentaires pour le nouvel objet blob, l'opération de copie entraîne des frais d'utilisation de la capacité du compte de stockage pour ces ressources supplémentaires. Toutefois, si le nom d'objet blob source et de destination sont les mêmes au sein du même compte (par exemple, lorsque vous promouvez un instantané en objet blob de base), cela n'entraîne aucun frais supplémentaire en dehors des métadonnées de copie supplémentaires stockées dans la version du 12/02/2012 ou 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é vers un objet blob de destination avec un nom différent, des frais supplémentaires se produisent pour les ressources de stockage utilisées par le nouvel objet blob qui en résulte. Deux objets blob avec des noms différents ne peuvent pas partager des blocs ou des pages même s'ils sont identiques. Pour plus d'informations sur les scénarios de coûts d'instantané, consultez Comprendre comment les instantanés contribuent à l'augmentation des coûts.

Afficher:
© 2014 Microsoft