Copiar Blob

Artigo
04/11/2023

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 consolidado 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 ficheiro do Azure em qualquer conta de armazenamento do Azure.

Nota

Apenas as contas de armazenamento criadas em ou depois de 7 de junho de 2012 permitem que a Copy Blob operação copie a partir de outra conta de armazenamento.

Pedir

Pode construir o pedido da Copy Blob seguinte forma. Recomendamos HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento, mycontainer pelo nome do contentor e myblob pelo nome do blob de destino.

A partir da versão 2013-08-15, pode especificar uma assinatura de acesso partilhado (SAS) para o blob de destino se estiver na mesma conta que o blob de origem. A partir da versão 2015-04-05, também pode especificar uma assinatura de acesso partilhado para o blob de destino se estiver numa conta de armazenamento diferente.

URI do pedido do 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 estiver a fazer um pedido relativamente ao serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e Armazenamento de Blobs do Azure porta como 127.0.0.1:10000, seguido do nome da conta de armazenamento emulada:

URI do pedido do método PUT	Versão HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

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

Parâmetros do URI

Pode especificar os seguintes parâmetros adicionais no URI do pedido:

Parâmetro	Description
`timeout`	Opcional. O `timeout` parâmetro é expresso em segundos. Para obter mais informações, veja Definir tempos limite para operações de Armazenamento de Blobs.

Cabeçalhos do pedido

A tabela seguinte descreve os cabeçalhos de pedido obrigatórios e opcionais:

