Copy Blob

Articolo
02/07/2024

Tramite l'operazione Copy Blob viene copiato un Blob in una destinazione nell'account di archiviazione.

Nella versione 2012-02-12 e successive, l'origine per un'operazione Copy Blob può essere un BLOB di cui è stato eseguito il commit in qualsiasi account di archiviazione di Azure.

A partire dalla versione 2015-02-21, l'origine per un'operazione Copy Blob può essere un file di Azure in qualsiasi account di archiviazione di Azure.

Nota

Solo gli account di archiviazione creati il 7 giugno 2012 consentono l'operazione Copy Blob di copia da un altro account di archiviazione.

Richiesta

È possibile costruire la Copy Blob richiesta come indicato di seguito. È consigliabile usare HTTPS. Sostituire myaccount con il nome dell'account di archiviazione, mycontainer con il nome del contenitore e myblob con il nome del BLOB di destinazione.

A partire dalla versione 2013-08-15, è possibile specificare una firma di accesso condiviso per il BLOB di destinazione se si trova nello stesso account del BLOB di origine. A partire dalla versione 2015-04-05, è anche possibile specificare una firma di accesso condiviso per il BLOB di destinazione se si trova in un account di archiviazione diverso.

URI della richiesta del metodo PUT	Versione HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob`	HTTP/1.1

URI per il servizio di archiviazione emulato

Quando si effettua una richiesta per il servizio di archiviazione emulato, specificare il nome host dell'emulatore e Archiviazione BLOB di Azure porta come 127.0.0.1:10000, seguito dal nome dell'account di archiviazione emulato:

URI della richiesta del metodo PUT	Versione HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

Per altre informazioni, vedere Usare l'emulatore Azurite per lo sviluppo locale di Archiviazione di Azure.

Parametri URI

Nell'URI della richiesta puoi specificare i parametri seguenti:

Parametro	Descrizione
`timeout`	Facoltativa. Il parametro `timeout` viene espresso in secondi. Per altre informazioni, vedere Impostare i timeout per le operazioni di archiviazione BLOB.

Intestazioni della richiesta

La tabella seguente descrive le intestazioni di richiesta obbligatorie e facoltative:

Intestazione della richiesta	Descrizione
`Authorization`	Obbligatorio. Specifica lo schema di autorizzazione, il nome dell'account e la firma. Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`Date` o `x-ms-date`	Obbligatorio. Specifica la data per la richiesta nel fuso orario UTC (Coordinated Universal Time). Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`x-ms-version`	Obbligatorio per tutte le richieste autorizzate. Per altre informazioni, vedere Controllo delle versioni per i servizi di archiviazione di Azure.
`x-ms-meta-name:value`	facoltativo. Specifica una coppia nome/valore definita dall'utente associata al BLOB. Se non vengono specificate coppie nome/valore, l'operazione copia i metadati dal BLOB o dal file di origine al BLOB di destinazione. Se vengono specificate una o più coppie nome/valore, il BLOB di destinazione viene creato con i metadati specificati e i metadati non vengono copiati dal BLOB o dal file di origine. A partire dalla versione 2009-09-19, i nomi dei metadati devono rispettare le regole di denominazione per gli identificatori C#. Per altre informazioni, vedere Denominazione e riferimento a contenitori, BLOB e metadati.
`x-ms-tags`	facoltativo. Imposta i tag con codifica query-stringa specificati nel BLOB. I tag non vengono copiati dall'origine di copia. Per altre informazioni, vedere Osservazioni. Supportato nella versione 2019-12-12 e successive.
`x-ms-source-if-modified-since`	facoltativo. Valore `DateTime`. Specificare questa intestazione condizionale per copiare il Blob solo se il Blob di origine è stato modificato dopo la data e l'ora specificate. Se il BLOB di origine non è stato modificato, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita). Non è possibile specificare questa intestazione se l'origine è un file di Azure.
`x-ms-source-if-unmodified-since`	facoltativo. Valore `DateTime`. Specificare questa intestazione condizionale per copiare il Blob solo se il Blob di origine non è stato modificato dopo la data e l'ora specificate. Se il BLOB di origine è stato modificato, l'archiviazione BLOB restituisce il codice di stato 412 (precondizione non riuscita). Non è possibile specificare questa intestazione se l'origine è un file di Azure.
`x-ms-source-if-match`	facoltativo. Valore `ETag`. Specificare questa intestazione condizionale per copiare il BLOB di origine solo se il relativo `ETag` valore corrisponde al valore specificato. Se i valori non corrispondono, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita). Non è possibile specificare questa intestazione se l'origine è un file di Azure.
`x-ms-source-if-none-match`	facoltativo. Valore `ETag`. Specificare questa intestazione condizionale per copiare il BLOB solo se il relativo `ETag` valore non corrisponde al valore specificato. Se i valori sono identici, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita). Non è possibile specificare questa intestazione se l'origine è un file di Azure.
`If-Modified-Since`	facoltativo. Valore `DateTime`. Specificare questa intestazione condizionale per copiare il Blob solo se il Blob di destinazione è stato modificato dopo la data e l'ora specificate. Se il BLOB di destinazione non è stato modificato, l'archiviazione BLOB restituisce il codice di stato 412 (precondizione non riuscita).
`If-Unmodified-Since`	facoltativo. Valore `DateTime`. Specificare questa intestazione condizionale per copiare il Blob solo se il Blob di destinazione non è stato modificato dopo la data e l'ora specificate. Se il BLOB di destinazione è stato modificato, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita).
`If-Match`	facoltativo. Valore `ETag`. Specificare un `ETag` valore per questa intestazione condizionale per copiare il BLOB solo se il valore specificato `ETag` corrisponde al `ETag` valore per un BLOB di destinazione esistente. Se i valori non corrispondono, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita).
`If-None-Match`	facoltativo. Valore `ETag` o carattere jolly (). Specificare un `ETag` valore per questa intestazione condizionale per copiare il BLOB solo se il valore specificato `ETag` non corrisponde al `ETag` valore per il BLOB di destinazione. Specificare il carattere jolly () per eseguire l'operazione solo se il BLOB di destinazione non esiste. Se la condizione specificata non viene soddisfatta, Archiviazione BLOB restituisce il codice di stato 412 (precondizione non riuscita).
`x-ms-copy-source:name`	Obbligatorio. Specifica il nome del BLOB o del file di origine. A partire dalla versione 2012-02-12, questo valore può essere un URL di lunghezza massima di 2 kibibyte (KiB) che specifica un BLOB. Il valore deve essere codificato con URL come verrebbe visualizzato in un URI della richiesta. L'operazione di lettura in un BLOB di origine nello stesso account di archiviazione può essere autorizzata tramite chiave condivisa. A partire dalla versione 2017-11-09, è anche possibile usare Microsoft Entra ID per autorizzare l'operazione di lettura nel BLOB di origine. Tuttavia, se l'origine è un BLOB in un altro account di archiviazione, il BLOB di origine deve essere pubblico o l'accesso a tale BLOB deve essere autorizzato tramite una firma di accesso condiviso. Se il BLOB di origine è pubblico, non è necessaria alcuna autorizzazione per eseguire l'operazione di copia. A partire dalla versione 2015-02-21, l'oggetto di origine può essere un file in File di Azure. Se l'oggetto di origine è un file copiato in un BLOB, il file di origine deve essere autorizzato tramite una firma di accesso condiviso, indipendentemente dal fatto che si trovi nello stesso account o in un account diverso. Solo gli account di archiviazione creati o dopo il 7 giugno 2012 consentono di copiare l'operazione `Copy Blob` da un altro account di archiviazione. Ecco alcuni esempi di URL dell'oggetto di origine: - `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 l'oggetto di origine è un file in File di Azure, l'URL di origine usa il formato seguente. Si noti che l'URL deve includere un token di firma di accesso condiviso valido per il file. - `https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken` Nelle versioni precedenti al 2012-02-12, i BLOB possono essere copiati solo all'interno dello stesso account e un nome di origine può usare questi formati: - BLOB nel contenitore denominato: `/accountName/containerName/blobName` - Snapshot nel contenitore denominato: `/accountName/containerName/blobName?snapshot=<DateTime>` - BLOB nel contenitore radice: `/accountName/blobName` - Snapshot nel contenitore radice: `/accountName/blobName?snapshot=<DateTime>`
`x-ms-lease-id:<ID>`	Obbligatoria se il Blob di destinazione presenta un lease attivo. L'ID lease specificato per questa intestazione deve corrispondere all'ID lease del Blob di destinazione. Se la richiesta non include l'ID lease o l'ID non è valido, l'operazione non riesce con il codice di stato 412 (Precondizione non riuscita). Se questa intestazione è specificata e il BLOB di destinazione non ha attualmente un lease attivo, l'operazione non riesce con il codice di stato 412 (Precondizione non riuscita). Nella versione 2012-02-12 e versioni successive, questo valore deve specificare un lease infinito attivo per un BLOB in lease lease. Un ID lease di durata limitata non riesce con il codice di stato 412 (Precondizione non riuscita).
`x-ms-source-lease-id: <ID>`	Facoltativo per le versioni precedenti al 2012-02-12 (non supportato nel 2012-02-12 e versioni successive). Specificare questa intestazione per eseguire l'operazione `Copy Blob` solo se l'ID lease specificato corrisponde all'ID lease attivo del BLOB di origine. Se questa intestazione è specificata e il BLOB di origine non ha attualmente un lease attivo, l'operazione non riesce con il codice di stato 412 (Precondizione non riuscita).
`x-ms-client-request-id`	facoltativo. Fornisce un valore opaco generato dal client con un limite di caratteri 1 KiB registrato nei log quando la registrazione è configurata. È consigliabile usare questa intestazione per correlare le attività lato client con le richieste ricevute dal server.
`x-ms-access-tier`	facoltativo. Specifica il livello da impostare nel BLOB di destinazione. Questa intestazione è per i BLOB di pagine in un account Premium solo con la versione 2017-04-17 e versioni successive. Per un elenco completo dei livelli supportati, vedere Archiviazione Premium ad alte prestazioni e dischi gestiti per le macchine virtuali. Questa intestazione è supportata nella versione 2018-11-09 e successiva per i BLOB a blocchi. La suddivisione in livelli BLOB in blocchi è supportata in Archiviazione BLOB o per utilizzo generico account v2. I valori validi sono `Hot`, `ColdCool`e `Archive`. Nota:`Cold` il livello è supportato per la versione 2021-12-02 e successiva. Per informazioni dettagliate sul livello BLOB a blocchi, vedere Livelli di archiviazione ad accesso frequente, sporadico e archivio.
`x-ms-rehydrate-priority`	facoltativo. Indica la priorità con cui riattivare un BLOB archiviato. Questa intestazione è supportata nella versione 2019-02-02 e successiva per i BLOB a blocchi. I valori validi sono `High` e `Standard`. È possibile impostare la priorità su un BLOB una sola volta. Questa intestazione verrà ignorata nelle richieste successive allo stesso BLOB. La priorità predefinita senza questa intestazione è `Standard`.
`x-ms-seal-blob`	facoltativo. Supportato nella versione 2019-12-12 o successiva. Questa intestazione è valida solo per i BLOB di accodamento. Si blocca il BLOB di destinazione al termine dell'operazione di copia.
`x-ms-immutability-policy-until-date`	Versione 2020-06-12 e versioni successive. Specifica la data di conservazione fino alla data da impostare nel BLOB. Questa è la data fino alla quale il BLOB può essere protetto dalla modifica o dall'eliminazione. Segue RFC1123 formato.
`x-ms-immutability-policy-mode`	Versione 2020-06-12 e versioni successive. Specifica la modalità dei criteri di non modificabilità da impostare nel BLOB. I valori validi sono `unlocked` e `locked`. Un `unlocked` valore indica che l'utente può modificare il criterio aumentando o riducendo la data di conservazione. Un `locked` valore indica che queste azioni sono vietate.
`x-ms-legal-hold`	Versione 2020-06-12 e versioni successive. Specifica il blocco legale da impostare nel BLOB. I valori validi sono `true` e `false`.

