Exportar (0) Imprimir
Expandir Tudo

Copiar Blob

Atualizado: novembro de 2013

A operação Copy Blob copia um blob em um destino na conta de armazenamento. Na versão 2012-02-12 e mais recentes, a origem para uma operação Copy Blob pode ser um blob confirmado em qualquer conta de armazenamento do Azure.

noteObservação
Apenas as contas de armazenamento criadas a partir de 7 de junho de 2012 permitem que a operação Copy Blob faça cópias de outra conta de armazenamento.

A solicitação Copy Blob pode ser criada da seguinte maneira. HTTPS é recomendado. Substitua myaccount pelo nome da sua conta de armazenamento, mycontainer pelo nome do seu contêiner e myblob pelo nome do seu blob de destino. A partir da versão 2013-08-15, você pode especificar uma assinatura de acesso compartilhado para o blob de destino.

 

  URI de solicitação do método PUT Versão de HTTP

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

HTTP/1.1

Ao fazer uma solicitação no serviço de armazenamento emulado, especifique o nome de host do emulador e a porta do serviço Blob como 127.0.0.1:10000, seguido pelo nome da conta de armazenamento emulado:

 

  URI de solicitação do método PUT Versão de HTTP

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

HTTP/1.1

Para obter mais informações, consulte Uso do Azure Storage Emulator para desenvolvimento e testes.

Os seguintes parâmetros adicionais podem ser especificados no URI de solicitação.

 

Parâmetro Descrição

timeout

Opcional. O parâmetro timeout é expresso em segundos. Para obter mais informações, consulte Definição de tempos limite para operações de serviço Blob.

A tabela a seguir descreve os cabeçalhos de solicitação obrigatórios e opcionais.

 

Cabeçalho de solicitação Descrição

Authorization

Obrigatória. Especifica o esquema de autenticação, o nome da conta e a assinatura. Para obter mais informações, consulte Autenticação federada para os Serviços de Armazenamento do Azure.

Date ou x-ms-date

Obrigatória. Especifica o Tempo Universal Coordenado (UTC) para a solicitação. Para obter mais informações, consulte Autenticação federada para os Serviços de Armazenamento do Azure.

x-ms-version

Obrigatório para todas as solicitações autenticadas. Para obter mais informações, consulte Controle de versão para os Serviços de Armazenamento do Azure.

x-ms-meta-name:value

Opcional. Especifica um par de nome-valor definido pelo usuário associado ao blob. Se nenhum par de nome-valor for especificado, a operação copiará os metadados do blob de origem no blob de destino. Se um ou mais pares de nome-valor forem especificados, o blob de destino será criado com os metadados especificados, e os metadados não serão copiados do blob de origem.

Observe que, a partir da versão 2009-09-19, os nomes de metadados devem atender às regras de nomenclatura para identificadores C#. Consulte Nomeando e referenciando contêineres, blobs e metadados para obter mais informações.

x-ms-source-if-modified-since

Opcional. Um valor DateTime. Especifique esse cabeçalho condicional para copiar o blob somente se o blob de origem tiver sido modificado desde a data/hora especificada. Se o blob de origem não tiver sido modificado, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

x-ms-source-if-unmodified-since

Opcional. Um valor DateTime. Especifique esse cabeçalho condicional para copiar o blob somente se o blob de origem não tiver sido modificado desde a data/hora especificada. Se o blob de origem tiver sido modificado, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

x-ms-source-if-match

Opcional. Um valor de ETag. Especifique esse cabeçalho condicional para copiar o blob de origem somente se a ETag corresponder ao valor especificado. Se os valores de ETag não coincidirem, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

x-ms-source-if-none-match

Opcional. Um valor de ETag. Especifique esse cabeçalho condicional para copiar o blob de origem somente se a ETag não corresponder ao valor especificado. Se os valores forem idênticos, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

If-Modified-Since

Opcional. Um valor DateTime. Especifique esse cabeçalho condicional para copiar o blob somente se o blob de destino tiver sido modificado desde a data/hora especificada. Se o blob de destino não tiver sido modificado, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

