Compartir a través de

Copiar Blob

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

En la versión 2012-02-12 y posteriores, el origen de una Copy Blob operación 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 Copy Blob operación puede ser un archivo de Azure en cualquier cuenta de almacenamiento de Azure.

Nota:

Solo las cuentas de almacenamiento creadas a partir del 7 de junio de 2012 permiten que la Copy Blob operación se copie desde otra cuenta de almacenamiento.

Solicitud

Puede construir la solicitud Copy Blob de la siguiente manera. 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 (SAS) para el blob de destino si está 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 está en una cuenta de almacenamiento diferente.

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

URI para el servicio de almacenamiento emulado

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

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

Para más información, consulte Uso del emulador de Azurite para el desarrollo local de Azure Storage.

Parámetros de URI

Puede especificar los siguientes parámetros adicionales 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, consulte Establecer tiempos de espera para operaciones de Blob Storage.

Cabeceras de solicitud

En la tabla siguiente se describen los encabezados de solicitud obligatorios y opcionales:

Cabecera de solicitud Descripción
Authorization Obligatorio. Especifica el esquema de autorización, el nombre de la cuenta y la firma. Para más información, consulte Autorizar solicitudes a Azure Storage.
Date o x-ms-date Obligatorio. Especifica la hora universal coordinada (UTC) de la solicitud. Para más información, consulte Autorizar solicitudes a Azure Storage.
x-ms-version Necesario para todas las solicitudes autorizadas. Para más información, consulte Control de versiones de para los servicios de Azure Storage.
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 copia los metadatos del blob o archivo de origen en el 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.

A partir de la versión 2009-09-19, los nombres de metadatos deben cumplir las reglas de nomenclatura para los identificadores de C#. Para obtener más información, consulte Nomenclatura y referencia a contenedores, blobs y metadatos.
x-ms-tags Opcional. Establece las etiquetas codificadas en cadena de consulta especificadas en el blob. Las etiquetas no se copian del origen de copia. Para obtener más información, vea Comentarios. Compatible con la versión 2019-12-12 y posteriores.
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 y hora especificadas. Si el blob de origen no se ha modificado, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado 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 y hora especificadas. Si se ha modificado el blob de origen, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado 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 su ETag valor coincide con el valor especificado. Si los valores no coinciden, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado 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 solo si su ETag valor no coincide con el valor especificado. Si los valores son idénticos, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado 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 y hora especificadas. Si el blob de destino no se ha modificado, Blob Storage 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 y hora especificadas. Si se ha modificado el blob de destino, Blob Storage devuelve el código de estado 412 (error de condición previa).
If-Match Opcional. Valor ETag. Especifique un ETag valor para este encabezado condicional para copiar el blob solo si el valor especificado ETag coincide con el valor de ETag un blob de destino existente. Si los valores no coinciden, Blob Storage devuelve el código de estado 412 (error de condición previa).
If-None-Match Opcional. Un ETag valor o el carácter comodín (*).

Especifique un ETag valor para este encabezado condicional para copiar el blob solo si el valor especificado ETag no coincide con el ETag valor 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 Storage 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 kibibytes (KiB) de longitud que especifica un blob. El valor debe estar codificado en dirección URL, tal como aparecería en un URI de solicitud.

La operación de lectura en un blob de origen de la misma cuenta de almacenamiento se puede autorizar a través de una clave compartida. A partir de la versión 2017-11-09, también puede usar el identificador de Microsoft Entra para autorizar la operación de lectura en el blob de origen. Sin embargo, si el origen es un blob de otra cuenta de almacenamiento, el blob de origen debe ser público o el acceso a él debe estar autorizado mediante 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 Azure Files. Si el objeto de origen es un archivo que se va a copiar en un blob, el archivo de origen debe autorizarse a través de una firma de acceso compartido, tanto si reside en la misma cuenta como en otra diferente.

