Copiar blob

Artigo
04/06/2023

A operação Copy Blob copia um blob em um destino na 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 as contas de armazenamento criadas em ou após 7 de junho de 2012 permitem que a Copy Blob operação seja copiada de outra conta de armazenamento.

Solicitação

Você pode construir a solicitação da Copy Blob seguinte maneira. Recomendamos HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento, mycontainer pelo nome do contêiner e myblob pelo nome do blob de destino.

A partir da versão 2013-08-15, você pode especificar uma SAS (assinatura de acesso compartilhado) 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

Ao fazer uma solicitação no serviço de armazenamento emulado, especifique o nome do host do emulador e Armazenamento de Blobs do Azure porta 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 desenvolvimento local do armazenamento do Azure.

Parâmetros do URI

Você pode especificar os seguintes parâmetros adicionais no URI da 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 Blobs.

Cabeçalhos da solicitaçã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órios. Especifica o esquema de autorização, o nome da conta e a assinatura. Para saber mais, confira Autorizar solicitações para o Armazenamento do Azure.
`Date` ou `x-ms-date`	Obrigatórios. Especifica o UTC (Tempo Universal Coordenado) para a solicitação. Para saber mais, confira Autorizar solicitações para o Armazenamento do Azure.
`x-ms-version`	Necessário para todas as solicitações autorizadas. 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 seguir as regras de nomenclatura para identificadores C#. Para obter mais informações, consulte Nomenclatura e referência a contêineres, blobs e metadados.
`x-ms-tags`	Opcional. Define as marcas codificadas em cadeia de caracteres de consulta fornecidas no blob. As marcas não são copiadas da origem da cópia. Para obter mais informações, consulte Comentários. Com suporte na versão 2019-12-12 e posterior.
`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 Armazenamento de Blobs retornará status código 412 (Falha na pré-condição). Você não poderá especificar esse cabeçalho se a origem for um arquivo do Azure.
`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 Armazenamento de Blobs retornará status código 412 (Falha na pré-condição). Você não poderá especificar esse cabeçalho se a origem for um arquivo do Azure.
`x-ms-source-if-match`	Opcional. Um valor `ETag`. Especifique esse cabeçalho condicional para copiar o blob de origem somente se o `ETag` valor corresponder ao valor especificado. Se os valores não corresponderem, o Armazenamento de Blobs retornará status código 412 (Falha na pré-condição). Você não poderá especificar esse cabeçalho se a origem for um arquivo do Azure.
`x-ms-source-if-none-match`	Opcional. Um valor `ETag`. Especifique esse cabeçalho condicional para copiar o blob somente se o `ETag` valor não corresponder ao valor especificado. Se os valores forem idênticos, o Armazenamento de Blobs retornará status código 412 (Falha na pré-condição). Você não poderá especificar esse cabeçalho se a origem for um arquivo do Azure.
`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 Armazenamento de Blobs retornará status código 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 Armazenamento de Blobs retornará status código 412 (Falha na pré-condição).
`If-Match`	Opcional. Um valor `ETag`. Especifique um `ETag` valor para esse cabeçalho condicional para copiar o blob somente se o valor especificado `ETag` corresponder ao `ETag` valor de um blob de destino existente. Se os valores não corresponderem, o Armazenamento de Blobs retornará status código 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 Blobs retornará status código 412 (Falha na pré-condição).
`x-ms-copy-source:name`	Obrigatórios. 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 em URL, pois seria exibido em um URI de solicitação. A operação de leitura em um blob de origem na mesma conta de armazenamento pode ser autorizada por meio de chave compartilhada. A partir da versão 2017-11-09, você também pode usar 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 no 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, independentemente de residir na mesma conta ou em uma conta diferente. Somente as contas de armazenamento criadas em ou após 7 de junho de 2012 permitem que a `Copy Blob` operação seja copiada 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 no Arquivos do Azure, a URL de origem usa o formato a seguir. 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 só podem ser copiados dentro da mesma conta e um nome de origem pode usar estes formatos: - Blob no contêiner nomeado: `/accountName/containerName/blobName` – Instantâneo no contêiner nomeado: `/accountName/containerName/blobName?snapshot=<DateTime>` - Blob no contêiner raiz: `/accountName/blobName` – Instantâneo 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. 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 a ID não for válida, a operação falhará com status código 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 status código 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 concedido. Uma ID de concessão de duração finita falha com status código 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 posterior). Especifique esse cabeçalho para executar a `Copy Blob` operação somente se a ID de concessão fornecida corresponder à ID de concessão ativa 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 status código 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 recebidas pelo servidor.
`x-ms-access-tier`	Opcional. Especifica a camada a ser definida no blob de destino. Esse cabeçalho é para blobs de páginas em uma conta premium somente com a versão 2017-04-17 e posterior. Para obter uma lista completa de camadas com suporte, consulte Armazenamento premium de alto desempenho e discos gerenciados para VMs. Esse cabeçalho tem suporte na versão 2018-11-09 e posterior para blobs de blocos. Há suporte para camadas de blob de blocos no Armazenamento de Blobs ou Uso Geral contas v2. Os valores válidos são `Hot`, `ColdCool`e `Archive`. Nota:`Cold` A camada tem suporte para a versão 2021-12-02 e posterior. Para obter informações detalhadas sobre camadas de blob de blocos, consulte Camadas de armazenamento frequentes, esporádicas e de arquivos.
`x-ms-rehydrate-priority`	Opcional. Indica a prioridade com a qual reidratar um blob arquivado. Esse cabeçalho tem suporte na versão 2019-02-02 e posterior para blobs de blocos. 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. Com suporte na versão 2019-12-12 ou posterior. Esse cabeçalho é válido somente 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 até ser definida no blob. Essa é a data até a qual o blob pode ser protegido contra modificação ou exclusão. Ele 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`.