Cabeçalho do pedido	Description
`Authorization`	Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
`Date` ou `x-ms-date`	Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
`x-ms-version`	Necessário para todos os pedidos autorizados. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
`x-ms-meta-name:value`	Opcional. Especifica um par de nomes/valores definido pelo utilizador associado ao blob. Se não forem especificados pares nome/valor, a operação copia os metadados do blob ou ficheiro de origem para o blob de destino. Se for especificado um ou mais pares nome/valor, o blob de destino é criado com os metadados especificados e os metadados não são copiados do blob ou ficheiro de origem. A partir da versão 2009-09-19, os nomes de metadados têm de cumprir as regras de nomenclatura dos identificadores C#. Para obter mais informações, veja Naming and referencing containers, blobs, and metadata (Atribuir nomes e referenciar contentores, blobs e metadados).
`x-ms-tags`	Opcional. Define as etiquetas codificadas por cadeias de consulta especificadas no blob. As etiquetas não são copiadas da origem de cópia. Para obter mais informações, consulte Observações. Suportado na versão 2019-12-12 e posterior.
`x-ms-source-if-modified-since`	Opcional. Um `DateTime` valor. Especifique este cabeçalho condicional para copiar o blob apenas 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 devolve o código de estado 412 (Falha na Pré-condição). Não pode especificar este cabeçalho se a origem for um ficheiro do Azure.
`x-ms-source-if-unmodified-since`	Opcional. Um `DateTime` valor. Especifique este cabeçalho condicional para copiar o blob apenas 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 devolve o código de estado 412 (Falha na Pré-condição). Não pode especificar este cabeçalho se a origem for um ficheiro do Azure.
`x-ms-source-if-match`	Opcional. Um `ETag` valor. Especifique este cabeçalho condicional para copiar o blob de origem apenas se o respetivo `ETag` valor corresponder ao valor especificado. Se os valores não corresponderem, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição). Não pode especificar este cabeçalho se a origem for um ficheiro do Azure.
`x-ms-source-if-none-match`	Opcional. Um `ETag` valor. Especifique este cabeçalho condicional para copiar o blob apenas se o respetivo `ETag` valor não corresponder ao valor especificado. Se os valores forem idênticos, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição). Não pode especificar este cabeçalho se a origem for um ficheiro do Azure.
`If-Modified-Since`	Opcional. Um `DateTime` valor. Especifique este cabeçalho condicional para copiar o blob apenas 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 devolve o código de estado 412 (Falha na Pré-condição).
`If-Unmodified-Since`	Opcional. Um `DateTime` valor. Especifique este cabeçalho condicional para copiar o blob apenas 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 devolve o código de estado 412 (Falha na Pré-condição).
`If-Match`	Opcional. Um `ETag` valor. Especifique um `ETag` valor para este cabeçalho condicional para copiar o blob apenas 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 devolve o código de estado 412 (Falha na Pré-condição).
`If-None-Match`	Opcional. Um `ETag` valor ou o caráter universal (). Especifique um `ETag` valor para este cabeçalho condicional para copiar o blob apenas se o valor especificado `ETag` não corresponder ao `ETag` valor do blob de destino. Especifique o caráter universal () para executar a operação apenas se o blob de destino não existir. Se a condição especificada não for cumprida, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição).
`x-ms-copy-source:name`	Obrigatório. Especifica o nome do blob ou ficheiro de origem. A partir da versão 2012-02-12, este valor pode ser um URL de até 2 kibibytes (KiB) de comprimento que especifica um blob. O valor deve ser codificado por URL, tal como apareceria num URI de pedido. A operação de leitura num blob de origem na mesma conta de armazenamento pode ser autorizada através de uma chave partilhada. A partir da versão 2017-11-09, também pode utilizar Microsoft Entra ID para autorizar a operação de leitura no blob de origem. No entanto, se a origem for um blob noutra conta de armazenamento, o blob de origem tem de ser público ou o acesso ao mesmo tem de ser autorizado através de uma assinatura de acesso partilhado. Se o blob de origem for público, não é necessária autorização para executar a operação de cópia. A partir da versão 2015-02-21, o objeto de origem pode ser um ficheiro no Ficheiros do Azure. Se o objeto de origem for um ficheiro que será copiado para um blob, o ficheiro de origem tem de ser autorizado através de uma assinatura de acesso partilhado, quer resida na mesma conta ou numa conta diferente. Apenas as contas de armazenamento criadas em ou depois de 7 de junho de 2012 permitem que a `Copy Blob` operação copie a partir de outra conta de armazenamento. Eis alguns exemplos de URLs de objetos 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 ficheiro no Ficheiros do Azure, o URL de origem utiliza o seguinte formato. Tenha em atenção que o URL tem de incluir um token de SAS válido para o ficheiro. - `https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken` Nas versões anteriores a 2012-02-12, os blobs só podem ser copiados na mesma conta e um nome de origem pode utilizar estes formatos: - Blob no contentor com o nome: `/accountName/containerName/blobName` - Instantâneo no contentor com nome: `/accountName/containerName/blobName?snapshot=<DateTime>` - Blob no contentor de raiz: `/accountName/blobName` - Instantâneo no contentor de raiz: `/accountName/blobName?snapshot=<DateTime>`
`x-ms-lease-id:<ID>`	Necessário se o blob de destino tiver uma concessão ativa. O ID de concessão especificado para este cabeçalho tem de corresponder ao ID de concessão do blob de destino. Se o pedido não incluir o ID de concessão ou o ID não for válido, a operação falha com o código de estado 412 (Falha na Pré-condição). Se este cabeçalho for especificado e o blob de destino não tiver atualmente uma concessão ativa, a operação falha com o código de estado 412 (Falha na Pré-condição). Na versão 2012-02-12 e posterior, este valor tem de especificar uma concessão infinita ativa para um blob arrendado. Um ID de concessão de duração finita falha com o código de estado 412 (Falha na Pré-condição).
`x-ms-source-lease-id: <ID>`	Opcional para versões antes de 2012-02-12 (não suportado em 2012-02-12 e posterior). Especifique este cabeçalho para executar a `Copy Blob` operação apenas se o ID de concessão fornecido corresponder ao ID de concessão ativo do blob de origem. Se este cabeçalho for especificado e o blob de origem não tiver atualmente uma concessão ativa, a operação falha com o código de estado 412 (Falha na Pré-condição).
`x-ms-client-request-id`	Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 KiB que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe.
`x-ms-access-tier`	Opcional. Especifica a camada a definir no blob de destino. Este cabeçalho destina-se a blobs de páginas numa conta premium apenas com a versão 2017-04-17 e posterior. Para obter uma lista completa dos escalões suportados, veja Armazenamento premium de alto desempenho e discos geridos para VMs. Este cabeçalho é suportado na versão 2018-11-09 e posterior para blobs de blocos. A camada de blobs de blocos é suportada no Armazenamento de Blobs ou Fins Gerais contas v2. Os valores válidos são `Hot`, `CoolCold` e `Archive`. Nota:`Cold` O escalão é suportado para a versão 2021-12-02 e posterior. Para obter informações detalhadas sobre as camadas de blobs de blocos, veja Camadas de armazenamento frequente, esporádico e de arquivo.
`x-ms-rehydrate-priority`	Opcional. Indica a prioridade para reidratar um blob arquivado. Este cabeçalho é suportado na versão 2019-02-02 e posterior para blobs de blocos. Os valores válidos são `High` e `Standard`. Pode definir a prioridade num blob apenas uma vez. Este cabeçalho será ignorado nos pedidos subsequentes para o mesmo blob. A prioridade predefinida sem este 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. Fecha 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. Esta é a data até à qual o blob pode ser protegido contra modificação ou eliminaçã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 definir no blob. Os valores válidos são `unlocked` e `locked`. Um `unlocked` valor indica que o utilizador pode alterar a política ao aumentar ou diminuir a data de retenção até à data. Um `locked` valor indica que estas ações são proibidas.
`x-ms-legal-hold`	Versão 2020-06-12 e posterior. Especifica a suspensão legal a definir no blob. Os valores válidos são `true` e `false`.