Solo las cuentas de almacenamiento creadas a partir del 7 de junio de 2012 permiten que la Copy Blob operación se 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 de Azure Files, la dirección URL de origen usa el siguiente formato. 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 dentro de la misma cuenta y un nombre de origen puede usar 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 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 el identificador no es válido, se produce un error en la operación con el código de estado 412 (error en la condición previa).

Si se especifica este encabezado y el blob de destino no tiene actualmente una concesión activa, se produce un error en la operación con el código de estado 412 (error de condición previa).

En la versión 2012-02-12 y posteriores, este valor debe especificar una concesión infinita activa para un blob arrendado. Se produce un error en un ID de concesión de duración finita con el código de estado 412 (error de condición previa).
x-ms-source-lease-id: <ID> Opcional para versiones anteriores a 2012-02-12 (no compatible en 2012-02-12 y posteriores). Especifique este encabezado para realizar la Copy Blob operación solo si el identificador de concesión proporcionado coincide con el identificador de concesión activo del blob de origen.

Si se especifica este encabezado y el blob de origen no tiene actualmente una concesión activa, se produce un error en la operación 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 cuando se configura el registro. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes que recibe el servidor.
x-ms-access-tier Opcional. Especifica el nivel que se va a establecer en el blob de destino. Este encabezado es para blobs en páginas en una cuenta premium solo con la versión 2017-04-17 y posteriores. Para obtener una lista completa de los niveles admitidos, consulte Almacenamiento premium de alto rendimiento y discos administrados para máquinas virtuales. Este encabezado se admite en la versión 2018-11-09 y posteriores para blobs en bloques. La organización en niveles de blobs en bloques se admite en cuentas de Blob Storage o de uso general v2. Los valores válidos son Hot, Cool, Cold y Archive. Nota:Cold nivel es compatible con la versión 2021-12-02 y posteriores. Para obtener información detallada sobre la organización en niveles de blobs en bloques, consulte Niveles de almacenamiento frecuente, esporádico y de archivo.
x-ms-rehydrate-priority Opcional. Indica la prioridad con la que rehidratar un blob archivado. Este encabezado se admite en la versión 2019-02-02 y posteriores para blobs en bloques. Los valores válidos son High y Standard. Puede establecer la prioridad 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. Este encabezado solo es válido para blobs en anexos. Sella el blob de destino una vez finalizada la operación de copia.
x-ms-immutability-policy-until-date Versión 2020-06-12 y posteriores. Especifica la fecha de retención hasta que se establecerá en el blob. Esta es la fecha hasta la cual el blob se puede proteger contra modificaciones o eliminaciones. Sigue RFC1123 formato.
x-ms-immutability-policy-mode Versión 2020-06-12 y posteriores. Especifica el modo de directiva de inmutabilidad que se va a establecer en el blob. Los valores válidos son unlocked y locked. Un unlocked valor indica que el usuario puede cambiar la directiva aumentando o disminuyendo la fecha de retención hasta. Un locked valor indica que estas acciones están prohibidas.
x-ms-legal-hold Versión 2020-06-12 y posteriores. Especifica la retención legal que se va a establecer en el blob. Los valores válidos son true y false.

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

Cuerpo de la solicitud

Ninguno.

Respuesta

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 posteriores, 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 de esta operación incluye los siguientes encabezados. La respuesta también puede incluir encabezados HTTP estándar adicionales. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1 de .

Encabezado de respuesta Descripción
ETag En la versión 2012-02-12 y posteriores, si la copia está completa, este encabezado contiene el ETag valor del blob de destino. Si la copia no está completa, el encabezado contiene el ETag valor del blob vacío creado al principio de la operación de copia.

En las versiones anteriores a 2012-02-12, este encabezado devuelve el valor del ETag blob de destino.