Questa operazione supporta le x-ms-if-tags intestazioni condizionali e x-ms-source-if-tags per avere esito positivo solo se la condizione specificata viene soddisfatta. Per altre informazioni, vedere Specificare intestazioni condizionali per le operazioni di archiviazione BLOB.

Testo della richiesta

Nessuno.

Risposta

Nella risposta sono inclusi un codice di stato HTTP e un set di intestazioni per la risposta.

Codice stato

Nella versione 2012-02-12 e successiva, un'operazione con esito positivo restituisce il codice di stato 202 (accettato).

Nelle versioni precedenti alla 2012-02-12, un'operazione completata correttamente restituisce il codice di stato 201 (Creato).

Per informazioni sui codici di stato, vedere Codici di stato e di errore.

Intestazioni di risposta

Nella risposta per questa operazione sono incluse le intestazioni riportate di seguito; Nella risposta possono anche essere incluse intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1.

Intestazione risposta	Descrizione
`ETag`	Nella versione 2012-02-12 e successiva, se la copia è completata, questa intestazione contiene il `ETag` valore del BLOB di destinazione. Se la copia non è completa, l'intestazione contiene il `ETag` valore del BLOB vuoto creato all'inizio dell'operazione di copia. Nelle versioni precedenti al 2012-02-12, questa intestazione restituisce il `ETag` valore per il BLOB di destinazione. Nella versione 2011-08-18 e successiva, il `ETag` valore è tra virgolette.
`Last-Modified`	Restituisce la data/ora in cui è stata completata l'operazione di copia nel BLOB di destinazione.
`x-ms-request-id`	Identifica in modo univoco la richiesta effettuata. È possibile usare questa intestazione per risolvere i problemi della richiesta. Per altre informazioni, vedere Risolvere i problemi relativi alle operazioni api.
`x-ms-version`	Indica la versione dell'archiviazione BLOB usata per eseguire la richiesta. Questa intestazione viene restituita per le richieste effettuate nella versione 2009-09-19 e successive.
`Date`	Valore di data/ora UTC che indica l'ora in cui il servizio ha inviato la risposta.
`x-ms-copy-id: <id>`	Versione 2012-02-12 e versioni successive. Fornisce un identificatore di stringa per questa operazione di copia. Usare o `Get BlobGet Blob Properties` per controllare lo stato di questa operazione di copia o passare a `Abort Copy Blob` per annullare un'operazione di copia in sospeso.
`x-ms-copy-status: <success ¦ pending>`	Versione 2012-02-12 e versioni successive. Indica lo stato dell'operazione di copia, con questi valori: - `success`: l'operazione è stata completata correttamente. - `pending`: l'operazione è in corso.
`x-ms-version-id: <DateTime>`	Versione 2019-12-12 e successiva. Identifica in modo univoco il BLOB in base alla relativa versione. È possibile usare questo valore opaco nelle richieste successive per accedere a questa versione del BLOB.
`x-ms-client-request-id`	Può essere usato per risolvere le richieste e le risposte corrispondenti. Il valore di questa intestazione è uguale al valore dell'intestazione `x-ms-client-request-id` , se presente nella richiesta e il valore è al massimo 1.024 caratteri ASCII visibili. Se l'intestazione `x-ms-client-request-id` non è presente nella richiesta, questa intestazione non sarà presente nella risposta.

