Copia de blobs

Artículo
04/11/2023

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 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 el 7 de junio de 2012 o después, permiten que la Copy Blob operación se copie desde otra cuenta de almacenamiento.

Solicitud

Puede construir la solicitud de la Copy Blob 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 se encuentra en otra cuenta de almacenamiento.

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

URI para el servicio de almacenamiento emulado

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

URI de solicitud de método PUT	Versión de 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 desarrollo y pruebas locales de Azure Storage.

Parámetros del identificador URI

Puedes especificar los siguientes parámetros adicionales en el URI de la solicitud:

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

Encabezados de solicitud

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

Encabezado de solicitud	Descripción
`Authorization`	Necesario. Especifica el esquema de autorización, el nombre de cuenta y la firma. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
`Date` o `x-ms-date`	Necesario. Especifica la hora universal coordinada (UTC) de la solicitud. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
`x-ms-version`	Necesario para todas las solicitudes autorizadas. Para obtener más información, vea Versiones de 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 especifican pares 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 más información, consulte Nomenclatura y referencia a contenedores, blobs y metadatos.
`x-ms-tags`	Opcional. Establece las etiquetas con codificación de 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 u 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 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 u 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 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 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 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 u 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 u 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 `ETag` valor de 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. Valor `ETag` o 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`	Necesario. 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 como dirección URL, ya que 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 la clave compartida. A partir de la versión 2017-11-09, también puede usar Microsoft Entra ID para autorizar la operación de lectura en el blob de origen. Sin embargo, si el origen es un blob en otra cuenta de almacenamiento, el blob de origen debe ser público o el acceso a él debe estar autorizado a través de una firma de acceso compartido. Si el blob de origen es público, no se requiere 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 copiará en un blob, el archivo de origen debe estar autorizado a través de una firma de acceso compartido, tanto si reside en la misma cuenta como en otra. Solo las cuentas de almacenamiento creadas el 7 de junio de 2012 o después, 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 en Azure Files, 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 dentro de la misma cuenta y un nombre de origen puede usar estos formatos: - Blob en el contenedor con nombre: `/accountName/containerName/blobName` - Instantánea en el 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 el identificador no es válido, se produce un error en la operación 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, 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 concedido. Se produce un error en un identificador 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 las versiones anteriores a 2012-02-12 (no compatibles en 2012-02-12 y versiones 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 es compatible con la versión 2018-11-09 y posteriores para blobs en bloques. El almacenamiento en capas de blobs en bloques se admite en Blob Storage o en cuentas de De uso general v2. Los valores válidos son `Hot`, `CoolCold` y `Archive`. Nota:`Cold` tier es compatible con la versión 2021-12-02 y posteriores. Para obtener información detallada sobre los niveles de blob en bloques, consulte Niveles de almacenamiento de acceso frecuente , esporádico y de archivo.
`x-ms-rehydrate-priority`	Opcional. Indica la prioridad con la que rehidratar un blob archivado. Este encabezado es compatible con la versión 2019-02-02 y posteriores para blobs en bloques. Los valores válidos son `High` y `Standard`. Solo puede establecer la prioridad en un blob 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. Cierra 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 va a establecer en el blob. Esta es la fecha hasta la que el blob se puede proteger de la modificación o eliminación. 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 la fecha. Un `locked` valor indica que estas acciones están prohibidas.
`x-ms-legal-hold`	Versión 2020-06-12 y posteriores. Especifica la suspensió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 más información, consulte Especificación de encabezados condicionales para las operaciones de Blob Storage.

Cuerpo de la solicitud

Ninguno.

Response

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

status code

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, consulte Códigos de estado y 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 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 versiones anteriores a 2012-02-12, este encabezado devuelve el `ETag` valor del 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 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 versiones posteriores.
`Date`	Valor de fecha y hora UTC que indica la hora en 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 para `Abort Copy Blob` 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 `x-ms-client-request-id` encabezado, si está presente en la solicitud y el valor es como máximo de 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.

Response body

Ninguno.

Respuesta de muestra

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>

Authorization

La autorización es necesaria 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 Copy Blob operación:

Tipo de objeto	autorización de Microsoft Entra ID	Autorización de firma de acceso compartido (SAS)	Autorización de clave compartida (o Shared Key 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 x-ms-tags solicitud, el autor de la llamada debe cumplir los requisitos de autorización de la operación Establecer etiquetas de blob .

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

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. La entidad de seguridad se autentica mediante Microsoft Entra ID para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.

Para más información sobre la autorización mediante Microsoft Entra ID, consulte Autorización del acceso a blobs mediante Microsoft Entra ID.

Permisos

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

Blob de destino

Acción de RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (para escribir en un blob existente) o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (para escribir un nuevo blob en el destino)
Rol integrado con privilegios mínimos:Colaborador de datos de Storage Blob

Blob de origen dentro de la misma cuenta de almacenamiento

Acción RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Rol integrado con privilegios mínimos:Lector de datos de Storage Blob

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

Una firma de acceso compartido (SAS) proporciona acceso delegado seguro a los recursos de una cuenta de almacenamiento. Con una SAS, tiene un control granular sobre cómo un cliente puede acceder a los datos. Puede especificar a qué recurso puede tener acceso el cliente, a qué permisos tienen esos recursos y cuánto tiempo es válido la SAS.

La Copy Blob operación admite tres tipos de firmas de acceso compartido: SAS de delegación de usuarios, SAS de servicio y SAS de cuenta.

Como procedimiento recomendado de seguridad, se recomienda usar Microsoft Entra credenciales en lugar de la clave de la cuenta de almacenamiento, lo que se puede poner en peligro más fácilmente. Si el diseño de la aplicación requiere firmas de acceso compartido, use Microsoft Entra credenciales para crear una SAS de delegación de usuarios, siempre que sea posible.

Cuando no se permite el acceso a la clave compartida para la cuenta de almacenamiento, no se permitirá un token de SAS de servicio o un token de SAS de cuenta en una solicitud a Blob Storage. Para más información, consulte Descripción de cómo no permitir la clave compartida afecta a los tokens de SAS.

SAS de delegación de usuarios

Una SAS de delegación de usuarios se protege con credenciales de Microsoft Entra y también con los permisos especificados para la SAS.

Llamar a la Copy Blob operación mediante un token de SAS delegado en un recurso de blob requiere el siguiente permiso como parte del token de SAS de delegación de usuarios.

Operación	Tipo de objeto	Permiso firmado
Copia de blobs	Blob de destino (nuevo)	Crear (c) o escribir (w)
Copia de blobs	Blob de destino (existente)	Escritura (w)
Copia de blobs	Blob de origen (dentro de la misma cuenta de almacenamiento)	Lectura (r)
Copia de blobs	Blob de origen (en una cuenta de almacenamiento diferente)	Lectura (r)

Para más información sobre la SAS de delegación de usuarios, consulte Creación de una SAS de delegación de usuarios.

SAS de servicio

Una SAS de servicio está protegida con la clave de cuenta de almacenamiento. Una SAS de servicio delega el acceso a un recurso en un único servicio de Azure Storage, como Blob Storage.

Llamar a la Copy Blob operación mediante un token de SAS delegado en un recurso de blob requiere el siguiente permiso como parte del token de SAS de servicio.

Operación	Tipo de objeto	Permiso firmado
Copia de blobs	Blob de destino (nuevo)	Crear (c) o escribir (w)
Copia de blobs	Blob de destino (existente)	Escritura (w)
Copia de blobs	Blob de origen (dentro de la misma cuenta de almacenamiento)	Lectura (r)
Copia de blobs	Blob de origen (en una cuenta de almacenamiento diferente)	Lectura (r)

Para más información sobre la SAS de servicio, consulte Creación de una SAS de servicio.

SAS de cuenta

Una SAS de cuenta está protegida con la clave de cuenta de almacenamiento. SAS de cuenta delega el acceso a los recursos en uno o varios de los servicios de almacenamiento. Todas las operaciones disponibles con una SAS de servicio o delegación de usuarios están también disponibles con una SAS de cuenta.

En la tabla siguiente se indica el tipo de recurso firmado y los permisos firmados que se deben especificar al delegar el acceso:

Operación	Tipo de objeto	Servicio firmado	Tipo de recurso firmado	Permiso firmado
Copia de blobs	Blob de destino (nuevo)	Blob (b)	Objeto (o)	Crear (c) o escribir (w)
Copia de blobs	Blob de destino (existente)	Blob (b)	Objeto (o)	Escritura (w)
Copia de blobs	Blob de origen (dentro de la misma cuenta de almacenamiento)	Blob (b)	Objeto (o)	Lectura (r)
Copia de blobs	Blob de origen (en una cuenta de almacenamiento diferente)	Blob (b)	Objeto (o)	Lectura (r)

Para más información sobre la SAS de la cuenta, consulte Creación de una SAS de cuenta.

Comentarios

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 identificador de copia que puede usar 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 de la mejor manera posible. Blob service copia los blobs cuando otras tareas no usan los recursos del servidor, 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 que el blob de origen. Si existe un blob de destino, se sobrescribirá. No se puede modificar el blob de destino mientras una operación de copia está 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 en Azure Files. 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 pendiente Copy Blob . En otras palabras, un blob no puede ser el destino de varias operaciones pendientes Copy Blob . Se produce un error al intentar copiar un blob en un blob de destino que ya tiene una operación de copia pendiente con el código de estado 409 (conflicto).

Solo las cuentas de almacenamiento creadas el 7 de junio de 2012 o después, permiten que la Copy Blob operación se copie desde otra cuenta de almacenamiento. Se produce un error al intentar copiar de otra cuenta de almacenamiento en una cuenta creada antes del 7 de junio de 2012 con el código de estado 400 (solicitud incorrecta).

La Copy Blob operación siempre copia todo el blob o archivo de origen. ya que no se admite la copia de un intervalo de bytes o un conjunto 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 que tenga un nombre diferente. El blob de destino puede ser un blob existente del mismo tipo de blob (bloque, anexar 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 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 en 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, 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, 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 a Get Blob o Get 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, los cambios realizados en el origen mientras la operación de copia está en curso harán que se produzca un error en esa operación. Se producirá un error al intentar cambiar el blob de destino mientras una copia está 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 se debe pasar a Copy Blob. Las concesiones de duración finita no se permiten.

El ETag valor de un blob en bloques cambia cuando se inicia la Copy Blob operación y cuando finaliza la operación. El ETag valor de un blob en páginas cambia cuando se inicia la Copy Blob operación y continúa modificando 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 blob

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 bloques confirmada del blob de origen también se copia en el blob de destino, si el blob es un blob en bloques. No se copiarán los bloques sin confirmar.

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 para el 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 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, 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, use 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 alquilado

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. 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 que especifique es una concesión de duración finita activa, 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, independientemente de si va a copiar en un blob de destino que tiene un nombre diferente del origen, copiar en un blob de destino que tenga el mismo nombre que el origen o promover 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. Para 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 se sobrescribe un blob de destino 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 a través de su blob base, siempre y cuando 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 se conserva, pero el destino se sobrescribe con una copia que se puede leer y escribir.

Copia de versiones de blobs

Puede realizar una operación de copia para promover una versión a través de su blob base, siempre y cuando 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 permanece, 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 y cuando 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 el blob de origen se está rehidratando.

Para obtener información detallada sobre la organización por niveles en el nivel de blob en bloques, consulte Niveles de almacenamiento de acceso 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 siguiente paso en función del código de estado devuelto:

status code	Significado
202 (Aceptado), x-ms-copy-status: success	La operación de copia finalizó correctamente.
202 (Aceptado), x-ms-copy-status: pending	La operación de copia no ha finalizado. Sondee el blob de destino mediante `Get Blob Properties` para examinar el `x-ms-copy-status` encabezado hasta que finalice o se produzca un error en la operación.
4xx, 500 o 503	Error en la operación de 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 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 failed resultado, el x-ms-copy-status-description encabezado contiene una cadena de detalles de error.

Una operación pendiente Copy Blob tiene un tiempo de espera de dos semanas. Intento de copia que no ha terminado después de dos semanas de espera y deja un blob vacío con el x-ms-copy-status campo establecido failed en 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 pueden impedir el progreso de la operación, pero no provocar que se produzca un error. En estos casos, x-ms-copy-status-description describe los errores intermitentes.

Cualquier intento de modificar o instantánear el 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 a para volver a Copy Blob intentar la operación de copia.

Si la Copy Blob operación finaliza de forma sincrónica, use la tabla siguiente para determinar el estado de la operación de copia:

status code	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, al sobrescribir el blob de destino se heredará el nivel frecuente o esporádico del destino si x-ms-access-tier no se proporciona. Se producirá un error al sobrescribir un blob archivado. Para obtener información detallada sobre la organización por niveles en el nivel de blob en bloques, consulte Niveles de almacenamiento de acceso 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 Copy Blob las solicitudes basadas en el tipo de cuenta de almacenamiento:

Operación	Tipo de cuenta de almacenamiento	Categoría de facturación
Copiar blob (cuenta^{de destino 1})	Blobs en bloques Premium De uso general, estándar, v2 De uso general, estándar, v1	Operaciones de escritura
Copiar blob (cuenta^{de origen 2})	Blobs en bloques Premium De uso general, estándar, v2 De uso general, estándar, v1	Lee operaciones.

¹La cuenta de destino se cobra por una transacción para iniciar la escritura.
²Cuando el objeto de origen está en otra cuenta, la cuenta de origen incurre en una transacción para 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 Azure Blob Storage.

La cuenta de destino también incurre en costos de transacción para cada solicitud para cancelar la operación de copia (consulte Abort Copy Blob) o para comprobar el estado de la operación de copia (consulte Get Blob or Get Blob Properties).

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 usa para transferir la solicitud se cobra a la cuenta de almacenamiento de origen como salida. Las salidas entre cuentas de la misma región son gratuitas.

Al copiar un blob de origen en un blob de destino que tiene un nombre diferente dentro de la misma cuenta, se usan recursos de almacenamiento adicionales para el nuevo blob. A continuación, la operación de copia genera un cargo por el uso de 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, al promover 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.

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 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 ni páginas, incluso si son idénticos. Para más información sobre los escenarios de costos de instantáneas, consulte Descripción de cómo acumulan las instantáneas los cargos.

Consulte también

Autorización de solicitudes a Azure Storage
Estado y códigos de error
Códigos de error de Blob Storage
Descripción de cómo acumulan las instantáneas los cargos
Abort Copy Blob