Partilhar via

Copiar Blob

A Copy Blob operação copia um blob para um destino dentro da conta de armazenamento.

Na versão 2012-02-12 e posterior, a origem de uma Copy Blob operação pode ser um blob confirmado em qualquer conta de armazenamento do Azure.

A partir da versão 2015-02-21, a origem de uma Copy Blob operação pode ser um arquivo do Azure em qualquer conta de armazenamento do Azure.

Observação

Somente contas de armazenamento criadas em ou após 7 de junho de 2012 permitem que a Copy Blob operação copie de outra conta de armazenamento.

Solicitação

Você pode construir a solicitação Copy Blob da seguinte maneira. Recomendamos HTTPS. 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 (SAS) para o blob de destino se ele estiver na mesma conta que o blob de origem. A partir da versão 2015-04-05, você também pode especificar uma assinatura de acesso compartilhado para o blob de destino se ele estiver em uma conta de armazenamento diferente.

URI de solicitação de método PUT Versão HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob HTTP/1.1

URI para o serviço de armazenamento emulado

Quando você estiver fazendo uma solicitação no serviço de armazenamento emulado, especifique o nome do host do emulador e a porta do Armazenamento de Blob do Azure como 127.0.0.1:10000, seguido pelo nome da conta de armazenamento emulada:

URI de solicitação de método PUT Versão HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.1

Para obter mais informações, consulte Usar o emulador Azurite para o desenvolvimento local do Armazenamento do Azure.

Parâmetros de URI

Você pode especificar os seguintes parâmetros adicionais no URI de solicitação:

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

Cabeçalhos da requisição

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

Cabeçalho da solicitação Descrição
Authorization Obrigatório Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, consulte Autorizar solicitações para o Armazenamento do Azure.
Date ou x-ms-date Obrigatório Especifica o Tempo Universal Coordenado (UTC) para a solicitação. Para obter mais informações, consulte Autorizar solicitações para o Armazenamento do Azure.
x-ms-version Obrigatório para todos os pedidos autorizados. 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 nome/valor definido pelo usuário associado ao blob. Se nenhum par nome/valor for especificado, a operação copiará os metadados do blob ou arquivo de origem para o blob de destino. Se um ou mais pares nome/valor forem especificados, o blob de destino será criado com os metadados especificados e os metadados não serão copiados do blob ou arquivo de origem.

A partir da versão 2009-09-19, os nomes de metadados devem aderir às regras de nomenclatura para identificadores C#. Para obter mais informações, consulte Nomeando e referenciando contêineres, blobs e metadados.
x-ms-tags Opcional. Define as tags codificadas query-string-encoded no blob. As tags não são copiadas da fonte de cópia. Para obter mais informações, veja Observações. Suportado na versão 2019-12-12 e posterior.
x-ms-source-if-modified-since Opcional. Um valor de 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 Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição). Não é possível especificar esse cabeçalho se a origem for um arquivo do Azure.
x-ms-source-if-unmodified-since Opcional. Um valor de 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 Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição). Não é possível especificar esse cabeçalho se a origem for um arquivo do Azure.
x-ms-source-if-match Opcional. Um ETag valor. Especifique esse cabeçalho condicional para copiar o blob de origem somente se seu ETag valor corresponder ao valor especificado. Se os valores não corresponderem, o Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição). Não é possível especificar esse cabeçalho se a origem for um arquivo do Azure.
x-ms-source-if-none-match Opcional. Um ETag valor. Especifique esse cabeçalho condicional para copiar o blob somente se seu ETag valor não corresponder ao valor especificado. Se os valores forem idênticos, o Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição). Não é possível especificar esse cabeçalho se a origem for um arquivo do Azure.
If-Modified-Since Opcional. Um valor de 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 Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição).
If-Unmodified-Since Opcional. Um valor de 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 Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição).
If-Match Opcional. Um ETag valor. Especifique um ETag valor para esse cabeçalho condicional para copiar o blob somente se o valor especificado ETag corresponder ao valor de ETag um blob de destino existente. Se os valores não corresponderem, o Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição).
If-None-Match Opcional. Um ETag valor ou o caractere curinga (*).