Corpo della risposta

Nessuno.

Risposta di esempio

Il codice seguente è una risposta di esempio per una richiesta di copia di un 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>

Autorizzazione

L'autorizzazione è necessaria quando si chiama qualsiasi operazione di accesso ai dati in Archiviazione di Azure. La tabella seguente descrive come è possibile autorizzare gli oggetti di destinazione e di origine per un'operazione Copy Blob :

Tipo oggetto	autorizzazione Microsoft Entra ID	Autorizzazione firma di accesso condiviso (SAS)	Autorizzazione chiave condivisa (o Shared Key Lite)
BLOB di destinazione	Sì	Sì	Sì
BLOB di origine nello stesso account di archiviazione	Sì	Sì	Sì
BLOB di origine in un altro account di archiviazione	No	Sì	No

Se una richiesta specifica i tag nell'intestazione della richiesta, il chiamante deve soddisfare i requisiti di autorizzazione dell'operazione x-ms-tagsImposta tag BLOB .

È possibile autorizzare l'operazione Copy Blob come descritto di seguito. Si noti che un BLOB di origine in un account di archiviazione diverso deve essere autorizzato separatamente tramite token di firma di accesso condiviso con l'autorizzazione Read (r). Per altre informazioni sull'autorizzazione BLOB di origine, vedere i dettagli per l'intestazione x-ms-copy-sourcedella richiesta .