Esta operação suporta os x-ms-if-tags cabeçalhos condicionais e x-ms-source-if-tags para serem bem-sucedidos apenas se a condição especificada for cumprida. Para obter mais informações, veja Especificar cabeçalhos condicionais para operações de Armazenamento de Blobs.

Corpo do pedido

Nenhum.

Resposta

A resposta inclui um código de estado 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 devolve o código de estado 202 (Aceite).

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

Para obter informações sobre códigos de estado, veja Códigos de estado 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 de resposta	Descrição
`ETag`	Na versão 2012-02-12 e posterior, se a cópia estiver concluída, este cabeçalho contém o `ETag` valor do blob de destino. Se a cópia não estiver concluída, o cabeçalho contém o `ETag` valor do blob vazio criado no início da operação de cópia. Nas versões anteriores a 2012-02-12, este cabeçalho devolve o `ETag` valor do blob de destino. Na versão 2011-08-18 e posterior, o `ETag` valor está entre aspas.
`Last-Modified`	Devolve a data/hora em que a operação de cópia foi concluída para o blob de destino.
`x-ms-request-id`	Identifica exclusivamente o pedido que foi feito. Pode utilizar este cabeçalho para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API.
`x-ms-version`	Indica a versão do Armazenamento de Blobs que é utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos feitos 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 para esta operação de cópia. Utilize com `Get Blob` ou `Get Blob Properties` para verificar o estado desta operação de cópia ou passe para `Abort Copy Blob` 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 pela respetiva versão. Pode utilizar este valor opaco em pedidos subsequentes para aceder a esta versão do blob.
`x-ms-client-request-id`	Pode ser utilizado para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do `x-ms-client-request-id` cabeçalho, se estiver presente no pedido e o valor for, no máximo, 1024 carateres ASCII visíveis. Se o `x-ms-client-request-id` cabeçalho não estiver presente no pedido, este cabeçalho não estará presente na resposta.

Corpo da resposta

Nenhum.

Resposta de amostra

O código seguinte é uma resposta de exemplo para um pedido 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 seguinte descreve como os objetos de destino e de origem de uma Copy Blob operação podem ser autorizados:

Tipo de Objeto	autorização de Microsoft Entra ID	Autorização de Assinatura de Acesso Partilhado (SAS)	Autorização de Chave Partilhada (ou Chave Partilhada Lite)
Blob de destino	Yes	Yes	Yes
Blob de origem na mesma conta de armazenamento	Yes	Yes	Yes
Blob de origem noutra conta de armazenamento	No	Yes	No

Se um pedido especificar etiquetas no cabeçalho do x-ms-tags pedido, o autor da chamada tem de cumprir os requisitos de autorização da operação Definir Etiquetas de Blobs .

Pode autorizar a Copy Blob operação conforme descrito abaixo. Tenha em atenção que um blob de origem numa conta de armazenamento diferente tem de ser autorizado separadamente através do token SAS com a permissão Ler (r ). Para obter mais informações sobre a autorização do blob de origem, veja os detalhes do cabeçalho x-ms-copy-sourcedo pedido .

O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos para dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.

Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.

Permissões

Abaixo estão listadas as ações RBAC necessárias para que um utilizador, grupo ou principal de serviço Microsoft Entra chame a Copy Blob operação e a função RBAC do Azure com menos privilégios que inclua esta ação:

Blob de destino

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (para escrever num blob existente) ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (para escrever um novo blob no destino)
Função incorporada com menos privilégios:Contribuidor de Dados de Blobs de Armazenamento

Blob de origem na mesma conta de armazenamento

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Função incorporada com menos privilégios:Leitor deDados de Blobs de Armazenamento

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

