Copia de blobs
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 Azure Storage.
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 Copy Blob solicitud como se indica a continuación. 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 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 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 la 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 |
Obligatorio 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 de 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 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. Se admite en 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 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 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 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 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 ser la dirección URL codificada 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 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 de 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 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 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 una cuenta diferente. 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 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?sastokenEn 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 admitidas 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. Los niveles de blobs en bloques se admiten en Blob Storage o en cuentas de De uso general v2. Los valores válidos son Hot, CoolCold y Archive.
Nota:Cold el nivel es compatible con la versión 2021-12-02 y posteriores. Para obtener información detallada sobre los niveles de blobs 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. Puede establecer la prioridad en un blob una sola 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 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. 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, 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 posteriores, si la copia está completa, este encabezado contiene el ETag valor del blob de destino. Si la copia no se 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 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 pase 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 las 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 tiene como máximo 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
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 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 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 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 en 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 .
Importante
Microsoft recomienda usar Microsoft Entra ID con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso 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. 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 muestra la acción de RBAC necesaria para que un usuario, grupo, identidad administrada o entidad de servicio Microsoft Entra llame a la Copy Blob operación y el rol RBAC integrado con privilegios mínimos que incluya esta acción:
Blob de destino
- Acción 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 Blob de Storage
Para más información sobre cómo asignar roles mediante RBAC de Azure, consulte Asignación de un rol de Azure para el acceso a datos de blobs.
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 blobs de la mejor manera posible. Blob service copia blobs cuando otras tareas no usan recursos de servidor, por lo que no se garantiza que una copia se inicie inmediatamente o 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 pendiente una operación de copia 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 desde otra cuenta de almacenamiento a 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 recuento de bloques confirmado 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 Get Blob a 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, 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 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 cambiando con frecuencia durante la operación de copia. El contenido de un blob en bloques es visible a través de un Get comando solo una vez finalizada la operación de copia completa.
Copia de propiedades, etiquetas y metadatos de blob
Cuando se copia un blob, se copian las siguientes propiedades del sistema en el blob de destino que tienen los mismos valores:
Content-TypeContent-EncodingContent-LanguageContent-LengthCache-ControlContent-MD5Content-Dispositionx-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 codificarse 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 concedido
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, esta llamada produce un error con un código de estado 412 (error en la 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 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 esta manera, 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 esta manera, 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 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 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 paso siguiente 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. Un intento de copia que no ha finalizado 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 podrían impedir el progreso de la operación, pero no provocar que se produjera 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, la sobrescritura del blob de destino heredará el nivel de acceso 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 se pueden originar en clientes que usan las API de Blob Storage, ya sea directamente a través de la API rest de Blob Storage o de 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 que 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 (cuentade destino 1) | Blobs en bloques Premium De uso general, estándar, v2 De uso general, estándar, v1 |
Operaciones de escritura |
| Copiar blob (cuentade origen 2) | Blobs en bloques Premium De uso general, estándar, v2 De uso general, estándar, v1 |
Lee operaciones. |
1La cuenta de destino se cobra por una transacción para iniciar la escritura.
2Cuando el objeto de origen está en una cuenta diferente, la cuenta de origen incurre en una transacción para cada solicitud de lectura en el 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 se 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, excepto 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 conlleva 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, aunque sean idénticos. Para más información sobre los escenarios de costo 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