Especifique um ETag valor para esse cabeçalho condicional para copiar o blob somente se o valor especificado ETag não corresponder ao ETag valor 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 Armazenamento de Blob retornará o código de status 412 (Falha na pré-condição).
x-ms-copy-source:name Obrigatório Especifica o nome do blob ou arquivo de origem.

A partir da versão 2012-02-12, esse valor pode ser uma URL de até 2 kibibytes (KiB) de comprimento que especifica um blob. O valor deve ser codificado por URL como apareceria em um URI de solicitação.

A operação de leitura em um blob de origem na mesma conta de armazenamento pode ser autorizada via chave compartilhada. A partir da versão 2017-11-09, você também pode usar o Microsoft Entra ID para autorizar a operação de leitura no blob de origem. No entanto, se a origem for um blob em outra conta de armazenamento, o blob de origem deverá ser público ou o acesso a ele deverá ser autorizado por meio de uma assinatura de acesso compartilhado. Se o blob de origem for público, nenhuma autorização será necessária para executar a operação de cópia.

A partir da versão 2015-02-21, o objeto de origem pode ser um arquivo nos Arquivos do Azure. Se o objeto de origem for um arquivo que será copiado para um blob, o arquivo de origem deverá ser autorizado por meio de uma assinatura de acesso compartilhado, quer resida na mesma conta ou em uma conta diferente.

Somente contas de armazenamento criadas em ou após 7 de junho de 2012 permitem que a Copy Blob operação copie de outra conta de armazenamento.

Aqui estão alguns exemplos de URLs de objeto de origem:

- 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>

Quando o objeto de origem é um arquivo nos Arquivos do Azure, a URL de origem usa o seguinte formato. Observe que a URL deve incluir um token SAS válido para o arquivo.

- https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken

Em versões anteriores a 2012-02-12, os blobs podem ser copiados apenas dentro da mesma conta, e um nome de origem pode usar estes formatos:

- Blob no recipiente nomeado: /accountName/containerName/blobName
- Snapshot no contêiner nomeado: /accountName/containerName/blobName?snapshot=<DateTime>
- Blob no recipiente raiz: /accountName/blobName
- Snapshot no contêiner raiz: /accountName/blobName?snapshot=<DateTime>
x-ms-lease-id:<ID> Obrigatório se o blob de destino tiver uma concessão ativa. O ID de concessão especificado para este cabeçalho deve corresponder ao ID de concessão do blob de destino. Se a solicitação não incluir o ID de concessão ou se o ID não for válido, 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 uma concessão ativa no momento, a operação falhará com o código de status 412 (Falha na pré-condição).

Na versão 2012-02-12 e posterior, esse valor deve especificar uma concessão infinita ativa para um blob alugado. Um ID de concessão de duração finita falha com o código de status 412 (Falha na pré-condição).
x-ms-source-lease-id: <ID> Opcional para versões anteriores a 2012-02-12 (sem suporte em 2012-02-12 e posteriores). Especifique esse cabeçalho para executar a Copy Blob operação somente se o ID de concessão fornecido corresponder ao ID de concessão ativo do blob de origem.