Uma assinatura de acesso partilhado (SAS) fornece acesso delegado seguro aos recursos numa conta de armazenamento. Com uma SAS, tem controlo granular sobre como um cliente pode aceder aos dados. Pode especificar o recurso a que o cliente pode aceder, que permissões têm para esses recursos e quanto tempo a SAS é válida.

A Copy Blob operação suporta três tipos de assinaturas de acesso partilhado: SAS de delegação de utilizador,SAS de serviço e SAS de conta.

Como melhor prática de segurança, recomendamos que utilize Microsoft Entra credenciais em vez da chave da conta de armazenamento, que podem ser mais facilmente comprometidas. Se a estrutura da aplicação exigir assinaturas de acesso partilhado, utilize Microsoft Entra credenciais para criar uma SAS de delegação de utilizador, sempre que possível.

Quando o acesso à Chave Partilhada não for permitido para a conta de armazenamento, não será permitido um token de SAS de serviço ou um token de SAS de conta num pedido para o Armazenamento de Blobs. Para saber mais, veja Compreender como a desativação da Chave Partilhada afeta os tokens de SAS.

SAS de delegação de utilizadores

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

Chamar a Copy Blob operação com um token de SAS delegado a um recurso de blob requer a seguinte permissão como parte do token SAS de delegação de utilizador.

Operação	Tipo de Objeto	Permissão assinada
Copiar Blob	Blob de destino (novo)	Criar (c) ou Escrever (w)
Copiar Blob	Blob de destino (existente)	Escrever (w)
Copiar Blob	Blob de origem (na mesma conta de armazenamento)	Ler (r)
Copiar Blob	Blob de origem (numa conta de armazenamento diferente)	Ler (r)

Para saber mais sobre a SAS de delegação de utilizador, veja Criar uma SAS de delegação de utilizador.

SAS de Serviço

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

Chamar a Copy Blob operação através de um token de SAS delegado a um recurso de blob requer a seguinte permissão como parte do token de SAS do serviço.

Operação	Tipo de Objeto	Permissão assinada
Copiar Blob	Blob de destino (novo)	Criar (c) ou Escrever (w)
Copiar Blob	Blob de destino (existente)	Escrever (w)
Copiar Blob	Blob de origem (na mesma conta de armazenamento)	Ler (r)
Copiar Blob	Blob de origem (numa conta de armazenamento diferente)	Ler (r)

Para saber mais sobre a SAS do serviço, veja Criar uma SAS de serviço.

SAS de Conta

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

A tabela seguinte indica o tipo de recurso assinado e as permissões assinadas para especificar 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)	Criar (c) ou Escrever (w)
Copiar Blob	Blob de destino (existente)	Blob (b)	Objeto (o)	Escrever (w)
Copiar Blob	Blob de origem (na mesma conta de armazenamento)	Blob (b)	Objeto (o)	Ler (r)
Copiar Blob	Blob de origem (numa conta de armazenamento diferente)	Blob (b)	Objeto (o)	Ler (r)

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

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 devolve um ID de cópia que pode utilizar 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 os blobs numa base de melhor esforço. O serviço Blob copia blobs quando os recursos do servidor não estão a ser utilizados por outras tarefas, pelo que não é garantido que uma cópia comece imediatamente ou conclua num período de tempo 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ágina ou um instantâneo. Se o blob de destino já existir, tem de ser do mesmo tipo de blob que o blob de origem. Qualquer blob de destino existente será substituído. Não pode modificar o blob de destino enquanto uma operação de cópia estiver em curso.

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

Várias operações pendentes Copy Blob numa conta podem ser processadas sequencialmente. Um blob de destino só pode ter uma operação pendente Copy Blob . Por outras palavras, um blob não pode ser o destino para 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 estado 409 (Conflito).

Apenas as contas de armazenamento criadas em ou depois de 7 de junho de 2012 permitem que a Copy Blob operação copie a partir 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 estado 400 (Pedido Incorreto).

A Copy Blob operação copia sempre todo o blob ou ficheiro de origem. A cópia de um intervalo de bytes ou conjunto de blocos não é suportada.

Uma Copy Blob operação pode assumir qualquer um dos seguintes formulários:

Pode copiar um blob de origem para um blob de destino com 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.
Pode copiar um blob de origem para um blob de destino com o mesmo nome, substituindo efetivamente o blob de destino. Esta operação de cópia remove todos os blocos não comprometidos e substitui os metadados do blob.
Pode copiar um ficheiro de origem no Ficheiros 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 que a operação de cópia cria. A cópia de ficheiros para blobs de páginas ou blobs de acréscimo não é suportada.
Pode copiar um instantâneo sobre o respetivo blob base. Ao promover um instantâneo para a posição do blob base, pode restaurar uma versão anterior de um blob.
Pode copiar um instantâneo para um blob de destino com um nome diferente. O blob de destino resultante é um blob gravável e não um instantâneo.

Quando está a copiar de um blob de páginas, o Armazenamento de Blobs cria um blob de página de destino com o comprimento do blob de origem. Inicialmente, o blob de páginas contém todos os zeros. Em seguida, os intervalos de páginas de origem são enumerados 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 consolidado de comprimento zero antes de regressar desta operação.

Quando estiver a copiar de um blob de blocos, todos os blocos consolidados e os respetivos IDs de bloco são copiados. Os blocos não comprometidos não são copiados. No final da operação de cópia, o blob de destino tem a mesma contagem de blocos consolidada que a origem.

Quando estiver a copiar de um blob de acréscimo, todos os blocos consolidados são copiados. No final da operação de cópia, o blob de destino terá menos do que ou o mesmo número de blocos consolidados que o blob de origem.

Para todos os tipos de blobs, pode chamar Get Blob ou Get Blob Properties no blob de destino para verificar o estado da operação de cópia. O blob final será consolidado quando a operação de cópia for concluída.

Quando a origem de uma operação de cópia fornece valores ETag , quaisquer alterações à origem enquanto a operação de cópia estiver em curso farão com que essa operação falhe. Uma tentativa de alterar o blob de destino enquanto uma cópia estiver em curso falhará com o código de estado 409 (Conflito). Se o blob de destino tiver uma concessão infinita, o ID de concessão tem de ser transmitido para Copy Blob. As concessões de duração finita não são permitidas.

O ETag valor de um blob de blocos muda quando a Copy Blob operação é iniciada e quando a operação é concluída. O ETag valor de um blob de página é alterado quando a Copy Blob operação é iniciada e continua a ser alterado frequentemente durante a operação de cópia. O conteúdo de um blob de blocos só é visível através de um Get comando após a conclusão da operação de cópia completa.

Copiar propriedades, etiquetas e metadados de blobs

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

A lista de bloqueios consolidada do blob de origem também é copiada para o blob de destino, se o blob for um blob de blocos. Os blocos não comprometidos não são copiados.

O blob de destino tem sempre o 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 são iguais, Copy Blob remove todos os blocos não comprometidos. Se os metadados forem especificados neste caso, os metadados existentes são substituídos pelos novos metadados.

Se o x-ms-tags cabeçalho fornecer etiquetas para o blob de destino, têm de estar codificadas com cadeia de consulta. As chaves de etiqueta e os valores têm de estar em conformidade com os requisitos de nomenclatura e comprimento, conforme especificado em Definir Etiquetas de Blobs.

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

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

Copiar um blob alugado

A Copy Blob operação só lê a partir do blob de origem, pelo que o estado de concessão do blob de origem não importa. No entanto, a Copy Blob operação guarda 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á. Pode impedir alterações ao blob de origem ao alugá-lo durante a operação de cópia.

Se o blob de destino tiver uma concessão infinita ativa, tem de especificar o respetivo ID de concessão na chamada para a Copy Blob operação. Se a concessão que especificar for uma concessão de duração finita ativa, esta chamada falhará com um código de estado 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 falha com o código de estado 409 (Conflito). Uma concessão infinita no blob de destino é bloqueada desta forma durante a operação de cópia, quer esteja a copiar para um blob de destino que tenha um nome diferente da origem, a copiar para um blob de destino que tenha o mesmo nome que a origem ou a promover um instantâneo sobre o blob base.

Se o cliente especificar um ID de concessão num blob que ainda não existe, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição) para pedidos feitos na versão 2013-08-15 e posterior. Para versões anteriores, o Armazenamento de Blobs devolve o código de estado 201 (Criado).

Copiar instantâneos de blobs

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 o respetivo nome.

Pode executar uma operação de cópia para promover um instantâneo sobre o respetivo blob base, desde que esteja numa camada online (frequente ou esporádica). Desta forma, pode restaurar uma versão anterior de um blob. O instantâneo permanece, mas o destino é substituído por uma cópia que pode ser lida e escrita.

Copiar versões de blobs