If-Unmodified-Since

Opcional. Um valor DateTime. Especifique esse cabeçalho condicional para copiar o blob somente se o blob de destino não tiver sido modificado desde a data/hora especificada. Se o blob de destino tiver sido modificado, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

If-Match

Opcional. Um valor de ETag. Especifique um valor ETag para esse cabeçalho condicional copiar o blob somente se o valor ETag especificado corresponder ao valor ETag de um blob de destino existente. Se o ETag do BLOB de destino não corresponde ao ETag especificado para If-Match, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

If-None-Match

Opcional. Um valor de ETag ou o caractere curinga (*).

Especifique um valor ETag para esse cabeçalho condicional copiar o blob somente se o valor ETag especificado não corresponder ao valor ETag do blob de destino.

Especifique o caractere curinga (*) para executar a operação somente se o blob de destino não existir.

Se a condição especificada não for atendida, o serviço Blob retornará o código de status 412 (Falha na Pré-condição).

x-ms-copy-source:name

Obrigatória. Especifica o nome do blob de origem.

Na versão 2012-02-12 e mais recente, esse valor é uma URL de até 2 KB de comprimento que especifica um blob. Um blob de origem na mesma conta pode ser particular, mas um blob em outra conta deve ser público ou aceitar as credenciais inclusas nessa URL, como uma assinatura de acesso compartilhado. Apenas as contas de armazenamento criadas a partir de 7 de junho de 2012 permitem que a operação Copy Blob faça cópias de outra conta de armazenamento. A Microsoft recomenda o uso de HTTPS quando possível. Exemplos:

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

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

Nas versões anteriores à 2012-02-12, os blobs só podem ser copiados na mesma conta, e um nome de origem pode usar estes formatos:

  • Blob em contêiner nomeado: /accountName/containerName/blobName

  • Instantâneo em contêiner nomeado: /accountName/containerName/blobName?snapshot=<DateTime>

  • Blob em contêiner raiz: /accountName/blobName

  • Instantâneo em contêiner raiz: /accountName/blobName?snapshot=<DateTime>

x-ms-lease-id:<ID>

Obrigatório se o blob de destino tiver uma concessão ativa. A ID da concessão especificada para esse cabeçalho deve corresponder à ID de concessão do blob de destino. Se a solicitação não incluir a ID de concessão ou não for válida, a operação falhará com o código de status 412 (Falha na Pré-condição).

Se esse cabeçalho for especificado e o blob de destino não tiver nenhuma concessão ativa, a operação também falhará com o código de status 412 (Falha na Pré-condição).

Na versão 2012-02-12 e mais recente, esse valor deve especificar uma concessão ativa, infinita para um blob concedido. Uma ID de concessão de duração finita falha com 412 (Falha na Pré-condição).

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

Opcional, versões anteriores à 2012-02-12 (sem suporte na 2012-02-12 e mais recente). Especifique esse cabeçalho para executar a operação Copy Blob somente se a ID de concessão especificada corresponder à ID de concessão ativa do blob de origem.

Se esse cabeçalho for especificado e o blob de origem não tiver nenhuma concessão ativa, a operação também falhará com o código de status 412 (Falha na Pré-condição).

x-ms-client-request-id

Opcional. Fornece um valor opaco, gerado pelo cliente, com um limite de caracteres de 1 KB que é registrado nos logs de análise quando o log de análise de armazenamento está habilitado. É altamente recomendável usar esse cabeçalho para correlacionar atividades do cliente com solicitações recebidas pelo servidor. Para obter mais informações, consulte Sobre o registro em log da Análise de Armazenamento e Log do Windows Azure: Usando logs para rastrear solicitações de armazenamento.

A resposta inclui um código de status HTTP e um conjunto de cabeçalhos de resposta.

Na versão 2012-02-12 e mais recente, uma operação bem-sucedida retorna um código de status 202 (Aceito).