En la versión 2011-08-18 y posteriores, el ETag valor está entre comillas.
Last-Modified Devuelve la fecha y hora en que finalizó la operación de copia en el blob de destino.
x-ms-request-id Identifica de forma única la solicitud que se realizó. Puede usar este encabezado para solucionar problemas de la solicitud. Para obtener más información, consulte Solución de problemas de operaciones de API.
x-ms-version Indica la versión de Blob Storage que se usa para ejecutar la solicitud. Este encabezado se devuelve para las solicitudes realizadas en la versión 2009-09-19 y posteriores.
Date Valor de fecha y hora UTC que indica la hora a la que el servicio envió la respuesta.
x-ms-copy-id: <id> Versión 2012-02-12 y posteriores. Proporciona un identificador de cadena para esta operación de copia. Use con Get Blob o Get Blob Properties para comprobar el estado de esta operación de copia o pasar a Abort Copy Blob para cancelar una operación de copia pendiente.
x-ms-copy-status: <success ¦ pending> Versión 2012-02-12 y posteriores. Indica el estado de la operación de copia, con estos valores:

- success: La operación finalizó correctamente.
- pending: La operación está en curso.
x-ms-version-id: <DateTime> Versión 2019-12-12 y posteriores. Identifica de forma única el blob por su versión. Puede usar este valor opaco en solicitudes posteriores para acceder a esta versión del blob.
x-ms-client-request-id Se puede usar para solucionar problemas de solicitudes y respuestas correspondientes. El valor de este encabezado es igual al valor del encabezado x-ms-client-request-id, si está presente en la solicitud y el valor es como máximo 1024 caracteres ASCII visibles. Si el encabezado x-ms-client-request-id no está presente en la solicitud, este encabezado no estará presente en la respuesta.

Cuerpo de respuesta

Ninguno.

Respuesta de ejemplo

El código siguiente es una respuesta de ejemplo para una solicitud para copiar 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>

Autorización

Se requiere autorización al llamar a cualquier operación de acceso a datos en Azure Storage. En la tabla siguiente se describe cómo se pueden autorizar los objetos de destino y de origen de una operación de Copy Blob:

Tipo de objeto Autorización de ID de Microsoft Entra Autorización de firma de acceso compartido (SAS) Autorización de clave compartida (o clave compartida lite)
Blob de destino Sí Sí Sí
Blob de origen en la misma cuenta de almacenamiento Sí Sí Sí
Blob de origen en otra cuenta de almacenamiento No Sí No

Si una solicitud especifica etiquetas en el encabezado de la x-ms-tags solicitud, el autor de la llamada debe cumplir los requisitos de autorización de la operación Set Blob Tags .

Puede autorizar la operación de Copy Blob como se describe a continuación. Tenga en cuenta que un blob en origen de una cuenta de almacenamiento diferente debe autorizarse por separado a través de un token de SAS con el permiso de lectura (r). Para obtener más información sobre la autorización de blobs en el origen, consulte los detalles del encabezado x-ms-copy-sourcede solicitud .

Importante

Microsoft recomienda usar el identificador de Entra de Microsoft con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona seguridad y facilidad de uso superiores en comparación con la autorización de clave compartida.

Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad. La entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada de Azure. Microsoft Entra ID autentica la entidad de seguridad para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.

Para obtener más información sobre la autorización mediante el identificador de Entra de Microsoft, consulte Autorizar el acceso a blobs mediante el identificador de Microsoft Entra.

Permisos

A continuación se enumeran las acciones de RBAC necesarias para que un usuario, grupo, identidad administrada o entidad de servicio de Microsoft Entra llame a la operación de Copy Blob y el rol RBAC integrado con privilegios mínimos que incluye esta acción:

Blob de destino

Blob de origen dentro de la misma cuenta de almacenamiento

Para más información sobre cómo asignar roles mediante Azure RBAC, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

Observaciones

En la versión 2012-02-12 y posteriores, la Copy Blob operación puede finalizar de forma asincrónica. Esta operación devuelve un ID de copia que puede utilizar para comprobar o cancelar la operación de copia. Debido a la naturaleza asincrónica de la operación de copia, Blob Storage copia los blobs en la medida de lo posible. El servicio Blob copia blobs cuando los recursos del servidor no están siendo utilizados por otras tareas, por lo que no se garantiza que una copia se inicie inmediatamente o se complete en un período de tiempo especificado.