Essa operação dá suporte aos x-ms-if-tags cabeçalhos condicionais e x-ms-source-if-tags 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 Blobs.

Corpo da solicitação

Nenhum.

Resposta

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

Código de status

Na versão 2012-02-12 e posterior, uma operação bem-sucedida retorna status código 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 Códigos de status e de erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os cabeçalhos a seguir. 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 de 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 posterior, 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 problemas da 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. Esse cabeçalho é retornado para solicitações feitas na versão 2009-09-19 e mais recente.
`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 marcar o status desta 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 andamento.
`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 será igual ao valor do `x-ms-client-request-id` cabeçalho, se ele estiver presente na solicitação e o valor for no máximo 1.024 caracteres ASCII visíveis. Se o `x-ms-client-request-id` cabeçalho não estiver presente na solicitação, esse cabeçalho não estará presente na resposta.

Corpo da resposta

Nenhum.

Resposta de exemplo

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 de origem de uma Copy Blob operação podem ser autorizados:

Tipo de objeto	autorização Microsoft Entra ID	Autorização de SAS (Assinatura de Acesso Compartilhado)	Autorização de chave compartilhada (ou Chave Compartilhada Lite)
Blob de destino	Yes	Yes	Yes
Blob de origem na mesma conta de armazenamento	Yes	Yes	Yes
Blob de origem em outra conta de armazenamento	No	Yes	No

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

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

Importante

A Microsoft recomenda usar Microsoft Entra ID com identidades gerenciadas para autorizar solicitações ao Armazenamento do Azure. Microsoft Entra ID fornece 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 de Microsoft Entra ID para autorizar solicitações para dados de blob. Com Microsoft Entra ID, você pode usar o RBAC (controle de acesso baseado em função) do Azure 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 por Microsoft Entra ID para retornar um token OAuth 2.0. Em seguida, o token pode ser usado para autorizar uma solicitação no serviço de Blob.

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

Permissões