Se esse cabeçalho for especificado e o blob de origem não tiver uma concessão ativa no momento, a operação 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 KiB que é registrado nos logs quando o registro em log é configurado. É altamente recomendável que você use esse cabeçalho para correlacionar atividades do lado do cliente com solicitações que o servidor recebe.
x-ms-access-tier Opcional. Especifica a camada a ser definida no blob de destino. Este cabeçalho destina-se a blobs de página numa conta premium apenas com a versão 2017-04-17 e posterior. Para obter uma lista completa dos níveis suportados, consulte Armazenamento premium de alto desempenho e discos gerenciados para VMs. Este cabeçalho é suportado na versão 2018-11-09 e posterior para blobs de bloco. A hierarquização de blob de bloco é suportada em contas de Armazenamento de Blob ou de Uso Geral v2. Os valores válidos são Hot, ColdCoole Archive. Nota:Cold camada é suportada para a versão 2021-12-02 e posterior. Para obter informações detalhadas sobre a hierarquização de blob de bloco , consulte Níveis de armazenamento quentes, frios e de arquivamento.
x-ms-rehydrate-priority Opcional. Indica a prioridade com a qual hidratar um blob arquivado. Este cabeçalho é suportado na versão 2019-02-02 e posterior para blobs de bloco. Os valores válidos são High e Standard. Você pode definir a prioridade em um blob apenas uma vez. Esse cabeçalho será ignorado em solicitações subsequentes para o mesmo blob. A prioridade padrão sem esse cabeçalho é Standard.
x-ms-seal-blob Opcional. Suportado na versão 2019-12-12 ou posterior. Este cabeçalho é válido apenas para blobs de acréscimo. Ele sela o blob de destino após a conclusão da operação de cópia.
x-ms-immutability-policy-until-date Versão 2020-06-12 e posterior. Especifica a data de retenção a ser definida no blob. Esta é a data até a qual o blob pode ser protegido contra modificação ou exclusão. Segue RFC1123 formato.
x-ms-immutability-policy-mode Versão 2020-06-12 e posterior. Especifica o modo de política de imutabilidade a ser definido no blob. Os valores válidos são unlocked e locked. Um unlocked valor indica que o usuário pode alterar a política aumentando ou diminuindo a data de retenção até. Um locked valor indica que essas ações são proibidas.
x-ms-legal-hold Versão 2020-06-12 e posterior. Especifica a retenção legal a ser definida no blob. Os valores válidos são true e false.

Esta operação suporta os x-ms-if-tags cabeçalhos e x-ms-source-if-tags condicionais para ter êxito somente se a condição especificada for atendida. Para obter mais informações, consulte Especificar cabeçalhos condicionais para operações de armazenamento de Blob.

Corpo de solicitação

Nenhum.

Resposta

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

Código de estado

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

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

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

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Cabeçalho da resposta Descrição
ETag Na versão 2012-02-12 e posterior, se a cópia estiver concluída, esse cabeçalho conterá o ETag valor do blob de destino. Se a cópia não estiver concluída, o cabeçalho conterá o ETag valor do blob vazio criado no início da operação de cópia.

Em versões anteriores a 2012-02-12, esse cabeçalho retorna o ETag valor do blob de destino.

Na versão 2011-08-18 e posteriores, o ETag valor está 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 Identifica exclusivamente a solicitação que foi feita. Você pode usar esse cabeçalho para solucionar a solicitação. Para obter mais informações, consulte Solucionar problemas de operações de API.
x-ms-version Indica a versão do Armazenamento de Blobs usada para executar a solicitação. Este cabeçalho é retornado para solicitações feitas na versão 2009-09-19 e posterior.
Date Um valor de data/hora UTC que indica a hora em que o serviço enviou a resposta.
x-ms-copy-id: <id> Versão 2012-02-12 e posterior. Fornece um identificador de cadeia de caracteres para esta 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 cancelar uma operação de cópia pendente.
x-ms-copy-status: <success ¦ pending> Versão 2012-02-12 e posterior. Indica o estado da operação de cópia, com estes valores:

- success: A operação foi concluída com êxito.
- pending: A operação está em curso.
x-ms-version-id: <DateTime> Versão 2019-12-12 e posterior. Identifica exclusivamente o blob por sua versão. Você pode usar esse valor opaco em solicitações subsequentes para acessar esta versão do blob.
x-ms-client-request-id Pode ser usado para solucionar problemas de solicitações e respostas correspondentes. O valor desse cabeçalho é igual ao valor do cabeçalho x-ms-client-request-id, se ele estiver presente na solicitação e o valor for no máximo 1.024 caracteres ASCII visíveis. Se o cabeçalho x-ms-client-request-id não estiver presente na solicitação, esse cabeçalho não estará presente na resposta.