Nas versões anteriores à 2012-02-12, uma operação bem-sucedida retorna um código de status 201 (Criado.

Para obter informações sobre códigos de status, consulte Status e códigos de erro.

A resposta para esta operação inclui os cabeçalhos a seguir. A resposta também pode incluir cabeçalhos padrão HTTP adicionais. Todos os cabeçalhos padrão obedecem à especificação de protocolo HTTP/1.1.

 

Cabeçalho de resposta Descrição

ETag

Na versão 2012-02-12 e mais recente, se a cópia estiver concluída, contém o ETag do blob de destino. Se a cópia não estiver concluída, contém o ETag do blob vazio criado no início da cópia.

Nas versões anteriores à 2012-02-12, retorna o ETag do blob de destino.

Na versão 2011-08-18 e mais recente, o valor de ETag estará entre aspas.

Last-Modified

Retorna a data/hora em que a operação de cópia para o blob de destino foi concluída.

x-ms-request-id

Esse cabeçalho identifica a solicitação que foi feita de forma exclusiva e pode ser usado para solucionar problemas na solicitação. Para obter mais informações, consulte Solucionando problemas de operações de API.

x-ms-version

Indica a versão do serviço Blob usado para executar a solicitação. Esse cabeçalho é retornado para solicitações feitas na versão 2009-09-19 e mais recente.

Date

Um valor de data/hora UTC gerado pelo serviço que indica a hora em que a resposta foi iniciada.

x-ms-copy-id: <id>

Versão 2012-02-12 e mais recente. Identificador de cadeia de caracteres para essa operação de cópia. Use com Get Blob ou Get Blob Properties para verificar o status dessa operação de cópia ou passe para Abort Copy Blob para anular uma cópia pendente.

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

Versão 2012-02-12 e mais recente. O estado da operação de cópia, com estes valores:

  • success: a cópia foi concluída com êxito.

  • pending: a cópia está em andamento.

Veja a seguir uma resposta de exemplo de uma solicitação para copiar um 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

Essa operação pode ser chamada pelo proprietário da conta. Para solicitações feitas em relação à versão 2013-08-15 e posterior, uma assinatura de acesso compartilhado que tenha permissão para gravar no blob de destino ou no contêiner tem suporte para operações de cópia na mesma conta. Observe que a assinatura de acesso compartilhado especificada na solicitação aplica-se apenas ao blob de destino. O acesso ao blob de origem é autorizado separadamente, como descrito em detalhes para o cabeçalho de solicitação x-ms-copy-source.

Na versão 2012-02-12 e mais recente, a operação Copy Blob pode ser executada de forma assíncrona. Essa operação retorna a ID da cópia que você pode usar para verificar ou anular a operação de cópia. O serviço Blob copia blobs em uma base do melhor esforço.

O blob de origem para uma operação de cópia pode ser um blob de blocos ou um blob de páginas, ou um instantâneo de um dos dois. Se o blob de destino já existir, ele deverá ser do mesmo tipo do blob de origem. Qualquer blob de destino existente será substituído. O blob de destino não pode ser modificado quando uma operação de cópia está em andamento.

Várias operações Copy Blob pendentes em uma conta podem ser processadas em sequência. Um blob de destino pode ter apenas uma operação pendente de blob de cópia. Em outras palavras, um blob não pode ser o destino de várias operações Copy Blob pendentes. Uma tentativa de Copy Blob para um blob de destino que já tenha uma cópia pendente falhará com o código de status 409 (Conflito).

Apenas as contas de armazenamento criadas a partir de 7 de junho de 2012 permitem que a operação Copy Blob faça cópias de outra conta de armazenamento. Uma tentativa de copiar de outra conta de armazenamento para uma conta criada antes de 7 de junho de 2012 falhará com o código de status 400 (Solicitação Incorreta).

A operação Copy Blob sempre copia o blob de origem inteiro; não há suporte à cópia de um intervalo de bytes ou o conjunto de blocos.

Uma operação Copy Blob pode ter algumas destas formas:

  • É possível copiar um blob de origem em um blob de destino com outro nome. O blob de destino pode ser um blob existente do mesmo tipo de blob (blocos ou páginas), ou pode ser um novo blob criado pela operação de cópia.

  • Você pode copiar um blob de origem para um blob de destino com o mesmo nome, substituindo efetivamente o blob de origem. Essa operação de cópia remove todos os blocos não confirmadas e substitui os metadados de blob.

  • É possível copiar um instantâneo sobre seu blob básico. Com a promoção de um instantâneo para a posição do blob básico, você pode restaurar uma versão anterior de um blob.

  • É possível copiar um instantâneo em um blob de destino com outro nome. O blob de destino resultante é um blob gravável e não um instantâneo.

Ao copiar de um blob de páginas, o serviço Blob cria um blob de páginas de destino do comprimento do blob de origem, inicialmente contendo todos os zeros. Os intervalos de páginas de origem são enumerados em seguida e os intervalos não vazios são copiados. Ao copiar de um blob de blocos, todos os blocos confirmados e suas IDs de bloco serão copiados. Os blocos não confirmados não serão copiados. Para um blob de blocos, o serviço Blob cria um blob confirmado de comprimento zero antes de retornar dessa operação. Para qualquer tipo de blob, você pode chamar Get Blob ou Get Blob Properties no blob de destino para verificar o status da operação de cópia. O blob final será confirmado quando a cópia for concluída.

Quando a origem de uma operação de cópia fornece ETags, se houver qualquer alteração na origem com a cópia em andamento, a cópia falhará. Uma tentativa de alterar o blob de destino quando uma cópia está em andamento falhará com o Conflito 409. Se o blob de destino tiver uma concessão infinita, a ID da concessão deverá ser passada para Copy Blob. As concessões de duração finita não são permitidas.

O ETag de um blob de blocos é alterado quando a operação Copy Blob é iniciada e quando a cópia termina. O ETag de um blob de páginas é alterado quando a operação Copy Blob é iniciada e continua sendo alterada frequentemente durante a cópia. O conteúdo de um blob de blocos é visível apenas com o uso de GET após a conclusão da cópia.

Copiando propriedades e metadados de blob

Quando um blob é copiado, as propriedades do sistema a seguir são copiadas no blob de destino com os mesmos valores:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

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

A lista de blocos confirmados do blob de origem também será copiada no blob de destino, se o blob for de blocos. Nenhum bloco não confirmado é copiado.

O blob de destino é sempre do mesmo tamanho do blob de origem, para que o valor do cabeçalho Content-Length do blob de destino corresponda ao do blob de origem.

Quando o blob de origem e o blob de destino forem iguais, Copy Blob removerá todos os blocos não confirmados. Se os metadados forem especificados nesse caso, os metadados existentes serão substituídos por novos metadados.

Cópia de um blob concedido

A operação Copy Blob lê apenas do blob de origem para que o estado de concessão do blob de origem não seja importante. Entretanto, a operação Copy Blob salva o ETag de blob de origem quando a cópia é iniciada. Se o valor de ETag for alterado antes da conclusão da cópia, a cópia falhará. Você pode evitar alterações no blob de origem concedendo-o durante a operação de cópia.

Se o blob de destino tiver uma concessão infinita ativa, você deverá especificar sua ID de concessão na chamada para a operação Copy Blob. Se a concessão especificada for uma concessão de duração finita, essa chamada falhará com o código de status 412 (Falha na Pré-condição). Quando a cópia estiver pendente, qualquer operação de concessão no blob de destino falhará com o código de status 409 (Conflito). A concessão infinita no blob de destino é bloqueada dessa forma durante a operação de cópia, quer você esteja copiando um blob de destino com um nome diferente da origem, copiando em um blob de destino com o mesmo nome da origem ou promovendo um instantâneo sobre o blob de base. Se o cliente especificar um ID de concessão em um blob que ainda não existir, o serviço Blob retornará o código de status 412 (falha na pré-condição) para solicitações feitas na versão 2013-08-15 e posterior; para versões anteriores, o serviço Blob retornará o código de status 201 (criado).

Copiando instantâneos

Quando um blob de origem é copiado, todos os instantâneos do blob de origem não são copiados no destino. Quando um blob de destino é substituído por uma cópia, todos os instantâneos associados ao blob de destino permanecem intactos sob o seu nome.

Você pode executar uma operação de cópia para promover um blob de instantâneo sobre seu blob de base. Dessa forma, você pode restaurar uma versão anterior de um blob. O instantâneo permanece, mas seu destino é substituído por uma cópia que pode ser lida e gravada.

Trabalho com uma cópia pendente (versão 2012-02-12 e mais novas)

A operação Copy Blob conclui a cópia de modo assíncrono. Use a tabela a seguir para determinar a próxima etapa com base no código de status retornado por Copy Blob:

 

Código de status Significado

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

Cópia concluída com êxito.

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

500 ou 503

A cópia não foi concluída. Sondar o blob de destino usando Get Blob Properties para examinar o x-ms-copy-status até a cópia ser concluída ou falhar.

4xx, 500 ou 503

Falha na cópia.

Durante e após uma operação Copy Blob, as propriedades do blob de destino contêm a ID da cópia da operação Copy Blob e a URL do blob de origem. Quando a cópia é concluída, o serviço Blob grava o valor de hora e de resultado (success, failed, ou aborted) nas propriedades do blob de destino. Se a operação failed, o cabeçalho x-ms-copy-status-description conterá uma cadeia de caracteres de detalhe de erro.

Uma operação Copy Blob pendente tem um tempo limite de 2 semanas. Uma tentativa de cópia que não foi concluída depois de 2 semanas atinge o tempo limite e deixa um blob vazio com o campo x-ms-copy-status definido como failed e x-ms-copy-status-description definido como 500 (OperationCancelled). Erros intermitentes e não fatais que podem ocorrer durante uma cópia podem impedir o andamento da cópia, mas não causarão sua falha. Nesses casos, x-ms-copy-status-description descreve os erros intermitentes.

Qualquer tentativa de modificar ou obter um instantâneo do blob de destino durante a cópia falhará com 409 (Conflito) Cópia de Blob em Andamento.

Se você chamar a operação Abort Copy Blob, verá um cabeçalho x-ms-copy-status:aborted e o blob de destino terá metadados intactos e um comprimento de blob de zero bytes. Você pode repetir a chamada original para Copy Blob para tentar a cópia novamente.

Cobrança

A conta de destino de uma operação Copy Blob é cobrada por uma transação para iniciar a cópia e também incorre em uma transação para cada solicitação de anular ou pedir o status da operação de cópia.

Quando o blob de origem está em outra conta, a conta de origem incorre em custos de transações. Além disso, se as contas de origem e destino estiverem em regiões diferentes (por exemplo, o norte e o sul dos EUA), a largura de banda usada para transferir a solicitação será cobrada da conta de armazenamento de origem como saída. A saída entre contas na mesma região é gratuita.

Quando você copia um blob de origem para um blob de destino com um nome diferente na mesma conta, usa recursos de armazenamento adicionais para o novo blob, para que a operação de cópia resulte em um encargo no uso da capacidade da conta de armazenamento para esses recursos adicionais. No entanto, se os nomes dos blobs de origem e destino forem iguais na mesma conta (por exemplo, quando você promove um instantâneo para seu blob de base), nenhum encargo adicional é incorrido, sem ser a cópia extra dos metadados armazenados na versão 2012-02-12 e mais recentes.

Quando você promove um instantâneo para substituir o blob de base, o instantâneo e o blob de base se tornam idênticos. Eles compartilham blocos ou páginas, portanto, a operação de cópia não resulta em um encargo adicional no uso da capacidade da conta de armazenamento. No entanto, se você copiar um instantâneo para um blob de destino com um nome diferente, um encargo adicional será incorrido para os recursos de armazenamento usados pelo novo blob resultante. Dois blobs com nomes diferentes não podem compartilhar blocos ou páginas, mesmo que sejam idênticos. Para obter mais informações sobre cenários de custo de instantâneo, consulte Noções básicas sobre como os instantâneos acumulam cobranças.

Mostrar:
© 2014 Microsoft