Controllo delle versioni per i BLOB

Puoi abilitare il controllo delle versioni dei 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 controllo delle versioni dei BLOB potrebbe comportare costi aggiuntivi. Per minimizzare i costi, utilizza una policy Lifecycle Management o un compito Storage Actions per eliminare automaticamente le versioni precedenti.

Configurazione consigliata per la protezione dei dati

Il blob versioning è una delle diverse funzionalità di protezione dei dati. La scelta della funzionalità giusta o della combinazione di funzionalità dipende dal tuo carico di lavoro e da cosa ti stai proteggendo. Per saperne di più sulle raccomandazioni di Microsoft per la protezione dei dati, consulta Panoramica sulla protezione dei dati.

Versioni e snapshot a confronto

Una versione blob è simile a una snapshot, ma le due differiscono per come vengono create e per cosa sono più adatte. Il controllo delle versioni è automatico e gestito dal sistema: Archiviazione di Azure crea una nuova versione a ogni scrittura o eliminazione quando il controllo delle versioni dei BLOB è abilitato, senza bisogno di logica applicativa. Una snapshot è manuale e guidata dall'applicazione: crei esplicitamente una copia in un momento in cui la tua applicazione decide che è necessaria.

Usa il versioning quando vuoi una protezione automatica e continua contro sovrascritture e cancellazioni accidentali o dannose. Usa snapshot quando vuoi copie deliberate e in un momento preciso, come un checkpoint sicuramente funzionante prima di un aggiornamento pianificato. Microsoft consiglia di smettere di scattare istantanee dei blob a blocchi una volta abilitato il controllo delle versioni.

Funzionamento del controllo delle versioni BLOB

Una versione acquisisce lo stato di un BLOB in un determinato momento. Ogni versione ha un ID di versione. Quando abiliti il controllo delle versioni dei BLOB per un account di archiviazione, Archiviazione di Azure crea automaticamente una nuova versione con un ID univoco quando crei un BLOB per la prima volta e ogni volta che lo modifichi.

Un ID versione può identificare la versione corrente o una versione precedente. Un blob può avere una sola versione corrente alla volta, ovvero il suo stato corrente. Un blob può avere più versioni precedenti.

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 mostra come vengono create le versioni durante le operazioni di scrittura e come una versione precedente potrebbe essere promossa alla versione attuale:

Le versioni precedenti dei blob sono immutabili, il che significa che non puoi modificare il contenuto o i metadati.

Importante

• La presenza di un numero elevato di versioni per BLOB può aumentare la latenza per le operazioni di elenco di BLOB. Microsoft raccomanda di mantenere meno di 1.000 versioni per blob. Puoi usare una policy di gestione del ciclo di vita o un'attività Storage Actions per eliminare automaticamente le versioni vecchie.

• 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 versione è il timestamp quando 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 esegui 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 versione 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

Un blob che hai creato prima che il versioning fosse abilitato per l'account di archiviazione non ha un ID di versione. Quando modifichi quel blob, il blob modificato diventa la nuova versione corrente, e lo stato del blob prima dell'aggiornamento diventa una versione precedente. La versione corrente ha un ID di versione che corrisponde al suo momento di creazione.

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:

• Put Blob
• Imposta elenco blocchi
• Set Blob Metadata
• Copia Blob

Le seguenti operazioni non attivano la creazione di una nuova versione:

• Inserisci pagina (BLOB di pagine)
• Accoda blocco (BLOB di accodamento)

Per catturare i cambiamenti da tali operazioni, crea un'istantanea manuale. Per ulteriori informazioni, vedi Blob snapshots.

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 esegui l'operazione Elimina Blob senza specificare un ID di versione, la versione attuale diventa una versione precedente e non esiste più una versione attuale. 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 di blocco al livello appropriato, crea una policy Lifecycle Management, crea un'attività Storage Actions o abilita lo Smart Tier.

Abilitare o disabilitare il controllo delle versioni dei BLOB

Per le istruzioni su come abilitare o disabilitare il versioning dei blob, vedi Abilitare e gestire la versionazione dei blob.

La disabilitazione del controllo delle versioni dei BLOB non elimina BLOB, versioni o snapshot esistenti. Quando disattivi il controllo delle versioni dei BLOB, non puoi creare nuove versioni.

Dopo aver disattivato il versioning, modificare la versione attuale 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.

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

Il versioning non è supportato per i blob che si caricano usando le API di Data Lake Storage.

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.

Considerazioni sul carico di lavoro esistente

• L'eliminazione di un blob non libera più spazio. Quando abiliti il versioning, eliminare un blob non rimuove i suoi dati. La versione attuale diventa una versione precedente che persiste e continua a comportare costi. I carichi di lavoro che si basano su operazioni di cancellazione per recuperare lo spazio di archiviazione continuano a comportare costi finché non elimini esplicitamente quelle versioni.

• I carichi di lavoro con frequenti sovrascritture possono accumulare versioni. Le versioni persistono finché non le elimini esplicitamente. Questa persistenza può portare all'accumulo di versioni se non le gestisci correttamente. Per ridurre i costi, apporta modifiche a livello di blocco, che saranno addebitate per blocco nelle varie versioni, minimizzando i costi per versione.

