Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
È possibile abilitare il controllo delle versioni di archiviazione BLOB per mantenere automaticamente le versioni precedenti di un oggetto. Quando attivi la versione del blob, puoi accedere alle versioni precedenti di un blob per recuperare i tuoi dati se vengono modificati o cancellati.
Attenzione
Dopo aver abilitato il controllo delle versioni del BLOB per un account di archiviazione, ogni operazione di scrittura in un BLOB in tale account comporta la creazione di una nuova versione. Per questo motivo, abilitare il versioning dei blob potrebbe comportare costi aggiuntivi. Per ridurre al minimo i costi, usare criteri di gestione del ciclo di vita per eliminare automaticamente le versioni precedenti. Per altre informazioni sulla gestione del ciclo di vita, vedere Optimizzare i costi automatizzando i livelli di accesso Archiviazione BLOB di Azure.
Funzionamento del controllo delle versioni BLOB
Una versione acquisisce lo stato di un BLOB in un determinato momento. Ogni versione viene identificata con un ID versione. Quando il controllo delle versioni blob è abilitato per un account di archiviazione, Archiviazione di Azure crea automaticamente una nuova versione con un ID univoco quando viene creato un BLOB e ogni volta che il BLOB viene modificato successivamente.
Un ID versione può identificare la versione corrente o una versione precedente. Un BLOB può avere una sola versione corrente alla volta.
Quando si crea un nuovo BLOB, esiste una singola versione e tale versione è la versione corrente. Quando si modifica un BLOB esistente, la versione corrente diventa una versione precedente. Viene creata una nuova versione per acquisire lo stato aggiornato e tale nuova versione è la versione corrente. Quando si elimina un BLOB, la versione corrente del BLOB diventa una versione precedente e non è più disponibile una versione corrente. Tutte le versioni precedenti del BLOB vengono mantenute.
Il diagramma seguente illustra come vengono create le versioni nelle operazioni di scrittura e come una versione precedente può essere promossa come la versione corrente:
Importante
La presenza di un numero elevato di versioni per BLOB può aumentare la latenza per le operazioni di elenco di BLOB. Microsoft consiglia di mantenere meno di 1000 versioni per BLOB. È possibile usare la gestione del ciclo di vita per eliminare automaticamente le versioni precedenti. Per altre informazioni sulla gestione del ciclo di vita, vedere Optimizzare i costi automatizzando i livelli di accesso Archiviazione BLOB di Azure.
Le versioni del BLOB non sono modificabili. Non è possibile modificare il contenuto o i metadati di una versione BLOB esistente.
Il controllo delle versioni BLOB è disponibile per gli account di archiviazione BLOB standard per utilizzo generico v2, BLOB in blocchi Premium e archiviazione BLOB legacy. Gli account di archiviazione con uno spazio dei nomi gerarchico abilitato per l'uso con Azure Data Lake Storage non sono attualmente supportati.
La versione 2019-10-10 e successive dell'API REST Archiviazione di Azure supporta il controllo delle versioni dei BLOB.
Importante
Il blob versioning non può aiutarti a recuperare dalla cancellazione accidentale di un account o container di storage. Per impedire l'eliminazione accidentale dell'account di archiviazione, configurare un blocco sulla risorsa dell'account di archiviazione. Per ulteriori informazioni su come bloccare un account di archiviazione, consultare Applica un blocco di Gestione delle risorse di Azure a un account di archiviazione.
ID versione
Ogni versione del blob ha un ID di versione unico. Il valore dell'ID della versione corrisponde al timestamp del momento in cui il blob è stato aggiornato. Assegni l'ID della versione quando crei la versione.
Puoi leggere o cancellare una versione specifica di un blob usando il suo ID di versione. Se non includi l'ID versione, l'operazione prende di mira la versione corrente.
Quando si chiama un'operazione di scrittura per creare o modificare un BLOB, Archiviazione di Azure restituisce l'intestazione x-ms-version-id nella risposta. Questa intestazione contiene l'ID della versione corrente del blob creata dall'operazione di scrittura.
L'ID della versione rimane lo stesso per tutta la durata della versione.
Controllo delle versioni nelle operazioni di scrittura
Quando attivi la versione del blob, ogni operazione di scrittura su un blob crea una nuova versione. Le operazioni di scrittura includono Inserisci BLOB, Inserisci elenco a blocchi, Copia BLOB e Imposta metadati BLOB.
Se l'operazione di scrittura crea un nuovo blob, il blob risultante è la versione corrente del blob. Se l'operazione di scrittura modifica un blob esistente, la versione corrente diventa una versione precedente e una nuova versione attuale cattura il blob aggiornato.
Il diagramma seguente illustra come le operazioni di scrittura influiscono sulle versioni del BLOB. Per semplicità, i diagrammi in questo articolo mostrano l'ID della versione come un semplice valore intero. In realtà, l'ID versione è un timestamp. La versione corrente è visualizzata in blu e le versioni precedenti sono visualizzate in grigio.
Note
Quando si abilita la versione dei blob per un account storage, tutte le operazioni di scrittura sui blob a blocchi attivano la creazione di una nuova versione, tranne l'operazione Put Block .
Per i BLOB di pagine e i BLOB di accodamento, solo un subset di operazioni di scrittura attiva la creazione di una versione. tra cui:
Le operazioni seguenti non attivano la creazione di una nuova versione. Per acquisire le modifiche da tali operazioni, creare uno snapshot manuale:
- Inserisci pagina (BLOB di pagine)
- Accoda blocco (BLOB di accodamento)
Tutte le versioni di un blob devono essere dello stesso tipo di blob. Se un BLOB ha versioni precedenti, non è possibile sovrascrivere un BLOB di un tipo con un altro tipo, a meno che non si elimini prima il BLOB e tutte le relative versioni.
Controllo delle versioni nelle operazioni di eliminazione
Quando si chiama l'operazione Elimina BLOB senza specificare un ID versione, la versione corrente diventa una versione precedente e non esiste più una versione corrente. L'operazione preserva tutte le versioni precedenti esistenti del blob.
Il diagramma seguente illustra l'effetto di un'operazione di eliminazione in un BLOB con controllo delle versioni:
Per eliminare una versione specifica di un BLOB, specificare l'ID per tale versione nell'operazione di eliminazione. Se si abilita anche l'eliminazione temporanea dei BLOB per l'account di archiviazione, il sistema conserva la versione fino alla scadenza del periodo di conservazione dell'eliminazione temporanea.
La scrittura di nuovi dati nel BLOB crea una nuova versione corrente del BLOB. Questa azione non influisce sulle versioni esistenti, come mostrato nel diagramma seguente.
Livelli di accesso
È possibile spostare qualsiasi versione di un BLOB in blocchi, inclusa la versione corrente, in un livello di accesso BLOB diverso chiamando l'operazione Imposta livello BLOB. Spostando versioni più vecchie di un blob al livello cool o archive, puoi sfruttare un prezzo di capacità più basso. Per altre informazioni, vedere Livelli di accesso ad accesso frequente, sporadico, saltuario e archivio per i dati BLOB.
Per automatizzare il processo di spostamento dei blob a blocchi al livello appropriato, si utilizza la gestione del ciclo di vita dei blob. Per maggiori informazioni sulla gestione del ciclo di vita, vedi Gestire il ciclo di vita dello storage di Azure Blob.
Abilitare o disabilitare il controllo delle versioni dei BLOB
Per informazioni su come abilitare o disabilitare il controllo delle versioni dei BLOB, consultare Abilitare e gestire il controllo delle versioni dei BLOB.
La disabilitazione del controllo delle versioni dei BLOB non elimina BLOB, versioni o snapshot esistenti. Quando si disattiva il controllo delle versioni BLOB, tutte le versioni esistenti rimangono accessibili nell'account di archiviazione. Non vengono create nuove versioni.
Dopo la disabilitazione del controllo delle versioni, la modifica della versione corrente crea un BLOB che non è una versione. Tutti gli aggiornamenti successivi al BLOB sovrascrivono i dati senza salvare lo stato precedente. Tutte le versioni esistenti vengono mantenute come versioni precedenti.
Puoi leggere o cancellare le versioni usando l'ID versione dopo che il versioning è stato disabilitato. È anche possibile elencare le versioni di un BLOB dopo la disabilitazione del controllo delle versioni.
La replica di oggetti si basa sul controllo delle versioni dei BLOB. Prima di disabilitare il controllo delle versioni dei BLOB, è necessario eliminare tutti i criteri di replica degli oggetti nell'account. Per altre informazioni sulla replica di oggetti, vedere Replica di oggetti per BLOB in blocchi.
Il diagramma seguente illustra come modificare un BLOB dopo la disabilitazione del controllo delle versioni crea un BLOB senza controllo delle versioni. Tutte le versioni esistenti associate al BLOB vengono mantenute.
Controllo delle versioni dei BLOB ed eliminazione temporanea
Il controllo delle versioni dei BLOB e l'eliminazione temporanea dei BLOB fanno parte della configurazione di protezione dei dati consigliata per gli account di archiviazione. Per altre informazioni sulle raccomandazioni di Microsoft per la protezione dei dati, vedere Panoramica della protezione dei dati.
Sovrascrittura di un BLOB
Se il controllo delle versioni dei BLOB e l'eliminazione temporanea del BLOB sono entrambi abilitati per un account di archiviazione, la sovrascrittura di un BLOB crea automaticamente una nuova versione. La nuova versione non risulta in stato di eliminazione temporanea e alla scadenza del periodo di conservazione dell'eliminazione temporanea non sarà rimossa. Non sono creati snapshot in stato di eliminazione temporanea.
Eliminazione di un BLOB o di una versione
Se abiliti il controllo delle versioni e la cancellazione soft per un account di storage, quando elimini un blob, la versione corrente del blob diventa una versione precedente. L'operazione non crea una nuova versione né snapshot eliminati temporaneamente. Il periodo di ritenzione della cancellazione soft non si applica al blob eliminato.
L'eliminazione temporanea fornisce una protezione aggiuntiva quando si eliminano le versioni del blob. Quando elimini una versione precedente del blob, quella versione viene cancellata in modo soft. La versione con cancellazione soft viene conservata fino alla fine del periodo di ritenzione per la cancellazione soft, e poi viene eliminata definitivamente.
Per eliminare una versione precedente di un BLOB, chiamare l'operazione Elimina BLOB e specificare l'ID versione.
Il diagramma seguente illustra cosa accade quando si elimina un BLOB o una versione del BLOB.
Ripristino di una versione eliminata temporaneamente
L'operazione Annulla eliminazione BLOB può essere utilizzata durante il periodo di conservazione per ripristinare le versioni eliminate temporaneamente. L'operazione Undelete BLOB ripristina sempre tutte le versioni del BLOB in stato di eliminazione temporanea. Non puoi ripristinare solo una versione cancellata in modo software.
Ripristinare versioni cancellate in modo software usando l'operazione Undelete Blob non promuove nessuna versione come versione attuale. Per ripristinare la versione corrente, ripristinare prima tutte le versioni eliminate temporaneamente, quindi usare l'operazione Copia BLOB per copiare una versione precedente in una nuova versione corrente.
Il diagramma seguente mostra come ripristinare versioni di blob con cancellazione soft utilizzando l'operazione Undelete Blob , e come ripristinare la versione corrente del blob usando l'operazione Copia Blob .
Al termine del periodo di conservazione per il soft delete, tutte le versioni dei BLOB eliminate in modo soft delete vengono eliminate in modo permanente.
Controllo delle versioni dei BLOB e snapshot BLOB
Un blob snapshot è una copia in sola lettura di un blob scattata in un determinato momento del tempo. Gli snapshot blob e le versioni blob sono simili, ma tu o la tua applicazione create manualmente uno snapshot, mentre una versione blob viene creata automaticamente durante un'operazione di scrittura o cancellazione quando abiliti la versione blob per il tuo account storage.
Importante
Microsoft consiglia di abilitare il controllo delle versioni dei BLOB e successivamente di aggiornare l'applicazione per interrompere l'acquisizione di snapshot di BLOB di blocco. Se abiliti il versioning per il tuo account di archiviazione, questo cattura e preserva tutti gli aggiornamenti e le cancellazioni dei blob di blocco usando versioni. La creazione di snapshot non offre alcuna protezione aggiuntiva ai dati del BLOB in blocchi se il controllo delle versioni dei BLOB è abilitato e potrebbe aumentare i costi e la complessità dell'applicazione.
Creare uno snapshot di un BLOB quando è abilitato il controllo delle versioni
Anche se non è consigliato, puoi scattare uno snapshot di un blob anch'esso versionato. Se non è possibile aggiornare l'applicazione per interrompere l'acquisizione di snapshot dei BLOB quando si abilita il controllo delle versioni, l'applicazione può supportare sia snapshot che versioni.
Quando fai uno snapshot di un blob versionato, crei una nuova versione contemporaneamente allo snapshot. Crei anche una nuova versione attuale quando fai una snapshot.
Il diagramma seguente illustra cosa accade quando si crea uno snapshot di un BLOB con controllo delle versioni. Nel diagramma le versioni e gli snapshot del BLOB con ID versione 2 e 3 contengono dati identici.
Autorizzare le operazioni sulle versioni BLOB
Puoi autorizzare l'accesso alle versioni blob utilizzando uno dei seguenti approcci:
- Usa il controllo degli accessi in base al ruolo di Azure (Azure RBAC) per concedere autorizzazioni a un'entità di sicurezza di Microsoft Entra. Microsoft consiglia di usare Microsoft Entra ID per una maggiore sicurezza e facilità d'uso. Per altre informazioni sull'uso di Microsoft Entra ID con operazioni BLOB, vedere Autorizzare l'accesso ai dati in Archiviazione di Azure.
- Utilizzare una firma di accesso condiviso (SAS) per delegare l'accesso alle versioni dei blob. Specificare l'ID della versione per il tipo
bvdi risorsa firmata , che rappresenta una versione blob, per creare un token SAS per operazioni su una versione specifica. Per ulteriori informazioni sulle firme di accesso condiviso, vedere Concedere accesso limitato alle risorse di Archiviazione di Azure usando firme di accesso condiviso (SAS). - Usa le chiavi di accesso all'account per autorizzare le operazioni contro le versioni blob usando la Chiave Condivisa. Per altre informazioni, vedere Authorize with Shared Key (Autorizzazione con chiave condivisa).
Il controllo delle versioni dei BLOB è progettato per proteggere i dati da eliminazioni accidentali o dannose. Per migliorare la protezione, l'eliminazione di una versione del BLOB richiede autorizzazioni speciali. Le sezioni seguenti descrivono le autorizzazioni necessarie per eliminare una versione del BLOB.
Azione controllo degli accessi in base al ruolo di Azure per eliminare una versione del BLOB
La tabella seguente mostra quali azioni RBAC di Azure supportano l'eliminazione di un blob o di una sua versione.
| Descrizione | Operazione del servizio BLOB | Azioni sui dati di Azure RBAC richieste | Supporto del ruolo predefinito di Azure |
|---|---|---|---|
| Eliminazione della versione corrente | Elimina Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete | Collaboratore ai dati del BLOB di archiviazione |
| Eliminazione di una versione precedente | Elimina Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Proprietario dei dati del BLOB di archiviazione |
Parametri di firma di accesso condiviso
La risorsa firmata per una versione del BLOB è bv. Per altre informazioni, vedere Creare una firma di accesso condiviso del servizio o Creare una firma di accesso condiviso per la delega utente.
La tabella seguente illustra l'autorizzazione necessaria per una firma di accesso condiviso per eliminare una versione del BLOB.
| Autorizzazione | Simbolo URI | Operazioni consentite |
|---|---|---|
| Delete | x | Eliminare una versione del BLOB. |
Prezzi e fatturazione
Abilitare la versione dei blob può comportare costi aggiuntivi per l'archiviazione dei dati sul tuo account. Quando progetti la tua applicazione, fai attenzione a come questi costi potrebbero accumularsi per ridurre al minimo i costi.
Le versioni dei BLOB, come gli snapshot dei BLOB, vengono fatturate con la stessa frequenza dei dati attivi. Come paghi le versioni dipende dal fatto che tu imposti esplicitamente il tier per le versioni attuali o precedenti di un blob (o snapshot). Per altre informazioni sui livelli dei BLOB, vedere Livelli di accesso frequente, sporadico, saltuario e archivio per i dati BLOB.
Se non cambi il livello di un blob o di una versione, paghi per blocchi di dati unici su quel blob, le sue versioni e qualsiasi snapshot che possa avere. Per maggiori informazioni, vedi Fatturazione quando il livello blob non è esplicitamente impostato.
Se cambi un blob o il tier di una versione, paghi per l'intero oggetto, indipendentemente dal fatto che il blob e la versione siano di nuovo nello stesso tier. Per ulteriori informazioni, vedi Fatturazione quando il livello del BLOB è impostato in modo esplicito.
Note
Abilitare il versioning per dati che vengono spesso sovrascritti potrebbe aumentare i costi di capacità di archiviazione e aumentare la latenza durante le operazioni di elenco. Per attenuare questi problemi, archiviare i dati sovrascritti di frequente in un account di archiviazione separato con il controllo delle versioni disabilitato.
L'abilitazione delle versioni sugli account di archiviazione, che vengono spesso sottoposti a backup, potrebbe comportare addebiti per il recupero dei dati quando le versioni sono archiviate in livelli di accesso raro o freddo.
Per altre informazioni sui dettagli di fatturazione relativi agli snapshot del BLOB, vedere Snapshot dei BLOB.
Per gli account di archiviazione che usano smart tier, si paga per versioni e snapshot a lunghezza completa del contenuto. Per ulteriori informazioni, consultare Ottimizzazione dei costi con il livello intelligente.
Fatturazione quando non si imposta esplicitamente il livello del blob
Se non imposti esplicitamente il livello del blob per qualsiasi versione di un blob, paghi per blocchi o pagine uniche in tutte le versioni, e per eventuali snapshot che possa contenere. Paghi per i dati condivisi tra le versioni del blob solo una volta. Quando aggiorni un blob, i dati nella nuova versione attuale si discostano da quelli memorizzati nelle versioni precedenti, e paghi per i dati unici per ogni blocco o pagina.
Quando sostituisci un blocco all'interno di un blob, paghi per quel blocco come blocco unico. Questa regola si applica anche se il blocco ha lo stesso ID blocco e gli stessi dati della versione precedente. Dopo aver effettuato nuovamente il commit del blocco, questo si discosta dal suo corrispettivo nella versione precedente e si paga per i suoi dati. La stessa regola si applica a una pagina in un blob di pagine che aggiorni con dati identici.
Lo storage blob non ha modo di determinare se due blocchi contengono dati identici. Ogni blocco che carichi e di cui esegui il commit viene considerato univoco, anche se contiene gli stessi dati e lo stesso ID del blocco. Poiché paghi per blocchi unici, tieni presente che aggiornare un blob quando il versioning è abilitato comporta più blocchi unici e costi extra.
Quando abiliti il controllo delle versioni dei BLOB, usa operazioni di aggiornamento sui BLOB in blocchi in modo da aggiornare il minor numero possibile di blocchi. Le operazioni di scrittura che consentono un controllo con granularità fine sui blocchi sono Inserire Blocco e Inserire Elenco Blocchi. L'operazione Put Blob, invece, sostituisce l'intero contenuto di un blob e quindi potrebbe portare a costi aggiuntivi.
Gli scenari seguenti illustrano come vengono addebitati i costi per un BLOB in blocchi e le relative versioni quando non si imposta esplicitamente il livello del BLOB.
Scenario 1
Nello scenario 1 il BLOB ha una versione precedente. Il blob non è stato aggiornato da quando è stata creata la versione, quindi vengono addebitati costi solo per i blocchi univoci 1, 2 e 3.
Scenario 2
Nello scenario 2, aggiorni un blocco (blocco 3 nel diagramma) nel blob. Anche se il blocco aggiornato contiene gli stessi dati e lo stesso ID, non è uguale al blocco 3 nella versione precedente. Di conseguenza, paghi per quattro blocchi.
Scenario 3
Nello scenario 3, aggiorni il blob, ma non aggiorni la versione. Sostituisci il blocco 3 con il blocco 4 nel blob corrente, ma la versione precedente riflette ancora il blocco 3. Di conseguenza, paghi per quattro blocchi.
Scenario 4
Nello scenario 4, aggiorni completamente la versione attuale e questa non contiene nessuno dei blocchi originali. Di conseguenza, paghi per tutti e otto i blocchi unici: quattro nella versione attuale e quattro combinati nelle due versioni precedenti. Questo scenario può verificarsi se scrivi su un blob usando l'operazione Put Blob , perché sostituisce l'intero contenuto del blob.
Fatturazione quando il livello blob è esplicitamente impostato
Se imposti esplicitamente il blob tier per un blob, una versione o uno snapshot, paghi per la lunghezza completa del contenuto dell'oggetto nel nuovo tier, anche se condivide i blocchi con un oggetto del tier originale. Paghi anche per la lunghezza completa del contenuto della versione più vecchia del tier originale. Per eventuali altre versioni o snapshot precedenti che rimangono nel tier originale, si paga per blocchi unici che condividono, come descritto in Billing quando il blob tier non è esplicitamente impostato.
Spostamento di un BLOB in un nuovo livello
La tabella seguente descrive il comportamento di fatturazione di un blob o di una versione quando la si sposta su un nuovo livello.
| Quando imposti il livello del blob... | allora sarà addebitato... |
|---|---|
| In modo esplicito su una versione, sia corrente che precedente | Lunghezza completa del contenuto di tale versione. Le versioni che non dispongono di un livello impostato in modo esplicito vengono fatturate solo per blocchi univoci.1 |
| Per archiviare | Lunghezza completa del contenuto di tutte le versioni e snapshot.1. |
1Se sono presenti altre versioni o snapshot precedenti che non hai spostato dal livello originale, tali versioni o snapshot vengono fatturate in base al numero di blocchi univoci che contengono, come descritto in Fatturazione quando il livello del BLOB non è impostato in modo esplicito.
Il seguente diagramma illustra come vengono fatturati gli oggetti quando si sposta un BLOB con versione a un livello differente.
Non puoi annullare l'impostazione esplicita del tier per un blob, una versione o uno snapshot. Se sposti un blob in un nuovo tier e poi lo riporti al suo tier originale, paghi per l'intera lunghezza del contenuto dell'oggetto anche se condivide i blocchi con altri oggetti del tier originale.
Le operazioni che impostano in modo esplicito il livello di accesso di un BLOB, di una versione o di uno snapshot includono:
- Impostare il livello di BLOB
- Inserire BLOB specificando il livello
- Inserire Elenco Blocchi specificando il livello
- Copiare BLOB specificando il livello
Eliminazione di un BLOB quando è abilitata l'eliminazione temporanea
Quando abiliti l'eliminazione temporanea dei BLOB, paghi per tutte le entità eliminate temporaneamente alla stessa tariffa dei dati attivi. Se elimini o sovrascrivi una versione corrente per cui è impostato esplicitamente un livello, paghi per tutte le versioni precedenti del blob eliminato temporaneamente in base all’intera lunghezza del contenuto. Per altre informazioni sull'interazione tra il controllo delle versioni del BLOB e l’eliminazione temporanea, vedere Controllo delle versioni del BLOB ed Eliminazione temporanea.
Supporto delle funzionalità
Il supporto per questa funzionalità potrebbe essere influenzato dall'abilitazione di Data Lake Storage Gen2, del protocollo NFS (Network File System) 3.0 o del protocollo SFTP (SSH File Transfer Protocol). Se hai abilitato una di queste funzionalità, vedere supporto delle funzionalità di gestione rete virtuale di Azure negli account di Archiviazione di Azure per valutare il supporto per queste funzionalità.
Il versioning non è supportato per i blob che si caricano usando le API di Data Lake Storage.