El blob de origen de 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 de blob que el blob de origen. Se sobrescribirá cualquier blob de destino existente. No se puede modificar el blob de destino mientras hay una operación de copia en curso.

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

Es posible que varias operaciones pendientes Copy Blob dentro de una cuenta se procesen secuencialmente. Un blob de destino solo puede tener una operación pendiente Copy Blob . En otras palabras, un blob no puede ser el destino de varias operaciones pendientes Copy Blob . Un intento de copiar un blob en un blob de destino que ya tiene una operación de copia pendiente falla con el código de estado 409 (conflicto).

Solo las cuentas de almacenamiento creadas a partir del 7 de junio de 2012 permiten que la Copy Blob operación se copie desde otra cuenta de almacenamiento. Un intento de copiar desde otra cuenta de almacenamiento a una cuenta creada antes del 7 de junio de 2012 falla con el código de estado 400 (solicitud incorrecta).

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

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

  • Puede copiar un blob de origen en un blob de destino que tenga un nombre diferente. El blob de destino puede ser un blob existente del mismo tipo de blob (bloque, anexión o página) o puede ser un nuevo blob que crea la operación de copia.

  • Puede copiar un blob de origen en un blob de destino que tenga el mismo nombre, reemplazando eficazmente al blob de destino. Esta operación de copia quita los bloques no confirmados y sobrescribe los metadatos del blob.

  • Puede copiar un archivo de origen de Azure Files en un blob de destino. El blob de destino puede ser un blob en bloques existente o puede ser un nuevo blob en bloques que crea 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 que tenga 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, Blob Storage crea un blob en páginas de destino de la longitud del blob de origen. Inicialmente, el blob en páginas contiene todos los ceros. A continuación, se enumeran los intervalos de páginas de origen y se copian los intervalos no vacíos.

En el caso de un blob en bloques o un blob en anexos, Blob Storage 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 identificadores de bloque. Los bloques no confirmados no se copian. Al final de la operación de copia, el blob de destino tiene 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á menos o el mismo número de bloques confirmados que el blob de origen.

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

Cuando el origen de una operación de copia proporciona ETag valores, cualquier cambio en el origen mientras la operación de copia está en curso hará que se produzca un error en esa operación. Se producirá un error al intentar cambiar el blob de destino mientras hay una copia en curso con el código de estado 409 (conflicto). Si el blob de destino tiene una concesión infinita, el identificador de concesión debe pasarse a Copy Blob. No se permiten arrendamientos de duración finita.

El ETag valor de un blob en bloques cambia cuando se inicia la Copy Blob operación y cuando finaliza. El ETag valor de un blob en páginas cambia cuando se inicia la Copy Blob operación y sigue cambiando con frecuencia durante la operación de copia. El contenido de un blob en bloques solo es visible a través de un Get comando una vez finalizada la operación de copia completa.

Copia de propiedades, etiquetas y metadatos de blobs

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

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (solo para blobs en páginas)

  • x-ms-committed-block-count (solo para blobs en anexos y solo para la versión 2015-02-21)

La lista de bloqueo confirmada del blob de origen también se copia en el blob de destino, si el blob es un blob en bloques. Los bloques no confirmados no se copian.

El blob de destino siempre tiene el mismo tamaño que el blob de origen. El valor del Content-Length encabezado del blob de destino coincide con el valor de ese encabezado del blob de origen.

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

Si el x-ms-tags encabezado proporciona etiquetas para el blob de destino, 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.

El x-ms-tags encabezado puede contener hasta 2 kilobits de etiquetas. Si necesita más etiquetas, utilice la Set Blob Tags operación.

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

Copia de un blob arrendado