Archiviazione di Azure supporta l'uso di Microsoft Entra ID per autorizzare le richieste ai dati BLOB. Con Microsoft Entra ID è possibile usare il controllo degli accessi in base al ruolo di Azure per concedere le autorizzazioni a un'entità di sicurezza. L'entità di sicurezza può essere un utente, un gruppo, un'entità servizio applicazione o un'identità gestita di Azure. L'entità di sicurezza viene autenticata da Microsoft Entra ID per restituire un token OAuth 2.0. Il token può quindi essere usato per autorizzare una richiesta relativa al servizio BLOB.

Per altre informazioni sull'autorizzazione usando Microsoft Entra ID, vedere Autorizzare l'accesso ai BLOB usando Microsoft Entra ID.

Autorizzazioni

Di seguito è riportata l'azione RBAC necessaria per un utente, un gruppo o un'entità servizio di Microsoft Entra per chiamare l'operazione Copy Blob e il ruolo di controllo degli accessi in base al ruolo predefinito di Azure con privilegi minimi che include questa azione:

BLOB di destinazione

Azione RBAC di Azure:Microsoft.Storage/storageAccounts/BLOBServices/containers /blobs/write (per la scrittura in un BLOB esistente) o Microsoft.Storage/storageAccounts/BLOBServices/containers /blobs/add/action (per scrivere un nuovo BLOB nella destinazione)
Ruolo predefinito con privilegi minimi:Collaboratore ai dati BLOB di archiviazione

BLOB di origine all'interno dello stesso account di archiviazione

Azione controllo degli accessi in base al ruolo di Azure:Microsoft.Storage/storageAccounts/BLOBServices/containers/BLOBs/read
Ruolo predefinito con privilegi minimi:Lettore dati BLOB di archiviazione

Per altre informazioni sull'assegnazione dei ruoli tramite controllo degli accessi in base al ruolo di Azure, vedere Assegnare un ruolo di Azure per l'accesso ai dati BLOB.

Una firma di accesso condiviso (SAS) offre accesso delegato sicuro alle risorse in un account di archiviazione. Con una firma di accesso condiviso è disponibile un controllo granulare sul modo in cui un client può accedere ai dati. È possibile specificare la risorsa a cui può accedere il client, le autorizzazioni necessarie per tali risorse e il tempo di validità della firma di accesso condiviso.

L'operazione Copy Blob supporta tre tipi di firme di accesso condiviso: firma di accesso condiviso con delega utente, firma di accesso condiviso e firma di accesso condiviso.

Come procedura consigliata per la sicurezza, è consigliabile usare le credenziali Microsoft Entra anziché la chiave dell'account di archiviazione, che può essere più facilmente compromessa. Se la progettazione dell'applicazione richiede firme di accesso condiviso, usare Microsoft Entra credenziali per creare una firma di accesso condiviso di delega utente, quando possibile.

Quando l'accesso a chiave condivisa non è consentito per l'account di archiviazione, un token di firma di accesso condiviso del servizio o un token di firma di accesso condiviso dell'account non sarà consentito in una richiesta di archiviazione BLOB. Per altre informazioni, vedere Informazioni su come impedire la condivisione della chiave condivisa influisce sui token di firma di accesso condiviso.

