VENTAS: 1-800-867-1389

Copy Blob

Actualizado: octubre de 2014

La operación Copy Blob copia un blob en un destino en la cuenta de almacenamiento. En la versión 2012-02-12 y versiones más recientes, el origen para una operación Copy Blob puede ser un blob confirmado en cualquier cuenta de almacenamiento de Azure.

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

La solicitud Copy Blob se puede construir como sigue. Se recomienda HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento, mycontainer por el nombre del contenedor y myblob por el nombre del blob de destino. A partir de la versión 2013-08-15, puede especificar una firma de acceso compartido para el blob de destino.

 

  URI de solicitud del método PUT Versión de HTTP

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

HTTP/1.1

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

 

  URI de solicitud del método PUT Versión de HTTP

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

HTTP/1.1

Para obtener más información, vea Uso del emulador de almacenamiento de Azure para desarrollo y prueba.

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

 

Parámetro Descripción

timeout

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

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

 

Encabezado de solicitud Descripción

Authorization

Requerido. Especifica el esquema de autenticación, el nombre de la cuenta y la firma. Para obtener más información, vea Autenticación para los servicios de almacenamiento de Azure.

Date O bien x-ms-date

Requerido. Especifica la hora universal coordinada (UTC) para la solicitud. Para obtener más información, vea Autenticación para los servicios de almacenamiento de Azure.

x-ms-version

Obligatorio para todas las solicitudes autenticadas. Para obtener más información, vea Control de versiones de los servicios de almacenamiento de Azure.

x-ms-meta-name:value

Opcional. Especifica un par nombre-valor definido por el usuario asociado al blob. Si no se especifica ningún par nombre-valor, la operación copiará los metadatos del blob de origen en el blob de destino. Si se especifica uno o varios pares nombre-valor, el blob de destino se crea con los metadatos especificados, y los metadatos no se copian del blob de origen.

Tenga en cuenta que, a partir de la versión 2009-09-19, los nombres de los metadatos deben cumplir las reglas de nomenclatura para los Identificadores de C#. Vea Asignar nombres y hacer referencia a contenedores, blobs y metadatos para obtener más información.

x-ms-source-if-modified-since

Opcional. Valor DateTime. Especifique este encabezado condicional para copiar el blob solo si el blob de origen se ha modificado desde la fecha u hora especificadas. Si el blob de origen no se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

x-ms-source-if-unmodified-since

Opcional. Valor DateTime. Especifique este encabezado condicional para copiar el blob solo si el blob de origen no se ha modificado desde la fecha u hora especificadas. Si el blob de origen se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

x-ms-source-if-match

Opcional. Valor ETag. Especifique este encabezado condicional para copiar el blob de origen solo si la ETag coincide con el valor especificado. Si los valores de la ETag no coinciden, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

x-ms-source-if-none-match

Opcional. Valor ETag. Especifique este encabezado condicional para copiar el blob de origen solo si la ETag no coincide con el valor especificado. Si los valores son idénticos, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

If-Modified-Since

Opcional. Valor DateTime. Especifique este encabezado condicional para copiar el blob solo si el blob de destino se ha modificado desde la fecha u hora especificadas. Si el blob de destino no se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

If-Unmodified-Since

Opcional. Valor DateTime. Especifique este encabezado condicional para copiar el blob solo si el blob de destino no se ha modificado desde la fecha u hora especificadas. Si el blob de destino se ha modificado, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

If-Match

Opcional. Valor ETag. Especifique un valor ETag para este encabezado condicional para copiar el blob solo si el valor ETag especificado coincide con el valor ETag para un blob de destino existente. Si la ETag del blob de destino no coincide con la ETag especificada para If-Match, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

If-None-Match

Opcional. Valor ETag, o el carácter comodín (*).

Especifique un valor ETag para este encabezado condicional para copiar el blob solo si el valor ETag especificado no coincide con el del blob de destino.

Especifique el carácter comodín (*) para realizar la operación solo si no existe el blob de destino.

Si no se cumple la condición especificada, el servicio Blob devuelve el código de estado 412 (Error de condición previa).

x-ms-copy-source:name

Requerido. Especifica el nombre del blob de origen.

En la versión 2012-02-12 y versiones más recientes, este valor es una dirección URL con una longitud máxima de 2 KB que especifica un blob. El valor debe estar codificado para URL tal y como aparecería en un URI de solicitud. Un blob de origen de la misma cuenta puede ser privado, pero un blob de otra cuenta debe ser público o aceptar las credenciales incluidas en esta dirección URL, como una firma de acceso compartido. Las cuentas de almacenamiento creadas desde el 7 de junio de 2012 son las únicas que permiten que la operación Copy Blob copie desde otra cuenta de almacenamiento. Microsoft recomienda el uso de HTTPS siempre que sea posible. Ejemplos:

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

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

En las versiones anteriores a 2012-02-12, los blobs solo se pueden copiar en la misma cuenta, y un nombre de origen puede utilizar estos formatos:

  • Blob en contenedor con nombre: /accountName/containerName/blobName

  • Instantánea en contenedor con nombre: /accountName/containerName/blobName?snapshot=<DateTime>

  • Blob en contenedor raíz: /accountName/blobName

  • Instantánea en contenedor raíz: /accountName/blobName?snapshot=<DateTime>

x-ms-lease-id:<ID>

Obligatorio si el blob de destino tiene una concesión activa. El identificador de concesión especificado para este encabezado debe coincidir con el identificador de concesión del blob de destino. Si la solicitud no incluye el identificador de concesión o este no es válido, la operación produce un error con el código de estado 412 (Error de condición previa).

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