La Copy Blob operación solo lee del blob de origen, por lo que el estado de concesión del blob de origen no importa. Sin embargo, la Copy Blob operación guarda el ETag valor del blob de origen cuando se inicia la operación de copia. Si el ETag valor cambia antes de que finalice la operación de copia, se produce un error en la operación. Puede evitar cambios en el blob de origen concediéndolo durante la operación de copia.

Si el blob de destino tiene una concesión infinita activa, debe especificar su identificador de concesión en la llamada a la Copy Blob operación. Si la concesión especificada es una concesión activa de duración finita, se produce un error en esta llamada con un código de estado 412 (error de condición previa). Mientras la operación de copia está pendiente, se produce un error en cualquier operación de concesión en el blob de destino 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, tanto si se copia en un blob de destino que tiene un nombre diferente al del origen, como si se copia en un blob de destino que tiene el mismo nombre que el origen o se promociona 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 Storage devuelve el código de estado 412 (error de condición previa) para las solicitudes realizadas en la versión 2013-08-15 y posteriores. En el caso de versiones anteriores, Blob Storage devuelve el código de estado 201 (Creado).

Copia de instantáneas de blobs

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 una instantánea sobre su blob base, siempre que esté en un nivel en línea (frecuente o esporádico). De este modo, puede restaurar una versión anterior de un blob. La instantánea permanece, pero su destino se sobrescribe con una copia que se puede leer y escribir.

Copia de versiones de blob

Puede realizar una operación de copia para promocionar una versión sobre su blob base, siempre que esté en un nivel en línea (frecuente o esporádico). De este modo, puede restaurar una versión anterior de un blob. La versión se mantiene, pero su destino se sobrescribe con una copia que se puede leer y escribir.

Copia de un blob archivado

A partir de la versión 2018-11-09, puede copiar un blob archivado en un nuevo blob dentro de la misma cuenta de almacenamiento. El blob de origen permanece en el nivel de archivo. Cuando el blob de origen es un blob archivado, la solicitud debe contener el x-ms-access-tier encabezado, que indica el nivel del blob de destino. El blob de destino debe estar en un nivel en línea. No se puede copiar en un blob en el nivel de archivo.

A partir de la versión 2021-02-12, puede copiar un blob archivado en un nivel en línea en una cuenta de almacenamiento diferente, siempre que la cuenta de destino esté en la misma región que la cuenta de origen.

Es posible que se produzca un error en la solicitud si se está rehidratando el blob de origen.

Para obtener información detallada sobre la organización en niveles en el nivel de blob en bloques, consulte Niveles de almacenamiento frecuente, esporádico y de archivo.

Trabajar con una operación de copia pendiente (versión 2012-02-12 y posteriores)

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

Código de estado Significado
202 (aceptado), x-ms-copy-status: success La operación de copia finalizó correctamente.
202 (aceptado), x-ms-copy-status: pendiente La operación de copia no ha finalizado. Sondee el blob de destino mediante el uso Get Blob Properties para examinar el x-ms-copy-status encabezado hasta que la operación finalice o se produzca un error.
4xx, 500 o 503 Error en la operación de copia.

Durante y después de una Copy Blob operación, las propiedades del blob de destino contienen el identificador de copia de la Copy Blob operación y la dirección URL del blob de origen. Cuando finaliza la operación, Blob Storage escribe el valor de tiempo y resultado (success, failedo aborted) en las propiedades del blob de destino. Si la operación tiene un resultado failed, el encabezado x-ms-copy-status-description contiene una cadena de detalles de error.

Una operación de Copy Blob pendiente tiene un tiempo de espera de dos semanas. Un intento de copia que no ha finalizado después de dos semanas agota el tiempo de espera y deja un blob vacío con el x-ms-copy-status campo establecido en failed y el x-ms-copy-status-description establecido en 500 (OperationCancelled). Los errores intermitentes y no irrecuperables que pueden producirse durante una operación de copia podrían impedir el progreso de la operación, pero no provocar un error. En estos casos, x-ms-copy-status-description describe los errores intermitentes.