Veja abaixo a ação RBAC necessária para um usuário Microsoft Entra, grupo, identidade gerenciada ou entidade de serviço para chamar a Copy Blob operação e a função RBAC interna do Azure com menos privilégios que inclui esta ação:

Blob de destino

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (para gravar em um blob existente) ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (para gravar um novo blob no destino)
Função interna com privilégios mínimos:Colaborador de Dados do Blob de Armazenamento

Blob de origem na mesma conta de armazenamento

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Função interna com privilégios mínimos:Leitor de Dados do Blob de Armazenamento

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

Uma SAS (assinatura de acesso compartilhado) fornece acesso delegado seguro aos recursos em uma conta de armazenamento. Com uma SAS, você tem controle granular sobre como um cliente pode acessar dados. Você pode especificar qual recurso o cliente pode acessar, quais permissões eles têm para esses recursos e por quanto tempo a SAS é válida.

A Copy Blob operação dá suporte a três tipos de assinaturas de acesso compartilhado: SAS de delegação de usuário, SAS de serviço e SAS de conta.

Como prática recomendada de segurança, recomendamos que você use Microsoft Entra credenciais em vez da chave da conta de armazenamento, que pode ser comprometida com mais facilidade. Se o design do aplicativo exigir assinaturas de acesso compartilhado, use Microsoft Entra credenciais para criar uma SAS de delegação de usuário, quando possível.

Quando o acesso à Chave Compartilhada não for permitido para a conta de armazenamento, um token SAS de serviço ou um token SAS de conta não será permitido em uma solicitação para o Armazenamento de Blobs. Para saber mais, confira Entender como a não permissão de Chave Compartilhada afeta tokens SAS.

SAS de delegação do usuário

Uma SAS de delegação de usuário é protegida com Microsoft Entra credenciais e também pelas permissões especificadas para a SAS.

Chamar a Copy Blob operação usando um token SAS delegado a um recurso de blob requer a permissão a seguir como parte do token SAS de delegação do usuário.

Operação	Tipo de objeto	Permissão assinada
Copiar blob	Blob de destino (novo)	Create (c) ou Gravação (w)
Copiar blob	Blob de destino (existente)	Gravação (w)
Copiar blob	Blob de origem (dentro da mesma conta de armazenamento)	Leitura (r)
Copiar blob	Blob de origem (em uma conta de armazenamento diferente)	Leitura (r)

Para saber mais sobre a SAS de delegação de usuário, consulte Create uma SAS de delegação de usuário.

SAS de serviço

Uma SAS de serviço é protegida com a chave da conta de armazenamento. Uma SAS de serviço delega acesso a um recurso em um único serviço de Armazenamento do Azure, como o armazenamento de blobs.

Chamar a Copy Blob operação usando um token SAS delegado a um recurso de blob requer a permissão a seguir como parte do token SAS de serviço.

Operação	Tipo de objeto	Permissão assinada
Copiar blob	Blob de destino (novo)	Create (c) ou Gravação (w)
Copiar blob	Blob de destino (existente)	Gravação (w)
Copiar blob	Blob de origem (dentro da mesma conta de armazenamento)	Leitura (r)
Copiar blob	Blob de origem (em uma conta de armazenamento diferente)	Leitura (r)

Para saber mais sobre a SAS de serviço, consulte Create uma SAS de serviço.

SAS de Conta

Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma SAS de conta delega acesso a recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de uma SAS de serviço ou de delegação do usuário também estão disponíveis por meio de uma SAS de conta.

A tabela a seguir indica o tipo de recurso assinado e as permissões assinadas a serem especificadas ao delegar o acesso:

Operação	Tipo de objeto	Serviço assinado	Tipo de recurso assinado	Permissão assinada
Copiar blob	Blob de destino (novo)	Blob (b)	Objeto (o)	Create (c) ou Gravação (w)
Copiar blob	Blob de destino (existente)	Blob (b)	Objeto (o)	Gravação (w)
Copiar blob	Blob de origem (dentro da mesma conta de armazenamento)	Blob (b)	Objeto (o)	Leitura (r)
Copiar blob	Blob de origem (em uma conta de armazenamento diferente)	Blob (b)	Objeto (o)	Leitura (r)