Corpo da resposta

Nenhum.

Resposta da amostra

O código a seguir é uma resposta de exemplo para uma solicitação para copiar um 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>

Autorização

A autorização é necessária ao chamar qualquer operação de acesso a dados no Armazenamento do Azure. A tabela a seguir descreve como os objetos de destino e origem de uma operação Copy Blob podem ser autorizados:

Tipo de objeto Autorização do Microsoft Entra ID Autorização de Assinatura de Acesso Compartilhado (SAS) Autorização de chave compartilhada (ou Shared Key Lite)
Blob de destino Sim Sim Sim
Blob de origem na mesma conta de armazenamento Sim Sim Sim
Blob de origem em outra conta de armazenamento Não Sim Não

Se uma solicitação especificar tags no cabeçalho da x-ms-tags solicitação, o chamador deverá atender aos requisitos de autorização da operação Definir Tags de Blob .

Você pode autorizar a operação Copy Blob conforme descrito abaixo. Observe que um blob de origem em uma conta de armazenamento diferente deve ser autorizado separadamente via token SAS com a permissão Read (r ). Para obter mais informações sobre a autorização de blob de origem, consulte os detalhes do cabeçalho x-ms-copy-sourceda solicitação.

Importante

A Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autorizar solicitações ao Armazenamento do Azure. O Microsoft Entra ID oferece segurança superior e facilidade de uso em comparação com a autorização de chave compartilhada.

O Armazenamento do Azure dá suporte ao uso do Microsoft Entra ID para autorizar solicitações para dados de blob. Com o Microsoft Entra ID, você pode usar o controle de acesso baseado em função do Azure (Azure RBAC) para conceder permissões a uma entidade de segurança. A entidade de segurança pode ser um usuário, grupo, entidade de serviço de aplicativo ou identidade gerenciada do Azure. A entidade de segurança é autenticada pelo Microsoft Entra ID para retornar um token OAuth 2.0. O token pode ser usado para autorizar uma solicitação contra o serviço Blob.

Para saber mais sobre a autorização usando o Microsoft Entra ID, consulte Autorizar o acesso a blobs usando o Microsoft Entra ID.

Permissões

Abaixo estão listadas a ação RBAC necessária para que um usuário, grupo, identidade gerenciada ou entidade de serviço do Microsoft Entra chame a operação Copy Blob e a função interna menos privilegiada do RBAC do Azure que inclui essa ação:

Blob de destino

Blob de origem na mesma conta de armazenamento

Para saber mais sobre como atribuir funções usando o RBAC do Azure, consulte Atribuir uma função do Azure para acesso a dados de blob.

Observações

Na versão 2012-02-12 e posterior, a Copy Blob operação pode ser concluída de forma assíncrona. Esta operação retorna uma ID de cópia que você pode usar para verificar ou cancelar a operação de cópia. Devido à natureza assíncrona da operação de cópia, o Armazenamento de Blobs copia blobs com base no melhor esforço. O serviço Blob copia blobs quando os recursos do servidor não estão sendo utilizados por outras tarefas, portanto, não é garantido que uma cópia seja iniciada imediatamente ou concluída em um período de tempo especificado.

O blob de origem para uma operação de cópia pode ser um blob de bloco, um blob de acréscimo, um blob de página ou um instantâneo. Se o blob de destino já existir, ele deverá ser do mesmo tipo de blob que o blob de origem. Qualquer blob de destino existente será substituído. Não é possível modificar o blob de destino enquanto uma operação de cópia estiver em andamento.

Na versão 2015-02-21 e posterior, a origem da operação de cópia também pode ser um arquivo nos Arquivos do Azure. Se a origem for um arquivo, o destino deve ser um blob de bloco.

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