Cualquier intento de modificar o tomar una instantánea del blob de destino durante la operación de copia producirá un error con el código de estado 409 (conflicto), "Copiar blob en curso".

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

Si la Copy Blob operación finaliza de forma sincrónica, utilice 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 operación de copia finalizó correctamente.
4xx, 500 o 503 Error en la operación de copia.

El nivel se hereda para los niveles de almacenamiento premium. En el caso de los blobs en bloques, si no se proporciona el blob en bloques, se sobrescribirá el nivel de acceso frecuente o esporádico del destino x-ms-access-tier . Se producirá un error al sobrescribir un blob archivado. Para obtener información detallada sobre la organización en niveles en el nivel de blob en bloques, consulte Niveles de almacenamiento frecuente, esporádico y de archivo.

Facturación

Las solicitudes de precios pueden originarse en clientes que usan api de Blob Storage, ya sea directamente a través de la API REST de Blob Storage o desde una biblioteca cliente de Azure Storage. Estas solicitudes acumulan cargos por transacción. El tipo de transacción afecta a cómo se cobra la cuenta. Por ejemplo, las transacciones de lectura se acumulan en una categoría de facturación diferente a las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de las solicitudes de Copy Blob en función del tipo de cuenta de almacenamiento:

Operación Tipo de cuenta de almacenamiento Categoría de facturación
Copy Blob (cuenta de destino1) Blob en bloques Premium
Uso general estándar v2
Uso general estándar v1		 Operaciones de escritura
Copy Blob (cuenta de origen2) Blob en bloques Premium
Uso general estándar v2
Uso general estándar v1		 Operaciones de lectura

1La cuenta de destino se cobra por una transacción para iniciar la escritura.
número arábigoCuando el objeto de origen está en una cuenta diferente, la cuenta de origen incurre en una transacción por cada solicitud de lectura al objeto de origen.

Para obtener información sobre los precios de las categorías de facturación especificadas, consulte precios de Azure Blob Storage.

La cuenta de destino también incurre en costos de transacción por cada solicitud para cancelar la operación de copia (vea Anular blob de copia) o para comprobar el estado de la operación de copia (vea Obtener blob u Obtener propiedades de blob).

Además, si las cuentas de origen y destino residen en regiones diferentes (por ejemplo, Norte de EE. UU. y Sur de EE. UU.), el ancho de banda que use para transferir la solicitud se cargará a la cuenta de almacenamiento de origen como salida. La salida entre cuentas dentro de la misma región es gratuita.

Al copiar un blob de origen en un blob de destino que tiene un nombre diferente dentro de la misma cuenta, se utilizan recursos de almacenamiento adicionales para el nuevo blob. A continuación, la operación de copia da lugar a un cargo por el uso de la capacidad de la cuenta de almacenamiento para esos recursos adicionales. Sin embargo, si los nombres de los blobs de origen y destino son los mismos dentro de la misma cuenta (por ejemplo, cuando se promueve una instantánea a su blob base), no se incurre en ningún cargo adicional, aparte de los metadatos de copia adicionales almacenados en la versión 2012-02-12 y posteriores.

Al promover 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 genera un cargo adicional en el uso de la capacidad de la cuenta de almacenamiento. Sin embargo, si copia una instantánea en un blob de destino que tiene un nombre diferente, esa operación incurre en un cargo adicional por los recursos de almacenamiento que usa el nuevo blob resultante. Dos blobs que tienen nombres diferentes no pueden compartir bloques o páginas, incluso si son idénticos. Para obtener más información sobre los escenarios de costo de instantáneas, consulte Descripción de cómo las instantáneas acumulan cargos.

Consulte también

Autorizar solicitudes a Azure Storage
códigos de error y estado
códigos de error de Blob Storage
Descripción de cómo se acumulan cargos en las instantáneas
Anular blob de copia