Para saber mais sobre a SAS da conta, consulte Create uma SAS de conta.

Comentários

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 marcar 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 há garantia de que uma cópia seja iniciada imediatamente ou concluída em um período especificado.

O blob de origem de uma operação de cópia pode ser um blob de blocos, um blob de acréscimo, um blob de páginas ou um instantâneo. 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. Não é possível modificar o blob de destino enquanto uma operação de cópia está em andamento.

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

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 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 status código 409 (Conflito).

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

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

Uma operação Copy Blob pode ter algumas destas 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 que a operação de cópia cria.
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 todos os blocos não confirmadas e substitui os metadados de blob.
Você pode copiar um arquivo de origem em Arquivos do Azure para um blob de destino. O blob de destino pode ser um blob de blocos existente ou pode ser um novo blob de blocos criado pela operação de cópia. Não há suporte para a cópia de arquivos para blobs de páginas ou blobs de acréscimo.
Você pode copiar um instantâneo sobre seu blob de base. Promovendo um instantâneo para a posição do blob de base, você pode 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áginas, o Armazenamento de Blobs cria um blob de páginas de destino do comprimento do blob de origem. Inicialmente, o blob de páginas contém todos os zeros. Os intervalos de páginas de origem são enumerados em seguida e os intervalos não vazios são copiados.

Para um blob de blocos ou um blob de acréscimo, o Armazenamento de Blobs cria um blob confirmado de comprimento zero antes de retornar dessa operação.

Quando você está copiando de um blob de blocos, 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 confirmada 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 marcar o status da operação de cópia. O blob final será confirmado quando a operação de cópia for concluída.

Quando a origem de uma operação de cópia fornece ETag valores, qualquer alteração na origem enquanto a operação de cópia está em andamento fará com que essa operação falhe. Uma tentativa de alterar o blob de destino enquanto uma cópia está em andamento falhará com status código 409 (Conflito). 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 valor de um blob de blocos é alterado quando a Copy Blob operação é iniciada e quando a operação é concluída. O ETag valor de um blob de páginas é alterado quando a Copy Blob operação é iniciada e continua a ser alterado com frequência durante a operação de cópia. O conteúdo de um blob de blocos fica visível por meio de um Get comando somente após a conclusão da operação de cópia completa.

Copiando propriedades, marcas 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 (somente para blobs de páginas)
x-ms-committed-block-count (somente para blobs de acréscimo e somente para a versão 2015-02-21)

A lista de bloqueados confirmada do blob de origem também será copiada para o blob de destino, se o blob for um blob de blocos. Todos os blocos não confirmados não são copiados.

O blob de destino é sempre do mesmo tamanho que o blob de origem. O valor do Content-Length cabeçalho do blob de destino corresponde ao valor desse cabeçalho para o 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.

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

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

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

Copiando um blob concedido

A Copy Blob operação lê apenas do 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 ETag valor for alterado antes da conclusão da operação de cópia, a operação 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 ativa, essa chamada falhará com um código de status 412 (falha na pré-condição). Embora a operação de cópia esteja pendente, qualquer operação de concessão no blob de destino falhará com status código 409 (Conflito). Uma concessão infinita no blob de destino é bloqueada dessa forma durante a operação de cópia, seja copiando para um blob de destino que tenha um nome diferente da origem, copiando para um blob de destino que tenha o mesmo nome que a 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 Blobs retornará status código 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 Blobs retorna status código 201 (Criado).

Copiando instantâneos de blob

Quando um blob de origem é copiado, todos os 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 uma instantâneo sobre seu blob de base, desde que ele esteja em uma camada online (quente ou fria). 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 em seu blob de base, desde que ela esteja em uma camada online (quente ou fria). 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 gravada.

