Copia de blobs

Artículo
08/29/2021
Tiempo de lectura: 25 minutos

La operación Copy Blob copia un blob en un destino en la cuenta de almacenamiento.

En la versión 2012-02-12 y posteriores, el origen de una operación copy blob puede ser un blob confirmado en cualquier cuenta de Almacenamiento de Azure.

A partir de la versión 2015-02-21, el origen de una operación puede ser un archivo de Copy Blob Azure en cualquier cuenta de Azure Storage.

Nota

Las cuentas de almacenamiento creadas desde el 7 de junio de 2012 son las únicas que permiten que la operación Copy Blob copie desde otra cuenta de almacenamiento.

Solicitud

La solicitud Copy Blob se puede construir como sigue. Se recomienda HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento, mycontainer por el nombre del contenedor y myblob por el nombre del blob de destino.

A partir de la versión 2013-08-15, puede especificar una firma de acceso compartido para el blob de destino si se encuentra en la misma cuenta que el blob de origen. A partir de la versión 2015-04-05, también puede especificar una firma de acceso compartido para el blob de destino si se encuentra en una cuenta de almacenamiento diferente.

URI de solicitud del método PUT	Versión HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob`	HTTP/1.1

URI del servicio de almacenamiento emulado

Al realizar una solicitud en el servicio de almacenamiento emulado, especifique el nombre de host del emulador y el puerto del servicio Blob como 127.0.0.1:10000, seguido del nombre de la cuenta de almacenamiento emulado:

URI de solicitud del método PUT	Versión HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

Para obtener más información, vea Using the Azure Storage Emulator for Development and Testing.

Parámetros de URI

Se pueden especificar los parámetros adicionales siguientes en el URI de solicitud.

Parámetro	Descripción
`timeout`	Opcional. El parámetro `timeout` se expresa en segundos. Para obtener más información, vea Establecer tiempos de espera para las operaciones de Blob Service.

Encabezados de solicitud

En la tabla siguiente se describen los encabezados de solicitud requeridos y opcionales.

Encabezado de solicitud	Descripción
`Authorization`	Obligatorio. Especifica el esquema de autorización, el nombre de cuenta y la firma. Para obtener más información, vea Authorize requests to Azure Storage.
`Date` o `x-ms-date`	Obligatorio. Especifica la hora universal coordinada (UTC) de la solicitud. Para obtener más información, vea Authorize requests to Azure Storage.
`x-ms-version`	Se requiere para todas las solicitudes autorizadas. Para obtener más información, vea Control de versiones de Azure Storage Services.
`x-ms-meta-name:value`	Opcional. Especifica un par nombre-valor definido por el usuario asociado al blob. Si no se especifica ningún par nombre-valor, la operación copiará los metadatos del blob o archivo de origen al blob de destino. Si se especifican uno o varios pares nombre-valor, el blob de destino se crea con los metadatos especificados y los metadatos no se copian del blob o archivo de origen. Tenga en cuenta que, a partir de la versión 2009-09-19, los nombres de metadatos deben cumplir las reglas de nomenclatura para los identificadores de C#. Consulte Asignación de nombres y referencia a contenedores, blobs y metadatos para obtener más información.
`x-ms-tags`	Opcional. Establece las etiquetas codificadas de cadena de consulta especificadas en el blob. Las etiquetas no se copian del origen de copia. Consulte comentarios para obtener información adicional. Compatible con la versión 2019-12-12 y versiones más recientes.
`x-ms-source-if-modified-since`	Opcional. Valor `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de origen se ha modificado desde la fecha u hora especificadas. Si el blob de origen no se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa). Este encabezado no se puede especificar si el origen es un archivo de Azure.
`x-ms-source-if-unmodified-since`	Opcional. Valor `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de origen no se ha modificado desde la fecha u hora especificadas. Si el blob de origen se ha modificado, Blob service devuelve el código de estado 412 (Error de condición previa). Este encabezado no se puede especificar si el origen es un archivo de Azure.
`x-ms-source-if-match`	Opcional. Valor ETag. Especifique este encabezado condicional para copiar el blob de origen solo si la ETag coincide con el valor especificado. Si los valores de la ETag no coinciden, el servicio Blob devuelve el código de estado 412 (Error de condición previa). Este encabezado no se puede especificar si el origen es un archivo de Azure.
`x-ms-source-if-none-match`	Opcional. Valor ETag. Especifique este encabezado condicional para copiar el blob de origen solo si la ETag no coincide con el valor especificado. Si los valores son idénticos, Blob service devuelve el código de estado 412 (Error de condición previa). Este encabezado no se puede especificar si el origen es un archivo de Azure.
`If-Modified-Since`	Opcional. Valor `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de destino se ha modificado desde la fecha u hora especificadas. Si el blob de destino no se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa).
`If-Unmodified-Since`	Opcional. Valor `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de destino no se ha modificado desde la fecha u hora especificadas. Si el blob de destino se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa).
`If-Match`	Opcional. Valor ETag. Especifique un valor ETag para este encabezado condicional para copiar el blob solo si el valor ETag especificado coincide con el valor `ETag` para un blob de destino existente. Si la ETag del blob de destino no coincide con la ETag especificada para `If-Match`, Blob service devuelve el código de estado 412 (Error de condición previa).
`If-None-Match`	Opcional. Valor ETag o el carácter comodín (). Especifique un valor ETag para este encabezado condicional para copiar el blob solo si el valor ETag especificado no coincide con el del blob de destino. Especifique el carácter comodín ( ) para realizar la operación solo si el blob de destino no existe. Si no se cumple la condición especificada, Blob service devuelve el código de estado 412 (Error de condición previa).
`x-ms-copy-source:name`	Obligatorio. Especifica el nombre del blob o archivo de origen. A partir de la versión 2012-02-12, este valor puede ser una dirección URL de hasta 2 KiB de longitud que especifique un blob. El valor debe estar codificado para URL tal y como aparecería en un URI de solicitud. Un blob de origen en la misma cuenta de almacenamiento se puede autorizar mediante clave compartida. Sin embargo, si el origen es un blob de otra cuenta, el blob de origen debe ser público o debe estar autorizado a través de una firma de acceso compartido. Si el blob de origen es público, no se requiere ninguna autorización para realizar la operación de copia. A partir de la versión 2015-02-21, el objeto de origen puede ser un archivo en el servicio Azure File. Si el objeto de origen es un archivo que se va a copiar en un blob, el archivo de origen debe estar autorizado mediante una firma de acceso compartido, tanto si reside en la misma cuenta como en otra cuenta. Las cuentas de almacenamiento creadas desde el 7 de junio de 2012 son las únicas que permiten que la operación `Copy Blob` copie desde otra cuenta de almacenamiento. Estos son algunos ejemplos de direcciones URL de objeto de origen: - `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>` Cuando el objeto de origen es un archivo en el servicio Azure File, la dirección URL de origen usa el formato siguiente: Tenga en cuenta que la dirección URL debe incluir un token de SAS válido para el archivo: - `https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken` En las versiones anteriores a 2012-02-12, los blobs solo se pueden copiar en la misma cuenta, y un nombre de origen puede utilizar estos formatos: - Blob en un contenedor con nombre: `/accountName/containerName/blobName` - Instantánea en un contenedor con nombre: `/accountName/containerName/blobName?snapshot=<DateTime>` - Blob en el contenedor raíz: `/accountName/blobName` - Instantánea en el contenedor raíz: `/accountName/blobName?snapshot=<DateTime>`
`x-ms-lease-id:<ID>`	Obligatorio si el blob de destino tiene una concesión activa. El identificador de concesión especificado para este encabezado debe coincidir con el identificador de concesión del blob de destino. Si la solicitud no incluye el identificador de concesión o este no es válido, la operación produce un error con el código de estado 412 (Error de condición previa). Si se especifica este encabezado y el blob de destino no tiene actualmente una concesión activa, la operación también producirá un error con el código de estado 412 (Error de condición previa). En la versión 2012-02-12 y versiones más recientes, este valor debe especificar una concesión activa e infinita para un blob en concesión. Un identificador de concesión de duración finita produce un error con el código de estado 412 (Error de condición previa).
`x-ms-source-lease-id: <ID>`	Opcional, versiones anteriores a 2012-02-12 (no admitido en la versión 2012-02-12 y versiones más recientes). Especifique este encabezado para realizar la operación `Copy Blob` solo si el identificador de concesión proporcionado coincide con el identificador de concesión activa del blob de origen. Si se especifica este encabezado y el blob de origen no tiene actualmente una concesión activa, la operación también producirá un error con el código de estado 412 (Error de condición previa).
`x-ms-client-request-id`	Opcional. Proporciona un valor opaco generado por el cliente con un límite de caracteres de 1 KiB que se registra en los registros de análisis cuando se habilita el registro de análisis de almacenamiento. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes recibidas por el servidor. Para más información, consulte About Storage Analytics Logging and Azure Logging: Using Logs to Track Storage Requests.
`x-ms-access-tier`	Opcional. Especifica el nivel que se va a establecer en el blob de destino. Para blobs en páginas en una cuenta Premium solo con la versión 2017-04-17 y versiones más recientes. Para obtener una lista completa de los niveles Premium Storage y managed disks para las máquinas virtuales, consulte High-performance Premium Storage managed disks for VMs (Discos administrados y administrados de alto rendimiento para las máquinas virtuales). Versión 2018-11-09 y posteriores para blobs en bloques. Los niveles de blobs en bloques se admiten en las cuentas de Blob Storage o de uso general v2; los valores válidos son `Hot` / `Cool` / `Archive` . Para obtener información detallada sobre los niveles de blobs en bloques, consulte Niveles de almacenamiento de acceso es decir,acceso es cool y de archivo.
`x-ms-rehydrate-priority`	Opcional. Indica la prioridad con la que rehidratar un blob archivado. Compatible con la versión 2019-02-02 y versiones más recientes para blobs en bloques. Los valores válidos son `High` / `Standard` . La prioridad se puede establecer en un blob solo una vez. Este encabezado se omitirá en las solicitudes posteriores al mismo blob. La prioridad predeterminada sin este encabezado es `Standard` .
`x-ms-seal-blob`	Opcional. Compatible con la versión 2019-12-12 o posterior. Válido solo para blobs en anexos. Se sellará el blob de destino una vez finalizada la operación de copia.
`x-ms-immutability-policy-until-date`	Versión 2020-06-12 y versiones más recientes. Especifica la fecha de "retención hasta" que se va a establecer en el blob. Esta es la fecha hasta la que se puede proteger el blob para que no se modifique o elimine. Sigue el formato RFC1123.
`x-ms-immutability-policy-mode`	Versión 2020-06-12 y versiones más recientes. Especifica el modo de directiva de inmutabilidad que se va a establecer en el blob. Los valores válidos son `unlocked` / `locked` . `unlocked` indica que el usuario puede cambiar la directiva aumentando o disminuyendo la fecha de retención hasta. `locked` indica que estas acciones están prohibidas.
`x-ms-legal-hold`	Versión 2020-06-12 y versiones más recientes. Especifica la retención legal que se va a establecer en el blob; los valores válidos son `true/false` .

Esta operación admite los encabezados condicionales y para que se tengan x-ms-if-tags éxito solo si se cumple la condición x-ms-source-if-tags especificada. Para obtener más información, consulte Especificación de encabezados condicionales para las operaciones de Blob Service.

Cuerpo de la solicitud

Ninguno.

Response

La respuesta incluye un código de estado HTTP y un conjunto de encabezados de respuesta.

Código de estado

En la versión 2012-02-12 y versiones más recientes, una operación correcta devuelve el código de estado 202 (Aceptado).

En las versiones anteriores a 2012-02-12, una operación correcta devuelve el código de estado 201 (Creado).

Para obtener información sobre los códigos de estado, vea Códigos de estado y de error.

Encabezados de respuesta

La respuesta para esta operación incluye los encabezados siguientes. La respuesta también puede incluir otros encabezados HTTP estándar. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1.

Encabezado de respuesta	Descripción
`ETag`	En la versión 2012-02-12 y versiones más recientes, si se completa la copia, contiene la ETag del blob de destino. Si la copia no se completa, contiene la ETag del blob vacío creado al inicio de la copia. En las versiones anteriores a 2012-02-12, devuelve la ETag para el blob de destino. En la versión 2011-08-18 y versiones más recientes, el valor ETag estará entre comillas.
`Last-Modified`	Devuelve la fecha y la hora en la que se completó la operación de copia en el blob de destino.
`x-ms-request-id`	Este encabezado identifica de forma única la solicitud que se realizó y se puede utilizar para solucionar problemas relacionados con esta. Para más información, consulte Solución de problemas de operaciones de API.
`x-ms-version`	Indica la versión del servicio Blob utilizado para ejecutar la solicitud. Este encabezado se devuelve para las solicitudes realizadas en la versión 2009-09-19 y versiones posteriores.
`Date`	Valor de fecha y hora UTC generado por el servicio que indica la hora a la que se inició la respuesta.
`x-ms-copy-id: <id>`	Versión 2012-02-12 y versiones más recientes. Identificador de cadena para esta operación de copia. Utilícelo con `Get Blob` o `Get Blob Properties` para comprobar el estado de esta operación de copia, o páselo a `Abort Copy Blob` para anular una copia pendiente.
`x-ms-copy-status: <success \| pending>`	Versión 2012-02-12 y versiones más recientes. Estado de la operación de copia, con estos valores: - `success`: la copia se completó correctamente. - `pending`: la copia está en curso.
`x-ms-version-id: <DateTime>`	Versión 2019-12-12 y versiones más recientes. Valor DateTime devuelto por el servicio que identifica de forma única el blob. El valor de este encabezado indica la versión del blob y se puede usar en solicitudes posteriores para acceder a esta versión del blob. Este valor debe tratarse como opaco.
`x-ms-client-request-id`	Este encabezado se puede usar para solucionar problemas de solicitudes y respuestas correspondientes. El valor de este encabezado es igual al valor del encabezado si está presente en la solicitud y el valor tiene como máximo `x-ms-client-request-id` 1024 caracteres ASCII visibles. Si el `x-ms-client-request-id` encabezado no está presente en la solicitud, este encabezado no estará presente en la respuesta.

Cuerpo de la respuesta

Ninguno.

Respuesta de ejemplo

La siguiente es una respuesta de ejemplo para una solicitud de copia de un 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>

Authorization

El propietario de la cuenta puede llamar a esta operación. Para las solicitudes realizadas en la versión 2013-08-15 y posteriores, se admite una firma de acceso compartido que tiene permiso para escribir en el blob de destino o en su contenedor para las operaciones de copia dentro de la misma cuenta. Tenga en cuenta que la firma de acceso compartido especificada en la solicitud solo se aplica al blob de destino.

El acceso al blob o archivo de origen se autoriza por separado, como se describe en los detalles del encabezado de solicitud x-ms-copy-source .

En la tabla siguiente se describe cómo se pueden autorizar los objetos de destino y de origen de una operación copy blob.

Blob	Autorización con clave compartida/clave compartida Lite	Autorización con firma de acceso compartido	Objeto público que no requiere autorización
Blob de destino	Sí	Sí	No
Blob de origen en la misma cuenta	Sí	Sí	Sí
Blob de origen en otra cuenta	No	Sí	Sí
Archivo de origen en la misma cuenta u otra cuenta	No	Sí	N/D

Si una solicitud especifica etiquetas con el encabezado de solicitud, el autor de la llamada debe cumplir los requisitos de x-ms-tags autorización de la operación Establecer etiquetas de blob.

Observaciones

En la versión 2012-02-12 y versiones más recientes, la operación Copy Blob se puede completar de forma asincrónica. Esta operación devuelve un identificador de copia que se puede utilizar para comprobar o anular la operación de copia. Blob service copia blobs en función de la mejor opción.

El blob de origen para una operación de copia puede ser un blob en bloques, un blob en anexos, un blob en páginas o una instantánea. Si el blob de destino ya existe, debe ser del mismo tipo que el blob de origen. Si existe un blob de destino, se sobrescribirá. El blob de destino no puede modificarse mientras haya una operación de copia en curso.

En la versión 2015-02-21 y versiones posteriores, el origen de la operación de copia también puede ser un archivo en el servicio Azure File. Si el origen es un archivo, el destino debe ser un blob en bloques.

Es posible procesar secuencialmente varias operaciones Copy Blob pendientes en una cuenta. Un blob de destino solo puede tener una operación de copia de blob pendiente. En otras palabras, un blob no puede ser el destino de varias operaciones Copy Blob pendientes. Si se intenta realizar una operación Copy Blob en un blob de destino que ya tiene una copia pendiente, se producirá un error con el código de estado 409 (Conflicto).

Las cuentas de almacenamiento creadas desde el 7 de junio de 2012 son las únicas que permiten que la operación Copy Blob copie desde otra cuenta de almacenamiento. Si se intenta copiar de otra cuenta de almacenamiento en una cuenta creada antes del 7 de junio de 2012, se producirá un error con el código de estado 400 (Solicitud incorrecta).

La operación siempre copia todo el blob o archivo de origen; no se admite la copia de un intervalo de bytes o un conjunto Copy Blob de bloques.

Una operación Copy Blob puede adoptar cualquiera de las formas siguientes:

Puede copiar un blob de origen en un blob de destino con un nombre diferente. El blob de destino puede ser un blob existente del mismo tipo (en bloques, anexos o páginas), o puede ser un nuevo blob creado por la operación de copia.
Puede copiar un blob de origen en un blob de destino con el mismo nombre. De este modo, se reemplazará de forma efectiva el blob de destino. Este tipo de operación de copia quita los bloques sin confirmar y sobrescribe los metadatos del blob.
Puede copiar un archivo de origen del servicio de Azure File en un blob de destino. El blob de destino puede ser un blob en bloques existente o un nuevo blob de ese tipo creado por la operación de copia. No se admite la copia de archivos a blobs en páginas o blobs en anexos.
Puede copiar una instantánea sobre su blob base. Si se mueve una instantánea a la posición del blob, puede restaurar una versión anterior de un blob.
Puede copiar una instantánea en un blob de destino con un nombre diferente. El blob resultante de destino es un blob en el que se puede escribir y no una instantánea.

Al copiar desde un blob en páginas, el servicio Blob crea un blob en páginas de destino con la misma longitud que el blob de origen, y cuyo contenido inicial es todo ceros. A continuación, los intervalos de páginas de origen se enumeran, y se copian los intervalos no vacíos.

Para un blob en bloques o un blob en anexos, el Blob service crea un blob confirmado de longitud cero antes de volver de esta operación.

Al copiar desde un blob en bloques, se copian todos los bloques confirmados y sus iDs de bloque. Los bloques no confirmados no se copian. Al final de la operación de copia, el blob de destino tendrá el mismo número de bloques confirmados que el origen.

Al copiar desde un blob en anexos, se copian todos los bloques confirmados. Al final de la operación de copia, el blob de destino tendrá el mismo número de bloques confirmados que el origen.

Para todos los tipos de blob, puede llamar a Get Blob o en el blob de destino para comprobar el estado de la operación de Get Blob Properties copia. El blob final se confirmará cuando se complete la copia.

Cuando el origen de una operación de copia proporciona ETags, si se produce algún cambio en el origen mientras la copia está en curso, la copia producirá un error. Si se intenta cambiar el blob de destino mientras hay una copia en curso, se producirá un error con el código de estado 409 Conflicto. Si el blob de destino tiene una concesión infinita, el identificador de concesión se debe pasar a Copy Blob. Las concesiones de duración finita no se permiten.

La ETag para un blob en bloques cambia cuando se inicia la operación Copy Blob y cuando finaliza la copia. La ETag para un blob en páginas cambia cuando se inicia la operación Copy Blob, y sigue cambiando con frecuencia durante la copia. El contenido de un blob en bloques solo será visible si se utiliza un GET al finalizar la copia completa.

Copiar propiedades, etiquetas y metadatos de blobs

Cuando se copia un blob, las propiedades del sistema siguientes se copian en el blob de destino con los mismos valores:

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition
x-ms-blob-sequence-number (for page blobs only)
x-ms-committed-block-count (for append blobs only, and for version 2015-02-21 only)

La lista de bloques confirmados del blob de origen también se copia en el blob de destino, si este es un blob en bloques. No se copiarán los bloques sin confirmar.

El blob de destino tiene siempre el mismo tamaño que el blob de origen, de modo que el valor del encabezado Content-Length para el blob de destino coincida con el del blob de origen.

Cuando el blob de origen y el blob de destino son iguales, Copy Blob quita los bloques sin confirmar. Si se especifican metadatos en este caso, los metadatos existentes se sobrescriben con los nuevos.

Si se proporcionan etiquetas para el blob de destino en el x-ms-tags encabezado, deben estar codificadas en cadena de consulta. Las claves y los valores de etiqueta deben cumplir los requisitos de nomenclatura y longitud, tal y como se especifica en Establecer etiquetas de blob. Además, el x-ms-tags encabezado puede contener hasta 2 KB de etiquetas. Si se requieren más etiquetas, use la operación Establecer etiquetas de blob.

Si no se proporcionan etiquetas en el encabezado, no x-ms-tags se copian del blob de origen.

Copiar un blob sujeto a una concesión

La operación Copy Blob solo lee del blob de origen, por lo que el estado de concesión de este no es relevante. Sin embargo, la operación Copy Blob guarda la ETag del blob de origen cuando se inicia la copia. Si el valor ETag cambia antes de que finalice la copia, la copia produce un error. Para evitar que se realicen cambios en el blob de origen, establezca una concesión sobre el mismo durante la operación de copia.

Si el blob de destino tiene una concesión infinita activa, debe especificar el identificador de concesión en la llamada a la operación Copy Blob. Si la concesión especificada es una concesión activa de duración finita, esta llamada produce un error con un código de estado 412 (Error de condición previa). Mientras la copia está pendiente, las operaciones de concesión en el blob de destino producirán un error con el código de estado 409 (Conflicto). Una concesión infinita en el blob de destino se bloquea de esta manera durante la operación de copia siempre que la copia se realice en un blob de destino con un nombre diferente del de origen, en un blob de destino con el mismo nombre que el de origen o se promueva una instantánea sobre su blob base. Si el cliente especifica un identificador de concesión en un blob que aún no existe, Blob service devolverá el código de estado 412 (Error de condición previa) para las solicitudes realizadas en la versión 2013-08-15 y posteriores; para las versiones anteriores, Blob service devolverá el código de estado 201 (Creado).

Copiar instantáneas

Cuando se copia un blob de origen, las instantáneas o versiones del blob de origen no se copian en el destino. Cuando un blob de destino se sobrescribe con una copia, las instantáneas o versiones asociadas al blob de destino permanecen intactas bajo su nombre.

Puede realizar una operación de copia para promover un blob de instantánea sobre su blob base. De esta forma puede restaurar una versión anterior de un blob. La instantánea se conserva, pero el destino se sobrescribe con una copia que se puede leer y escribir.

Copiar versiones

Puede realizar una operación de copia para promover un blob de versión sobre su blob base. De esta forma puede restaurar una versión anterior de un blob. La versión permanece, pero su destino se sobrescribe con una copia que se puede leer y escribir.

Copia de blob archivado (versión 2018-11-09 y versiones posteriores)

Un blob archivado se puede copiar en un nuevo blob dentro de la misma cuenta de almacenamiento. Esto seguirá desasoyéndo el blob archivado inicialmente tal y como está. Al copiar un blob archivado como origen, la solicitud debe contener el encabezado x-ms-access-tier que indica el nivel del blob de destino. Los datos se copiarán finalmente en el blob de destino.

El origen y el destino de copia deben ser la misma cuenta de almacenamiento cuando se archiva el origen. La solicitud producirá un error con Conflicto si el origen de la copia sigue en estado de rehidratación pendiente.

Para obtener información detallada sobre los niveles de blob en bloques, consulte Niveles de almacenamiento de acceso es cool y de archivo.

Trabajar con una copia pendiente (versión 2012-02-12 y versiones más recientes)

Si la operación completa la copia de forma asincrónica, use la tabla siguiente para determinar el paso siguiente en función del código Copy Blob de estado devuelto por Copy Blob :

Código de estado	Significado
202 (Aceptado), x-ms-copy-status: success	La copia se realizó correctamente.
202 (Aceptado), x-ms-copy-status: pending	La copia no se ha completado. Sondee el blob de destino mediante `Get Blob Properties` para examinar el encabezado x-ms-copy-status hasta que la copia se complete o produzca un error.
4xx, 500 o 503	Se ha producido un error en la copia.

Tanto durante una operación Copy Blob como después de ella, las propiedades del blob de destino contienen el identificador de copia de la operación Copy Blob y la dirección URL del blob de origen. Cuando se completa la copia, el servicio Blob escribe el valor de la hora y del resultado (success, failed o aborted) en las propiedades del blob de destino. Si el resultado de la operación es failed, el encabezado x-ms-copy-status-description contiene una cadena de detalles de error.

Una operación Copy Blob pendiente tiene un tiempo de espera de 2 semanas. Si la copia no se ha completado después de 2 semanas, se agota el tiempo de espera y se obtiene un blob vacío con el campo x-ms-copy-status establecido en failed y el campo x-ms-copy-status-description establecido en 500 (Operación cancelada). Los errores intermitentes o recuperables que pueden aparecer durante una copia podrían impedir el progreso de esta, pero no que se complete. En estos casos, x-ms-copy-status-description describe los errores intermitentes.

Cualquier intento de modificar o realizar una instantánea del blob de destino durante la copia generará un error con el código de estado 409 (Conflicto) Copia de blob en curso.

Si llama a la operación Abort Copy Blob, verá un encabezado x-ms-copy-status:aborted y el blob de destino tendrá los metadatos intactos y una longitud de blob de cero bytes. Puede repetir la llamada original a Copy Blob para volver a intentar la copia de nuevo.

Si la Copy Blob operación se completa sincrónicamente, use la tabla siguiente para determinar el estado de la operación de copia:

Código de estado	Significado
202 (Aceptado), x-ms-copy-status: success	La copia se realizó correctamente.
4xx, 500 o 503	Se ha producido un error en la copia.

El nivel se hereda para los niveles de almacenamiento Premium. En el caso de los blobs en bloques, la sobrescritura del blob de destino heredará el nivel de acceso es decir, es decir, el nivel de acceso esfráfilo del destino si no se proporciona x-ms-access-tier. Se producirá un error al sobrescribir un blob archivado. Para obtener información detallada sobre los niveles de blob en bloques, consulte Niveles de almacenamiento de acceso es cool y de archivo.

Facturación

Se cobra una transacción en la cuenta de destino de una operación Copy Blob por iniciar la copia, y también se contabiliza una transacción por cada solicitud de anulación u obtención del estado de la operación de copia.

Cuando el blob de origen está en otra cuenta, la cuenta de origen soporta costos de transacción. Además, si las cuentas de origen y de destino residen en regiones diferentes (por ejemplo, Norte de EE. UU. y Sur de EE. UU.), el ancho de banda utilizado para transferir la solicitud se carga en la cuenta de almacenamiento de origen como salidas. Las salidas entre cuentas de la misma región son gratuitas.

Al copiar un blob de origen en un blob de destino con un nombre diferente en la misma cuenta, se utilizan recursos de almacenamiento adicionales para el nuevo blob, por lo que la operación de copia conlleva unos costos por el uso de la capacidad de la cuenta de almacenamiento para esos recursos adicionales. Sin embargo, si el nombre del blob de origen y el de destino es el mismo en la misma cuenta (por ejemplo, cuando se promueve una instantánea a su blob base), no se conlleva ningún cargo adicional que no sean los metadatos de copia adicionales almacenados en la versión 2012-02-12 y versiones más recientes.

Cuando se promueve una instantánea para reemplazar su blob base, la instantánea y el blob base pasan a ser idénticos. Comparten bloques o páginas, por lo que la operación de copia no da como resultado un costo adicional por el uso de la capacidad de la cuenta de almacenamiento. Sin embargo, si copia una instantánea en un blob de destino con un nombre diferente, conllevará un costo adicional por los recursos de almacenamiento utilizados por el nuevo blob resultante. Dos blobs con nombres diferentes no pueden compartir bloques o páginas aunque sean idénticos. Para obtener más información sobre los escenarios de costo de instantáneas, vea Descripción de cómo las instantáneas acumulan cargos.

Vea también

Autorización de solicitudes para Azure Storage
Códigos de estado y error
Códigos de error de Blob Service
Descripción de cómo las instantáneas acumulan cargos
Abort Copy Blob