Pode executar uma operação de cópia para promover uma versão através do blob base, desde que esteja numa camada online (frequente ou esporádica). Desta forma, pode restaurar uma versão anterior de um blob. A versão permanece, mas o destino é substituído por uma cópia que pode ser lida e escrita.

Copiar um blob arquivado

A partir da versão 2018-11-09, pode copiar um blob arquivado para um novo blob na mesma conta de armazenamento. O blob de origem permanece na camada de arquivo. Quando o blob de origem é um blob arquivado, o pedido tem de conter o x-ms-access-tier cabeçalho, que indica a camada do blob de destino. O blob de destino tem de estar numa camada online. Não pode copiar para um blob na camada de arquivo.

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

O pedido poderá falhar se o blob de origem estiver a ser reidratado.

Para obter informações detalhadas sobre as camadas ao nível do blob de blocos, veja Camadas de armazenamento frequente, esporádico e de arquivo.

Trabalhar 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, utilize a tabela seguinte para determinar o passo seguinte com base no código de estado devolvido:

Código de estado	Significado
202 (Aceite), x-ms-copy-status: success	A operação de cópia foi concluída com êxito.
202 (Aceite), x-ms-copy-status: pendente	A operação de cópia ainda não foi concluída. Consulte o blob de destino utilizando `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	A operação de cópia falhou.

Durante e após uma Copy Blob operação, as propriedades do blob de destino contêm o ID de cópia da operação e o Copy Blob URL do blob de origem. Quando a operação for concluída, o Armazenamento de Blobs escreve o valor de hora 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 contém uma cadeia de detalhes do 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 excede o tempo limite e deixa um blob vazio com o x-ms-copy-status campo definido como failed 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 a falha. Nestes casos, x-ms-copy-status-description descreve os erros intermitentes.

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

Se 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. 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, utilize a seguinte tabela para determinar o estado da operação de cópia:

Código de estado	Significado
202 (Aceite), x-ms-copy-status: success	A operação de cópia foi concluída com êxito.
4xx, 500 ou 503	A operação de cópia falhou.

A camada é herdada para camadas de armazenamento premium. Para blobs de blocos, substituir o blob de destino herdará a camada frequente ou esporádica 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 as camadas ao nível do blob de blocos, veja Camadas de armazenamento frequente, esporádico e de arquivo.

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Copy Blob pedidos com base no tipo de conta de armazenamento:

Operação	Tipo de conta de armazenamento	Categoria de faturação
Copiar Blob (conta de destino¹)	Blob de blocos Premium Standard para fins gerais v2 Standard para fins gerais v1	Operações de escrita
Copiar Blob (conta de^{origem 2})	Blob de blocos Premium Standard para fins gerais v2 Standard para fins gerais v1	Operações de leitura

¹A conta de destino é cobrada por uma transação para iniciar a escrita.
²Quando o objeto de origem está numa conta diferente, a conta de origem incorre numa transação para cada pedido de leitura para o objeto de origem.

Para saber mais sobre os preços das categorias de faturação especificadas, veja Preços do Armazenamento de Blobs do Azure.

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

Além disso, se as contas de origem e de destino residiram em regiões diferentes (por exemplo, E.U.A. Norte e E.U.A. Sul), a largura de banda que utiliza para transferir o pedido é cobrada para a conta de armazenamento de origem como saída. A saída entre contas na mesma região é gratuita.

Quando copia um blob de origem para um blob de destino com um nome diferente na mesma conta, utiliza recursos de armazenamento adicionais para o novo blob. Em seguida, a operação de cópia resulta numa cobrança relativamente à utilização 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 na mesma conta (por exemplo, quando promove um instantâneo para o respetivo blob base), não são cobrados custos adicionais, exceto os metadados de cópia extra armazenados na versão 2012-02-12 e posterior.

Quando promove um instantâneo para substituir o respetivo blob base, o instantâneo e o blob base tornam-se idênticos. Partilham blocos ou páginas, pelo que a operação de cópia não resulta num custo adicional relativamente à utilização de capacidade da conta de armazenamento. No entanto, se copiar um instantâneo para um blob de destino com um nome diferente, essa operação implica um custo adicional para os recursos de armazenamento que o novo blob resultante utiliza. Dois blobs com nomes diferentes não podem partilhar blocos ou páginas, mesmo que sejam idênticos. Para obter mais informações sobre cenários de custos de instantâneos, veja Compreender como os instantâneos acumulam custos.

Ver também

Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro
Códigos de erro do Armazenamento de Blobs
Compreender como os instantâneos acumulam custos
Abortar Blob de Cópia