Copiando um blob arquivado

A partir da versão 2018-11-09, você pode copiar um blob arquivado para um novo blob na mesma conta de armazenamento. O blob de origem permanece na camada de arquivos. 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. Você não pode copiar para um blob na camada de arquivos.

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 que a conta de origem.

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

Para obter informações detalhadas sobre camadas no nível do blob de blocos, consulte Camadas de armazenamento frequentes, esporádicas e de arquivos.

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 status	Significado
202 (Aceito), x-ms-copy-status: success	Operação de cópia concluída com êxito.
202 (Aceito), x-ms-copy-status: pending	A operação de cópia não foi concluída. Sondar o blob de destino usando `Get Blob Properties` para examinar o `x-ms-copy-status` cabeçalho até que a operação seja concluída ou falhe.
4xx, 500 ou 503	Falha na operação de 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 operação for concluída, o Armazenamento de Blobs gravará o valor de tempo e resultado (success, failedou aborted) nas propriedades do blob de destino. Se a operação tiver um failed resultado, o x-ms-copy-status-description cabeçalho conterá uma cadeia de caracteres de detalhes de erro.

Uma operação pendente Copy Blob tem um tempo limite de duas semanas. Uma tentativa de cópia que não foi concluída após duas semanas atinge o tempo limite e deixa um blob vazio com o x-ms-copy-status campo definido failed como e o x-ms-copy-status-description definido 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 causar falha. Nesses casos, x-ms-copy-status-description descreve os erros intermitentes.

Qualquer tentativa de modificar ou instantâneo o blob de destino durante a operação de cópia falhará com status código 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 para 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 status	Significado
202 (Aceito), x-ms-copy-status: success	Operação de cópia concluída com êxito.
4xx, 500 ou 503	Falha na operação de cópia.

A camada é herdada para camadas de armazenamento Premium. Para blobs de blocos, substituir o blob de destino herdará a camada quente ou fria do destino se x-ms-access-tier não for fornecido. A substituição de um blob arquivado falhará. Para obter informações detalhadas sobre camadas no nível do blob de blocos, consulte Camadas de armazenamento frequentes, esporádicas e de arquivos.

Cobrança

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

Operação	Tipo de conta de armazenamento	Categoria de cobrança
Copiar Blob (conta de destino¹)	Blob de blocos Premium Uso geral v2 Standard Uso geral v1 Standard	Operações de gravação
Copiar Blob (conta de origem²)	Blob de blocos Premium Uso geral v2 Standard Uso geral v1 Standard	Operações de leitura

¹A conta de destino é cobrada por uma transação para iniciar a gravação.
²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, confira Preços Armazenamento de Blobs do Azure.

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

Além disso, se as contas de origem e 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 para a 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 que tem um nome diferente na mesma conta, você usa recursos de armazenamento adicionais para o novo blob. Em seguida, a operação de cópia resulta em um encargo em relação ao uso da capacidade da conta de armazenamento para esses recursos adicionais. No entanto, se os nomes dos blobs de origem e destino forem os mesmos dentro da mesma conta (por exemplo, quando você promove um instantâneo para seu blob base), nenhuma cobrança adicional será incorrida, além dos metadados de cópia extra armazenados na versão 2012-02-12 e posterior.

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 uma instantâneo para um blob de destino que tenha um nome diferente, essa operação incorre em uma cobrança adicional para os recursos de armazenamento que o novo blob resultante usa. Dois blobs que têm nomes diferentes não podem compartilhar blocos ou páginas, mesmo que sejam idênticos. Para obter mais informações sobre instantâneo cenários de custo, consulte Noções básicas sobre como os instantâneos acumulam encargos.

Confira também

Autorizar solicitações para o Armazenamento do Azure
Status e códigos de erro
Códigos de erro do Armazenamento de Blobs
Noções básicas sobre como os instantâneos acumulam encargos
Anular copiar Blob

Compartilhar via