Interazioni tra le funzionalità

Eliminazione morbida

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 abiliti sia la versione del blob che la cancellazione soft del blob per un account di archiviazione, allora sovrascrivere un blob crea automaticamente una nuova versione precedente che riflette lo stato del blob prima dell'operazione di scrittura. La nuova versione non viene eliminata logicamente e persiste fino a quando non viene esplicitamente eliminata. Non sono creati snapshot in stato di eliminazione temporanea.

Eliminazione di un BLOB o di una versione

Se abiliti sia il versioning che la cancellazione soft per un account di archiviazione, quando elimini un blob, la versione attuale del blob diventa una versione precedente. L'operazione non crea una nuova versione né snapshot eliminati temporaneamente. Il periodo di conservazione dell'eliminazione temporanea non si applica al BLOB eliminato.

La cancellazione soft offre una protezione extra quando si eliminano le versioni del blob. Quando elimini una versione precedente del blob, l'operazione elimina temporaneamente tale versione. La versione eliminata temporaneamente viene mantenuta fino a quando non scade il periodo di conservazione dell'eliminazione temporanea, quando viene eliminato definitivamente.

Per eliminare una versione precedente di un BLOB, chiamare l'operazione Elimina BLOB e specificare l'ID versione.

Ripristino di una versione eliminata temporaneamente

Usa l'operazione Undelete Blob per ripristinare le versioni eliminate in modo temporaneo durante il periodo di conservazione della cancellazione soft. 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 le versioni eliminate temporaneamente usando l'operazione Undelete Blob non promuove nessuna versione alla 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.

Dopo la scadenza del periodo di conservazione soft-delete, il sistema elimina permanentemente tutte le versioni del BLOB eliminate temporaneamente.

Snapshot di BLOB

Uno snapshot di BLOB è una copia in sola lettura di un BLOB acquisita 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 automaticamente creata durante un'operazione di scrittura o cancellazione quando abiliti il controllo delle versioni dei BLOB per il tuo account storage.

Importante

Dopo aver abilitato il blob versioning, aggiorna la tua applicazione per smettere di scattare snapshot dei blob a blocchi. Se abiliti il controllo delle versioni per il tuo account di archiviazione, le versioni acquisiscono e preservano tutti gli aggiornamenti e le eliminazioni dei BLOB in blocchi. Scattare snapshot non offre alcuna protezione aggiuntiva ai dati del blocco blob se il versioning del 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.

Limitazioni note

• Non supportato negli account con spazio dei nomi gerarchico (Azure Data Lake Storage), né per i blob caricati tramite le API di Data Lake Storage.

• Non protegge contro la cancellazione di container o account. Il versioning funziona solo a livello di blob. Eliminare un contenitore rimuove tutti i blob e le loro versioni. Per recuperare da quella cancellazione è necessaria l'eliminazione temporanea del contenitore. Proteggere dall'eliminazione dell'account richiede un blocco della risorsa.

• Le versioni sono immutabili. Non puoi cambiare il contenuto o i metadati di una versione esistente.

• Tutte le versioni di un blob devono essere dello stesso tipo di blob. Non puoi sovrascrivere un blob con un tipo di blob diverso mentre ha versioni precedenti, a meno che tu non elimini prima il blob e tutte le sue versioni.

• Non tutte le operazioni di scrittura creano una versione. Fai riferimento alle informazioni riportate in precedenza in questo articolo che illustrano le eccezioni. Per catturare questi stati, usa una snapshot manuale.

• Non si può disabilitare il versioning finché esistono politiche di replica degli oggetti sull'account. Devi prima eliminare tutte le politiche di replica degli oggetti.

• Undelete Blob ripristina tutte le versioni eliminate temporaneamente di un BLOB, non una singola. Non puoi ripristinare selettivamente una versione. Undelete non promuove mai una versione a corrente.

• Tetto massimo raccomandato di 1.000 versioni per blob. Superarla degrada le prestazioni dell'elenco dei blob.

Prezzi e fatturazione

Quando attivi il controllo delle versioni dei BLOB, potresti sostenere costi aggiuntivi per l'archiviazione dei dati. Quando progetti la tua applicazione, considera come questi costi potrebbero sommarsi per mantenere bassi i costi.

Ti vengono addebitate le versioni blob, come gli snapshot blob, alla stessa tariffa dei dati attivi. Il modo in cui viene addebitato il costo delle versioni dipende dal fatto che si 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, ti vengono addebitati blocchi di dati unici tra quel blob, le sue versioni e qualsiasi snapshot che possa avere. Per altre informazioni, vedere Fatturazione quando il livello di BLOB non è esplicitamente impostato.

Se cambi il tier di un blob o di una versione, vieni addebitato per l'intero oggetto, indipendentemente dal fatto che il blob e la versione finiscano di nuovo nello stesso tier. Per altre informazioni, vedere Fatturazione quando il livello di BLOB è esplicitamente impostato.

Note