En la versión 2012-02-12 y versiones más recientes, este valor debe especificar una concesión activa e infinita para un blob en concesión. Un identificador de concesión de duración finita produce un error con el código de estado 412 (Error de condición previa).

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

Opcional, versiones anteriores a 2012-02-12 (no admitido en la versión 2012-02-12 y versiones más recientes). Especifique este encabezado para realizar la operación Copy Blob solo si el identificador de concesión proporcionado coincide con el identificador de concesión activa del blob de origen.

Si se especifica este encabezado y el blob de origen no tiene actualmente una concesión activa, la operación también producirá un error con el código de estado 412 (Error de condición previa).

x-ms-client-request-id

Opcional. Proporciona un valor opaco generado por el cliente con un límite de caracteres de 1 KB que se graba en los registros de análisis cuando el registro de análisis de almacenamiento está habilitado. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes recibidas por el servidor. Para obtener más información, vea Acerca del registro del análisis de almacenamiento y Registro de Azure: usar registros para realizar el seguimiento de las solicitudes de almacenamiento.

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

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

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

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

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 cumplen la especificación del protocolo HTTP/1.1.

 

Encabezado de respuesta Descripción

ETag

En la versión 2012-02-12 y versiones más recientes, si se completa la copia, contiene la ETag del blob de destino. Si la copia no se completa, contiene la ETag del blob vacío creado al inicio de la copia.

En las versiones anteriores a 2012-02-12, devuelve la ETag para el blob de destino.

En la versión 2011-08-18 y versiones más recientes, el valor ETag estará entre comillas.

Last-Modified

Devuelve la fecha y la hora en la que se completó la operación de copia en el blob de destino.

x-ms-request-id

Este encabezado identifica de forma única la solicitud que se realizó y se puede utilizar para solucionar problemas relacionados con esta. Para obtener más información, vea Solucionar problemas relacionados con las operaciones de la API.

x-ms-version

Indica la versión del servicio Blob utilizado para ejecutar la solicitud. Este encabezado se devuelve para las solicitudes realizadas en la versión 2009-09-19 y versiones posteriores.

Date

Valor de fecha y hora UTC generado por el servicio que indica la hora a la que se inició la respuesta.

x-ms-copy-id: <id>

Versión 2012-02-12 y versiones más recientes. Identificador de cadena para esta operación de copia. Utilícelo con Get Blob o Get Blob Properties para comprobar el estado de esta operación de copia, o páselo a Abort Copy Blob para anular una copia pendiente.

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

Versión 2012-02-12 y versiones más recientes. Estado de la operación de copia, con estos valores:

  • success: se completó correctamente la copia.

  • pending: la copia está en curso.

La siguiente es una respuesta de ejemplo para una solicitud de copia de un blob:

Response Status:
HTTP/1.1 202 Accepted

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

El propietario de la cuenta puede llamar a esta operación. Para las solicitudes realizadas en la versión 2013-08-15 y posteriores, se admite una firma de acceso compartido que tiene permiso para escribir en el blob de destino o en su contenedor para las operaciones de copia dentro de la misma cuenta. Tenga en cuenta que la firma de acceso compartido especificada en la solicitud solo se aplica al blob de destino. El acceso al blob de origen se autoriza por separado, como se describe en los detalles del encabezado de solicitud x-ms-copy-source.

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

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

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

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

La operación Copy Blob copia siempre el blob de origen completo; no se admite la copia de un intervalo de bytes ni de 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 con un nombre diferente. El blob de destino puede ser un blob existente del mismo tipo (en bloques o en páginas), o puede ser un nuevo blob creado por la operación de copia.

  • Puede copiar un blob de origen en un blob de destino con el mismo nombre, reemplazando de esta manera el blob de origen. Este tipo de operación de copia quita los bloques sin confirmar y sobrescribe los metadatos del blob.

  • Puede copiar una instantánea sobre su blob base. Si se mueve una instantánea a la posición del blob, puede restaurar una versión anterior de un blob.

  • Puede copiar una instantánea en un blob de destino con un nombre diferente. El blob resultante de destino es un blob que se puede escribir y no una instantánea.

Al copiar desde un blob en páginas, el servicio Blob crea un blob en páginas de destino con la misma longitud que el blob de origen, y cuyo contenido inicial es todo ceros. A continuación, los intervalos de páginas de origen se enumeran, y se copian los intervalos no vacíos. Al copiar desde un blob en bloques, se copiarán todos los bloques confirmados y sus identificadores de bloque. No se copiarán los bloques sin confirmar. Para un blob en bloques, el servicio Blob crea un blob confirmado de longitud cero antes de volver de esta operación. En cualquier tipo de blob, 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 se complete la copia.

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

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

Copiar las propiedades y los metadatos del blob

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

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

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

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

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

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

Copiar un blob sujeto a una concesión

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

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

Copiar instantáneas

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

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

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

La operación Copy Blob completa la copia de forma asincrónica. Utilice la tabla siguiente para determinar el siguiente paso basándose en el código de estado devuelto por Copy Blob:

 

Código de estado Significado

202 (Aceptado), x-ms-copy-status: success

La copia se realizó correctamente.

202 (Aceptado), x-ms-copy-status: pending

500 ó 503

La copia no se ha completado. Sondee el blob de destino mediante Get Blob Properties para examinar el encabezado x-ms-copy-status hasta que la copia se complete o produzca un error.

4xx, 500 o 503

Se ha producido un error en la copia.

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

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

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

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

Facturación

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

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

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

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

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2015 Microsoft