Somente contas de armazenamento criadas em ou após 7 de junho de 2012 permitem que a Copy Blob operação copie 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 falha com o código de status 400 (Solicitação incorreta).

A operação Copy Blob sempre copia todo o blob ou arquivo de origem. Não há suporte para copiar um intervalo de bytes ou um conjunto de blocos.

Uma Copy Blob operação pode assumir qualquer uma das seguintes formas:

  • Você pode copiar um blob de origem para um blob de destino que tenha um nome diferente. O blob de destino pode ser um blob existente do mesmo tipo de blob (bloco, acréscimo ou página), 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 que tenha o mesmo nome, substituindo efetivamente o blob de destino. Essa operação de cópia remove quaisquer blocos não confirmados e substitui os metadados do blob.

  • Você pode copiar um arquivo de origem nos Arquivos do Azure para um blob de destino. O blob de destino pode ser um blob de bloco existente ou pode ser um novo blob de bloco criado pela operação de cópia. Não há suporte para copiar de arquivos para blobs de página ou acrescentar blobs.

  • Você pode copiar um instantâneo sobre seu blob base. Ao promover uma cópia instantânea para a posição do blob base, pode-se restaurar uma versão anterior de um blob.

  • Você pode copiar um instantâneo para um blob de destino que tenha um nome diferente. O blob de destino resultante é um blob gravável e não um instantâneo.

Quando você está copiando de um blob de página, o Armazenamento de Blob cria um blob de página de destino do comprimento do blob de origem. Inicialmente, o blob de página contém todos os zeros. Em seguida, os intervalos de página de origem são enumerados e os intervalos não vazios são copiados.

Para um blob de bloco ou um blob de acréscimo, o Armazenamento de Blob cria um blob comprometido de comprimento zero antes de retornar desta operação.

Quando você está copiando de um blob de bloco, todos os blocos confirmados e suas IDs de bloco são copiados. Os blocos não confirmados não são copiados. No final da operação de cópia, o blob de destino tem a mesma contagem de blocos confirmados que a origem.

Quando você está copiando de um blob de acréscimo, todos os blocos confirmados são copiados. No final da operação de cópia, o blob de destino terá menos ou o mesmo número de blocos confirmados que o blob de origem.

Para todos os tipos 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 operação de cópia terminar.

Quando a origem de uma operação de cópia fornece ETag valores, quaisquer alterações na origem enquanto a operação de cópia estiver em andamento farão com que essa operação falhe. Uma tentativa de alterar o blob de destino enquanto uma cópia está em andamento falhará com o código de status 409 (Conflito). Se o blob de destino tiver uma concessão infinita, a ID da concessão deverá ser passada para Copy Blob. Não são permitidos arrendamentos de duração finita.

O ETag valor de um blob de bloco muda quando a Copy Blob operação é iniciada e quando a operação termina. O ETag valor de um blob de página muda quando a Copy Blob operação é iniciada e continua a ser alterado com freqüência durante a operação de cópia. O conteúdo de um blob de bloco é visível através de um Get comando somente após a conclusão da operação de cópia completa.

Copiando propriedades, tags e metadados de blob

Quando um blob é copiado, as seguintes propriedades do sistema são copiadas para o blob de destino que tem os mesmos valores:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (apenas para blobs de página)

  • x-ms-committed-block-count (apenas para blobs de apêndice e apenas para a versão 2015-02-21)

A lista de bloqueios confirmada do blob de origem também é copiada para o blob de destino, se o blob for um blob de bloco. Quaisquer blocos não confirmados não são copiados.

O blob de destino tem sempre o mesmo tamanho que o blob de origem. O valor do cabeçalho para o blob de Content-Length destino corresponde ao valor desse cabeçalho para o blob de origem.