Se abiliti il versioning per i dati che sovrascrivi frequentemente, potresti vedere un aumento dei costi di capacità di archiviazione e una latenza maggiore durante le operazioni di elenco. Per affrontare queste problematiche, memorizza i dati sovrascritti frequentemente in un account di archiviazione separato con il controllo delle versioni disabilitato.

Se abiliti le versioni negli account di archiviazione di cui viene eseguito spesso il backup, potresti attivare addebiti per il recupero dei dati quando le versioni vengono archiviate nei livelli di accesso cool o cold.

Per altre informazioni sui dettagli di fatturazione relativi agli snapshot del BLOB, vedere Snapshot dei BLOB.

Per gli account di archiviazione che usano il livello intelligente, versioni e snapshot si pagano in base all'intera lunghezza 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 tutte le versioni di un BLOB, ti vengono addebitati i blocchi o le pagine univoci tra tutte le versioni e le eventuali snapshot che può avere. Ti vengono addebitati i dati condivisi tra le versioni del BLOB una sola volta. Quando aggiorni un blob, i dati nella nuova versione attuale si discostano da quelli memorizzati nelle versioni precedenti, quindi vieni addebitato per i dati unici per blocco o pagina.

Quando sostituisci un blocco all'interno di un blob a blocchi, vieni fatturato 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 ti vengono addebitati i dati del blocco. 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é ti vengono addebitati i blocchi unici, tieni presente che aggiornare un blob quando il versioning è abilitato comporta blocchi unici extra e costi aggiuntivi.

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. Put Block prepara le modifiche, ma la modifica effettiva e la creazione della versione avvengono durante l'operazione Put Block List. 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, un blocco (blocco 3 nel diagramma) nel blob viene aggiornato. Anche se il blocco aggiornato contiene gli stessi dati e lo stesso ID, non è uguale al blocco 3 nella versione precedente. Di conseguenza, all'account vengono addebitati quattro blocchi.

Scenario 3

Nello scenario 3, il blob viene aggiornato, ma la versione no. Il blocco 3 viene sostituito dal blocco 4 nel blob corrente, ma la versione precedente riflette ancora il blocco 3. Di conseguenza, all'account vengono addebitati quattro blocchi.

Scenario 4

Nello scenario 4, la versione attuale è completamente aggiornata e non contiene nessuno dei suoi blocchi originali. Di conseguenza, l'account viene addebitato 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 si imposta esplicitamente il livello del blob

Se imposti esplicitamente il livello del blob per un blob, una versione o una snapshot, paghi per la lunghezza completa del contenuto dell'oggetto nel nuovo tier, indipendentemente dal fatto che condivida 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 livello originale, si paga per i blocchi unici che condividono, come descritto in Fatturazione quando il livello di BLOB 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 si imposta il livello del BLOB...	allora sarà addebitato...
Esplicitamente impostato su una versione, sia attuale 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
Impostato per l'archiviazione	La lunghezza completa del contenuto di tutte le versioni e istantanee. 1

¹Se 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 diagramma seguente illustra come gli oggetti vengono fatturati quando si sposta un blob versionato su un altro livello.

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 attuale per cui hai esplicitamente impostato il livello, paghi per eventuali versioni precedenti del blob soft-cancellato in base all'intera lunghezza del contenuto. Per maggiori informazioni su come funzionano insieme il controllo delle versioni dei BLOB e l'eliminazione temporanea, vedi Interazioni tra le funzionalità.

Monitoraggio e risoluzione dei problemi

• La mia politica LCM non cancella versioni quando mi aspetto: L'età di una versione si basa su quando hai originariamente scritto i dati, non su quando è diventata una versione precedente. Il cronometro parte dalla creazione del blob, non dall'overwrite che l'ha spinto nella cronologia delle versioni. Di conseguenza, un blob che è rimasto attuale a lungo prima di essere sovrascritto può produrre una versione precedente che già supera la tua daysAfterCreationGreaterThan soglia nel momento in cui viene creata, causando la sua cancellazione quasi immediata. Al contrario, versioni di blob creati di recente possono persistere più a lungo del previsto. Per confermare, controlla il timestamp reale di creazione sulle versioni invece di presumere che corrisponda al tempo di sovrascrittura. Se devi basare la retention su quando una versione è diventata non aggiornata o vuoi un controllo più dettagliato rispetto alle soglie giornaliere della gestione del ciclo di vita, considera invece Archiviazione di Azure Actions. Per maggiori informazioni, vedi Azioni di archiviazione.

• La mia fattura è ancora alta dopo aver disabilitato le versioni: Le versioni esistenti rimangono finché non le elimini manualmente.

• Non posso disabilitare il versioning. La replica degli oggetti potrebbe essere configurata sull'account. Elimina prima tutte le politiche di replica degli oggetti, poi disabilita il versioning. In alternativa, potrebbe esistere una policy di Immutabilità (WORM) su un container o su un account per i quali il versioning non può essere disabilitato.

Vedere anche

• Abilitare e gestire il controllo delle versioni dei BLOB
• Creazione di uno snapshot di un BLOB
• Eliminazione temporanea per i BLOB
• Eliminazione temporanea per i contenitori