Firma di accesso condiviso di delega utente

Una firma di accesso condiviso di delega utente è protetta con le credenziali di Microsoft Entra e anche dalle autorizzazioni specificate per la firma di accesso condiviso.

La chiamata all'operazione Copy Blob tramite un token di firma di accesso condiviso delegata a una risorsa BLOB richiede l'autorizzazione seguente come parte del token di firma di accesso condiviso della delega utente.

Operazione	Tipo oggetto	Autorizzazione firmata
Copy Blob	BLOB di destinazione (nuovo)	Creare (c) o Write (w)
Copy Blob	BLOB di destinazione (esistente)	Scrittura (w)
Copy Blob	BLOB di origine (all'interno dello stesso account di archiviazione)	Lettura (r)
Copy Blob	BLOB di origine (in account di archiviazione diverso)	Lettura (r)

Per altre informazioni sulla firma di accesso condiviso di delega utente, vedere Creare una firma di accesso condiviso di delega utente.

Firma di accesso condiviso del servizio

Una firma di accesso condiviso del servizio è protetta con la chiave dell'account di archiviazione. Una firma di accesso condiviso del servizio delega l'accesso a una risorsa in un singolo servizio di archiviazione di Azure, ad esempio l'archiviazione BLOB.

Operazione	Tipo oggetto	Autorizzazione firmata
Copy Blob	BLOB di destinazione (nuovo)	Creare (c) o Write (w)
Copy Blob	BLOB di destinazione (esistente)	Scrittura (w)
Copy Blob	BLOB di origine (all'interno dello stesso account di archiviazione)	Lettura (r)
Copy Blob	BLOB di origine (in account di archiviazione diverso)	Lettura (r)

Per altre informazioni sulla firma di accesso condiviso del servizio, vedere Creare una firma di accesso condiviso del servizio.

Firma di accesso condiviso dell'account

Una firma di accesso condiviso dell'account è protetta con la chiave dell'account di archiviazione. Una firma di accesso condiviso dell'account delega l'accesso alle risorse in uno o più servizi di archiviazione. Tutte le operazioni disponibili tramite una firma di accesso condiviso del servizio o di delega utente sono disponibili anche tramite una firma di accesso condiviso dell'account.

La tabella seguente indica il tipo di risorsa firmato e le autorizzazioni firmate per specificare quando delega l'accesso:

Operazione	Tipo oggetto	Servizio firmato	Tipo di risorsa firmato	Autorizzazione firmata
Copy Blob	BLOB di destinazione (nuovo)	BLOB (b)	Oggetto (o)	Creare (c) o Write (w)
Copy Blob	BLOB di destinazione (esistente)	BLOB (b)	Oggetto (o)	Scrittura (w)
Copy Blob	BLOB di origine (all'interno dello stesso account di archiviazione)	BLOB (b)	Oggetto (o)	Lettura (r)
Copy Blob	BLOB di origine (in account di archiviazione diverso)	BLOB (b)	Oggetto (o)	Lettura (r)

Per altre informazioni sulla firma di accesso condiviso dell'account, vedere Creare una firma di accesso condiviso dell'account.

Commenti

Nella versione 2012-02-12 e successiva l'operazione Copy Blob può terminare in modo asincrono. Questa operazione restituisce un ID di copia che è possibile usare per controllare o annullare l'operazione di copia. A causa della natura asincrona dell'operazione di copia, l'archiviazione BLOB copia i BLOB su base ottimale. Il servizio BLOB copia i BLOB quando le risorse del server non vengono usate da altre attività, quindi una copia non è garantita l'avvio immediato o il completamento in un intervallo di tempo specificato.

Il BLOB di origine per un'operazione di copia può essere un BLOB a blocchi, un BLOB di accodamento, un BLOB di pagine o uno snapshot. Se il Blob di destinazione esiste già, deve essere dello stesso tipo del Blob di origine. Eventuali Blob di destinazione esistenti verranno sovrascritti. Non è possibile modificare il BLOB di destinazione mentre è in corso un'operazione di copia.

Nella versione 2015-02-21 e successiva, l'origine per l'operazione di copia può anche essere un file in File di Azure. Se l'origine è un file, la destinazione deve essere un BLOB a blocchi.

Più operazioni Copy Blob in sospeso in un account possono essere elaborate in sequenza. Un BLOB di destinazione può avere una sola operazione in sospeso Copy Blob . In altre parole, un BLOB non può essere la destinazione per più operazioni in sospeso Copy Blob . Tentativo di copiare un BLOB in un BLOB di destinazione che dispone già di un'operazione di copia in sospeso non riesce con il codice di stato 409 (Conflitto).

Solo gli account di archiviazione creati o dopo il 7 giugno 2012 consentono di copiare l'operazione Copy Blob da un altro account di archiviazione. Un tentativo di copia da un altro account di archiviazione a un account creato prima del 7 giugno 2012 non riesce con il codice di stato 400 (richiesta non valida).

L'operazione Copy Blob copia sempre l'intero BLOB di origine o il file. La copia di un intervallo di byte o set di blocchi non è supportata.

Un'operazione Copy Blob può assumere una delle forme riportate di seguito:

È possibile copiare un BLOB di origine in un BLOB di destinazione con un nome diverso. Il BLOB di destinazione può essere un BLOB esistente dello stesso tipo di BLOB (blocco, accodamento o pagina) oppure può essere un nuovo BLOB creato dall'operazione di copia.
È possibile copiare un BLOB di origine in un BLOB di destinazione con lo stesso nome, sostituendo in modo efficace il BLOB di destinazione. Un'operazione di copia di questo tipo comporta la rimozione dei blocchi di cui non è stato eseguito il commit e la sovrascrittura dei metadati del Blob.
È possibile copiare un file di origine in File di Azure in un BLOB di destinazione. Il BLOB di destinazione può essere un BLOB a blocchi esistente oppure può essere un nuovo BLOB a blocchi creato dall'operazione di copia. La copia da file a BLOB di pagine o BLOB di accodamento non è supportata.
È possibile copiare uno snapshot sul relativo BLOB di base. Promuovendo uno snapshot alla posizione del BLOB di base, è possibile ripristinare la versione precedente di un BLOB.
È possibile copiare uno snapshot in un BLOB di destinazione con un nome diverso. Il BLOB di destinazione risultante è un BLOB scrivibile, non uno snapshot.

Quando si esegue la copia da un BLOB di pagine, Archiviazione BLOB crea un BLOB di pagine di destinazione della lunghezza del BLOB di origine. Inizialmente, il BLOB di pagine contiene tutti gli zero. Verranno enumerati gli intervalli di pagine di origine e verranno copiati gli intervalli non vuoti.

Per un BLOB a blocchi o un BLOB di accodamento, l'archiviazione BLOB crea un BLOB di commit di lunghezza zero prima di restituire da questa operazione.

Quando si esegue la copia da un BLOB a blocchi, vengono copiati tutti i blocchi di commit e i relativi ID blocco. I blocchi non inviati non vengono copiati. Alla fine dell'operazione di copia, il BLOB di destinazione ha lo stesso numero di blocchi commit dell'origine.

Quando si esegue la copia da un BLOB di accodamento, tutti i blocchi di commit vengono copiati. Alla fine dell'operazione di copia, il BLOB di destinazione avrà meno o lo stesso numero di blocchi commit del BLOB di origine.

Per tutti i tipi di BLOB, è possibile chiamare Get Blob o Get Blob Properties nel BLOB di destinazione per controllare lo stato dell'operazione di copia. Il BLOB finale verrà eseguito il commit al termine dell'operazione di copia.

Quando l'origine di un'operazione di copia fornisce ETag valori, le modifiche apportate all'origine mentre l'operazione di copia è in corso causerà l'esito negativo dell'operazione. Un tentativo di modificare il BLOB di destinazione mentre una copia è in corso avrà esito negativo con il codice di stato 409 (Conflitto). Se il Blob di destinazione presenta un lease infinito, il relativo ID deve essere passato a Copy Blob. I lease di durata finita non sono consentiti.

Il ETag valore per un BLOB a blocchi viene modificato all'avvio dell'operazione Copy Blob e al termine dell'operazione. Il ETag valore per un BLOB di pagine viene modificato all'avvio dell'operazione e continua a cambiare spesso durante l'operazione Copy Blob di copia. Il contenuto di un BLOB a blocchi è visibile tramite un Get comando solo dopo il completamento dell'operazione di copia completa.

Copia di proprietà, tag e metadati del BLOB

Quando viene copiato un BLOB, le proprietà di sistema seguenti vengono copiate nel BLOB di destinazione con gli stessi valori:

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition
x-ms-blob-sequence-number (solo per BLOB di pagine)
x-ms-committed-block-count (solo per aggiungere BLOB e solo per la versione 2015-02-21)

L'elenco di blocchi commit del BLOB di origine viene copiato anche nel BLOB di destinazione, se il BLOB è un BLOB a blocchi. Eventuali blocchi di cui non è stato eseguito il commit non vengono copiati.

Il BLOB di destinazione è sempre la stessa dimensione del BLOB di origine. Il valore dell'intestazione Content-Length per il BLOB di destinazione corrisponde al valore di tale intestazione per il BLOB di origine.

Se il Blob di origine equivale al Blob di destinazione, l'operazione Copy Blob comporta la rimozione di eventuali blocchi di cui è stato eseguito il commit. Se si specificano i metadati, i metadati esistenti vengono sovrascritti con quelli nuovi.

Se l'intestazione fornisce tag per il x-ms-tags BLOB di destinazione, devono essere codificati con stringa di query. Le chiavi e i valori dei tag devono essere conformi ai requisiti di denominazione e lunghezza, come specificato in Imposta tag BLOB.

L'intestazione x-ms-tags può contenere fino a 2 kilobit di tag. Se sono necessari altri tag, usare l'operazione Set Blob Tags .

Se l'intestazione x-ms-tags non fornisce tag, i tag non vengono copiati dal BLOB di origine.

Copia di un BLOB lease

L'operazione Copy Blob legge solo dal BLOB di origine, quindi lo stato del lease del BLOB di origine non è importante. Tuttavia, l'operazione Copy Blob salva il ETag valore del BLOB di origine all'avvio dell'operazione di copia. Se il valore cambia prima del completamento dell'operazione ETag di copia, l'operazione ha esito negativo. È possibile impedire modifiche al Blob di origine ponendo un lease su di esso durante l'operazione di copia.

Se il Blob di destinazione presenta un lease infinito attivo, è necessario specificare il relativo ID nella chiamata all'operazione Copy Blob. Se il lease specificato è un lease di durata limitata attiva, questa chiamata non riesce con un codice di stato 412 (Precondizione non riuscita). Mentre l'operazione di copia è in sospeso, qualsiasi operazione di lease nel BLOB di destinazione non riesce con il codice di stato 409 (Conflitto). Un lease infinito nel BLOB di destinazione viene bloccato in questo modo durante l'operazione di copia se si esegue la copia in un BLOB di destinazione con un nome diverso dall'origine, copiando in un BLOB di destinazione con lo stesso nome dell'origine o promuovendo uno snapshot nel BLOB di base.

Se il client specifica un ID lease in un BLOB che non esiste ancora, l'archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita) per le richieste effettuate rispetto alla versione 2013-08-15 e versioni successive. Per le versioni precedenti, Archiviazione BLOB restituisce il codice di stato 201 (Creato).

Copia di snapshot BLOB

Quando viene copiato un BLOB di origine, gli snapshot o le versioni del BLOB di origine non vengono copiati nella destinazione. Quando un BLOB di destinazione viene sovrascritto con una copia, gli snapshot o le versioni associati al BLOB di destinazione rimangono intatti sotto il nome.

È possibile eseguire un'operazione di copia per promuovere uno snapshot sul BLOB di base, purché si trovi in un livello online (ad accesso frequente o sporadico). In questo modo è possibile ripristinare una versione precedente di un BLOB. Lo snapshot viene mantenuto, ma la relativa destinazione viene sovrascritta con una copia che potrà essere letta e scritta.

Copia di versioni BLOB

È possibile eseguire un'operazione di copia per promuovere una versione sul BLOB di base, purché si trovi in un livello online (ad accesso frequente o sporadico). In questo modo è possibile ripristinare una versione precedente di un BLOB. La versione rimane, ma la destinazione viene sovrascritta con una copia che può essere sia di lettura che di scrittura.

Copia di un BLOB archiviato

A partire dalla versione 2018-11-09, è possibile copiare un BLOB archiviato in un nuovo BLOB all'interno dello stesso account di archiviazione. Il BLOB di origine rimane nel livello di archiviazione. Quando il BLOB di origine è un BLOB archiviato, la richiesta deve contenere l'intestazione x-ms-access-tier , che indica il livello del BLOB di destinazione. Il BLOB di destinazione deve trovarsi in un livello online. Non è possibile copiare in un BLOB nel livello di archivio.

A partire dalla versione 2021-02-12, è possibile copiare un BLOB archiviato in un livello online in un account di archiviazione diverso, purché l'account di destinazione si trovi nella stessa area dell'account di origine.

La richiesta potrebbe non riuscire se il BLOB di origine viene reidratato.

Per informazioni dettagliate sul livello del BLOB a blocchi, vedere Livelli di archiviazione ad accesso frequente, sporadico e archivio.

Uso di un'operazione di copia in sospeso (versione 2012-02-12 e successiva)

Se l'operazione termina in modo asincrono, usare la Copy Blob tabella seguente per determinare il passaggio successivo in base al codice di stato restituito:

Codice stato	Significato
202 (Accettato), x-ms-copy-status: success	Operazione di copia completata correttamente.
202 (Accettato), x-ms-copy-status: pending	L'operazione di copia non è stata completata. Eseguire il polling del BLOB di destinazione usando `Get Blob Properties` per esaminare l'intestazione finché l'operazione `x-ms-copy-status` non viene completata o non riesce.
4xx, 500 o 503	Operazione di copia non riuscita.

Durante e dopo un'operazione Copy Blob, le proprietà del Blob di destinazione contengono l'ID copia dell'operazione Copy Blob e l'URL del Blob di origine. Al termine dell'operazione, Archiviazione BLOB scrive il valore di tempo e risultato (success, failedo aborted) nelle proprietà del BLOB di destinazione. Se l'operazione ha un risultato, l'intestazione x-ms-copy-status-description contiene una failed stringa di dettaglio errore.

Un'operazione in sospeso Copy Blob ha un timeout di due settimane. Tentativo di copia che non è stato completato dopo due settimane di timeout e lascia un BLOB vuoto con il x-ms-copy-status campo impostato su failed e il x-ms-copy-status-description set su 500 (OperationCancelled). Errori intermittenti e non irreversibili che possono verificarsi durante un'operazione di copia potrebbero impedire lo stato di avanzamento dell'operazione, ma non causarne l'esito negativo. In questi casi, gli errori intermittenti vengono descritti nell'intestazione x-ms-copy-status-description.

Qualsiasi tentativo di modifica o snapshot del BLOB di destinazione durante l'operazione di copia avrà esito negativo con il codice di stato 409 (conflitto), "Copia BLOB in corso".

Se si chiama l'operazione, verrà visualizzata un'intestazione Abort Copy Blobx-ms-copy-status:aborted . Il BLOB di destinazione avrà metadati intatti e una lunghezza del BLOB di 0 byte. È possibile ripetere la chiamata originale per Copy Blob provare di nuovo l'operazione di copia.

Se l'operazione termina in modo sincrono, usare la Copy Blob tabella seguente per determinare lo stato dell'operazione di copia:

Codice stato	Significato
202 (Accettato), x-ms-copy-status: success	Operazione di copia completata correttamente.
4xx, 500 o 503	Operazione di copia non riuscita.

Il livello viene ereditato per i livelli di archiviazione Premium. Per i BLOB in blocchi, sovrascrivere il BLOB di destinazione erediterà il livello ad accesso frequente o sporadico dalla destinazione se x-ms-access-tier non viene fornito. La sovrascrittura di un BLOB archiviato avrà esito negativo. Per informazioni dettagliate sul livello del BLOB a blocchi, vedere Livelli di archiviazione ad accesso frequente, sporadico e archivio.

Fatturazione

Le richieste di prezzi possono derivare dai client che usano le API di archiviazione BLOB, direttamente tramite l'API REST dell'archiviazione BLOB o da una libreria client di Archiviazione di Azure. Queste richieste accumulano addebiti per transazione. Il tipo di transazione influisce sul modo in cui viene addebitato l'account. Ad esempio, le transazioni di lettura si accumulano in una categoria di fatturazione diversa rispetto alle transazioni di scrittura. Nella tabella seguente viene illustrata la categoria di fatturazione per Copy Blob le richieste in base al tipo di account di archiviazione:

Operazione	Tipo di account di archiviazione	Categoria di fatturazione
Copia BLOB (account di destinazione¹)	BLOB di blocchi Premium Utilizzo generico v2 Standard Utilizzo generico standard v1	Operazioni di scrittura
Copia BLOB (account di origine²)	BLOB di blocchi Premium Utilizzo generico v2 Standard Utilizzo generico standard v1	Operazioni di lettura

¹L'account di destinazione viene addebitato per una transazione per avviare la scrittura.
²Quando l'oggetto di origine si trova in un account diverso, l'account di origine comporta una transazione per ogni richiesta di lettura all'oggetto di origine.

Per informazioni sui prezzi per le categorie di fatturazione specificate, vedere prezzi Archiviazione BLOB di Azure.

L'account di destinazione comporta anche i costi delle transazioni per ogni richiesta per annullare l'operazione di copia (vedere Abort Copy BLOB) o per controllare lo stato dell'operazione di copia (vedere Get BLOB o Get BLOB Properties).

Inoltre, se gli account di origine e di destinazione risiedono in aree diverse (ad esempio Stati Uniti settentrionali e Stati Uniti meridionali), la larghezza di banda usata per trasferire la richiesta viene addebitata all'account di archiviazione di origine come uscita. L'uscita tra account della stessa area geografica è gratuita.

Quando si copia un BLOB di origine in un BLOB di destinazione con un nome diverso nello stesso account, si usano risorse di archiviazione aggiuntive per il nuovo BLOB. L'operazione di copia comporta quindi un addebito rispetto all'utilizzo della capacità dell'account di archiviazione per tali risorse aggiuntive. Tuttavia, se i nomi dei BLOB di origine e di destinazione sono uguali all'interno dello stesso account (ad esempio, quando si promuove uno snapshot nel BLOB di base), non viene addebitato alcun addebito aggiuntivo, diverso dai metadati di copia aggiuntivi archiviati nella versione 2012-02-12 e versioni successive.

Quando si promuove uno snapshot per sostituire il relativo Blob di base, il Blob di base e lo snapshot sono identici. Poiché condividono blocchi o pagine, l'operazione di copia non comporta alcun costo aggiuntivo associato all'utilizzo della capacità dell'account di archiviazione. Tuttavia, se si copia uno snapshot in un BLOB di destinazione con un nome diverso, tale operazione comporta un addebito aggiuntivo per le risorse di archiviazione usate dal nuovo BLOB risultante. Due BLOB con nomi diversi non possono condividere blocchi o pagine, anche se sono identici. Per altre informazioni sugli scenari di costo snapshot, vedere Informazioni sul modo in cui gli snapshot accumulano addebiti.

Vedi anche

Autorizzare le richieste ad Archiviazione di Azure
Stato e codici errore
Codici di errore dell'archiviazione BLOB
Informazioni sul modo in cui gli snapshot accumulano addebiti
Abort Copy Blob