Quando o blob de origem e o blob de destino são os mesmos, Copy Blob remove todos os blocos não confirmados. Se os metadados forem especificados nesse caso, os metadados existentes serão substituídos pelos novos metadados.

Se o x-ms-tags cabeçalho fornecer tags para o blob de destino, elas deverão ser codificadas em cadeia de caracteres de consulta. As chaves e os valores das tags devem estar em conformidade com os requisitos de nomenclatura e comprimento, conforme especificado em Definir tags de Blob.

O x-ms-tags cabeçalho pode conter até 2 kilobits de tags. Se precisar de mais tags, use a Set Blob Tags operação.

Se o x-ms-tags cabeçalho não fornecer tags, as tags não serão copiadas do blob de origem.

Copiando um blob alugado

A Copy Blob operação só lê o blob de origem, portanto, o estado de concessão do blob de origem não importa. No entanto, a Copy Blob operação salva o ETag valor do blob de origem quando a operação de cópia é iniciada. Se o valor do ETag for alterado antes da conclusão da operação de cópia, a operação falhará. Você pode impedir alterações no blob de origem alugando-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 Copy Blob operação. Se a concessão especificada for uma concessão de duração finita ativa, essa chamada falhará com um código de status 412 (Falha na pré-condição). Enquanto a operação de cópia estiver pendente, qualquer operação de concessão no blob de destino falhará com o código de status 409 (Conflito). Uma concessão infinita no blob de destino é bloqueada dessa forma durante a operação de cópia, quer você esteja copiando para um blob de destino que tenha um nome diferente da origem, copiando para um blob de destino que tenha o mesmo nome da origem ou promovendo um instantâneo sobre seu blob base.

Se o cliente especificar uma ID de concessão em um blob que ainda não existe, o Armazenamento de 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 Armazenamento de Blob retorna o código de status 201 (Criado).

Copiando instantâneos de blob

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

Você pode executar uma operação de cópia para promover um instantâneo sobre seu blob base, desde que ele esteja em uma camada online (quente ou legal). 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.

Copiando versões de blob

Você pode executar uma operação de cópia para promover uma versão sobre seu blob base, desde que ela esteja em uma camada online (quente ou legal). Dessa forma, você pode restaurar uma versão anterior de um blob. A versão permanece, mas seu destino é substituído por uma cópia que pode ser lida e escrita.

Copiando um blob arquivado

A partir da versão 2018-11-09, você pode copiar um blob arquivado para um novo blob dentro da mesma conta de armazenamento. O blob de origem permanece na camada de arquivamento. Quando o blob de origem é um blob arquivado, a solicitação deve conter o x-ms-access-tier cabeçalho, que indica a camada do blob de destino. O blob de destino deve estar em uma camada online. Não é possível copiar para um blob na camada de arquivamento.

A partir da versão 2021-02-12, você pode copiar um blob arquivado para uma camada online em uma conta de armazenamento diferente, desde que a conta de destino esteja na mesma região da conta de origem.

A solicitação pode falhar se o blob de origem estiver sendo reidratado.

Para obter informações detalhadas sobre hierarquização no nível de blob de bloco, consulte Níveis de armazenamento quentes, frios e de arquivamento.

Trabalhando com uma operação de cópia pendente (versão 2012-02-12 e posterior)

Se a Copy Blob operação for concluída de forma assíncrona, use a tabela a seguir para determinar a próxima etapa com base no código de status retornado:

Código de estado Significado
202 (Aceito), x-ms-copy-status: sucesso Operação de cópia concluída com êxito.
202 (Aceito), x-ms-copy-status: pendente A operação de cópia não foi concluída. Sondem o blob de destino usando Get Blob Properties para examinar o x-ms-copy-status cabeçalho até que a operação termine ou falhe.
4xx, 500 ou 503 Falha na operação de cópia.

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

Uma operação Copy Blob pendente tem um tempo limite de duas semanas. Uma tentativa de cópia que não foi concluída após duas semanas expira e deixa um blob vazio com o x-ms-copy-status campo definido como failed e o x-ms-copy-status-description conjunto como 500 (OperationCancelled). Erros intermitentes e não fatais que podem ocorrer durante uma operação de cópia podem impedir o progresso da operação, mas não fazer com que ela falhe. Nestes casos, x-ms-copy-status-description descreve os erros intermitentes.

Qualquer tentativa de modificar ou criar um instantâneo do blob de destino durante a operação de cópia falhará com o código de status 409 (Conflito), "Copiar Blob em Andamento".

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

Se a Copy Blob operação for concluída de forma síncrona, use a tabela a seguir para determinar o status da operação de cópia:

Código de estado Significado
202 (Aceito), x-ms-copy-status: sucesso Operação de cópia concluída com êxito.
4xx, 500 ou 503 Falha na operação de cópia.

O nível é herdado para níveis de armazenamento premium. Para blobs de bloco, a substituição do blob de destino herdará a camada quente ou fria do destino se x-ms-access-tier não for fornecida. A substituição de um blob arquivado falhará. Para obter informações detalhadas sobre hierarquização no nível de blob de bloco, consulte Níveis de armazenamento quentes, frios e de arquivamento.

Faturação

As solicitações de preços podem ser originadas de clientes que usam APIs de Armazenamento de Blob, diretamente por meio da API REST de Armazenamento de Blob ou de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam encargos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura são acumuladas para uma categoria de faturamento diferente das transações de gravação. A tabela a seguir mostra a categoria de faturamento para solicitações de Copy Blob com base no tipo de conta de armazenamento:

Funcionamento Tipo de conta de armazenamento Categoria de faturação
Copiar Blob (conta de destino1) Blob de armazenamento premium
Padrão de uso geral v2
Padrão de uso geral v1		 Operações de escrita
Copiar Blob (conta de origem2) Blob de armazenamento premium
Padrão de uso geral v2
Padrão de uso geral v1		 Operações de leitura

1ºA conta de destino é cobrada por uma transação para iniciar a gravação.
2ºQuando o objeto de origem está em uma conta diferente, a conta de origem incorre em uma transação para cada solicitação de leitura para o objeto de origem.

Para saber mais sobre os preços das categorias de cobrança especificadas, consulte Preços do Armazenamento de Blob do Azure.

A conta de destino também incorre em custos de transação para cada solicitação para cancelar a operação de cópia (consulte Abortar Blob de cópia) ou para verificar o status da operação de cópia (consulte Obter Blob ou Obter Propriedades de Blob).

Além disso, se as contas de origem e de destino residirem em regiões diferentes (por exemplo, Norte dos EUA e 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 dentro da mesma região é gratuita.

Quando você copia um blob de origem para um blob de destino que tem um nome diferente dentro da mesma conta, você usa recursos de armazenamento adicionais para o novo blob. Em seguida, a operação de cópia resulta em uma cobrança contra o uso da capacidade da conta de armazenamento para esses recursos adicionais. No entanto, se os nomes dos blobs de origem e de destino forem os mesmos dentro da mesma conta (por exemplo, quando você promove um instantâneo para seu blob base), nenhum custo adicional será incorrido, além dos metadados de cópia extra armazenados na versão 2012-02-12 e posterior.

Quando você promove um snapshot para substituir seu blob base, o snapshot e o blob base se tornam idênticos. Eles compartilham blocos ou páginas, portanto, a operação de cópia não resulta em uma cobrança adicional contra o uso de capacidade da conta de armazenamento. No entanto, se você copiar um instantâneo para um blob de destino que tenha um nome diferente, essa operação incorrerá em uma cobrança adicional pelos 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 snapshot , consulte Compreendendo como os snapshots acumulam encargos.

Ver também

Autorizar solicitações ao de Armazenamento do Azure
Códigos de status e de erro
códigos de erro de armazenamento de Blob
Compreender como os snapshots acumulam encargos
Abortar Cópia de Blob