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.
Una snapshot è una copia in sola lettura di un blob scattata in un momento specifico. Non è necessario abilitare la funzione di istantanee blob. Invece, crea snapshot on demand utilizzando l'operazione Snapshot Blob . Per ulteriori informazioni, vedi operazione Snapshot Blob. Puoi automatizzare la creazione di istantanee utilizzando script personalizzati per acquisire copie point-in-time dei blob in base a una pianificazione o prima o dopo operazioni specifiche.
Configurazione consigliata per la protezione dei dati
Le istantanee dei blob sono 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.
Istantanee e versioni
Una snapshot è simile a una versione blob, ma le due differiscono per come vengono create e per cosa sono più adatte. Una snapshot è manuale e guidata dall'applicazione: crei esplicitamente una copia in un momento in cui la tua applicazione decide che è necessaria. 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.
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 noto e valido prima di un aggiornamento pianificato, piuttosto che una cattura di ogni modifica.
Note
Anche se puoi approssimare il comportamento di versioning usando snapshot, Microsoft raccomanda il blob versioning per la protezione automatica contro sovrascrittura e cancellazione degli account FNS. Gli snapshot sono più adatti a catture deliberate e in un momento nel tempo piuttosto che per una protezione che cattura ogni cambiamento. Per maggiori informazioni, vedi Blob versioning.
Come funzionano gli snapshot
Una snapshot di un blob è identica al suo blob base, tranne per il fatto che l'URI del blob ha un valore DateTime aggiunto all'URI del blob per indicare il momento in cui è stato scattato lo snapshot. Ad esempio, se un URI del BLOB di pagine è http://storagesample.core.blob.windows.net/mydrives/myvhd, l'URI dello snapshot è simile a http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z.
Quando si crea uno snapshot di un BLOB, le proprietà di sistema del BLOB vengono copiate nello snapshot con gli stessi valori. Anche i metadati del BLOB di base vengono copiati nello snapshot, se non si specificano metadati separati per lo snapshot durante la creazione. Dopo aver creato uno snapshot, è possibile leggerlo, copiarlo o eliminarlo, ma non modificarlo. Tutti i lease associati al BLOB di base non influiscono sullo snapshot. Non è possibile acquisire un lease su uno snapshot.
Un BLOB può avere un numero qualsiasi di snapshot. Gli snapshot persistono finché non li elimini esplicitamente, indipendentemente o come parte di un'operazione di Cancella Blob per il blob base. Puoi creare un'istantanea di un blob nel livello caldo, freddo o sporadico. Non puoi creare uno snapshot di un blob archiviato.
Importante
Avere un gran numero di istantanee per blob può aumentare la latenza per le operazioni di listing del blob. Microsoft raccomanda di mantenere meno di 1.000 snapshot per blob. Puoi usare la gestione del ciclo di vita per eliminare automaticamente le vecchie snapshot. Per maggiori informazioni sulla gestione del ciclo di vita, vedi Ottimizza i costi automatizzando i livelli di accesso di Archiviazione BLOB di Azure.
Gli snapshot sono particolarmente utili per tipi di blob e operazioni che non vengono catturate dal blob versioning. Poiché alcune operazioni di scrittura, come Put Page (blob di pagina) e Append Block (blob di accodamento), non creano versioni di blob nemmeno quando il versioning è abilitato, gli snapshot forniscono un modo per catturare lo stato di un blob in un determinato momento quando si utilizzano queste API. Ad esempio, un file VHD memorizza le informazioni e lo stato attuali di un disco rigido virtuale. Puoi staccare un disco dall'interno della VM o spegnere la VM, scattare uno snapshot del suo file VHD e poi usare quello snapshot per recuperare il file VHD al momento dello snapshot e ricreare la VM.
Il diagramma seguente mostra come vengono creati gli snapshot e come un snapshot potrebbe essere promosso come blob corrente:
Gestire e ripristinare snapshot
Puoi creare, elencare e cancellare snapshot. Puoi anche usare uno snapshot per ripristinare un blob base a uno stato precedente. Le sezioni seguenti descrivono ogni operazione e gli strumenti corrispondenti.
Ripristinare un BLOB da uno snapshot
Poiché non puoi modificare uno snapshot, ripristini un blob base copiando uno snapshot sopra di esso. Chiama l'operazione Copy Blob e specifica l'URI snapshot come sorgente di copia. Questo processo promuove lo stato dello snapshot per diventare il blob base corrente, preservando gli snapshot esistenti del blob.
Elencare gli snapshot
Puoi enumerare gli snapshot associati al blob base per tracciare i tuoi snapshot attuali usando l'operazione List Blobs e specificando il snapshots valore nel include parametro. Per impostazione predefinita, una richiesta di elenco dei blob non restituisce snapshot. Imposta include=snapshots per restituire tutte le istantanee di ogni blob insieme al blob base. Per ulteriori informazioni, vedi List Blobs. Puoi anche usare Archiviazione di Azure Blob Inventory per generare un report programmato dei blob nel tuo account, inclusi i loro snapshot, impostando il includeSnapshots campo a true nella definizione della regola dell'inventario. Per maggiori informazioni, vedi Blob Inventory.
Eliminare gli snapshot
Devi cancellare esplicitamente uno snapshot. Per eliminare uno snapshot individuale, si chiama l'operazione Delete Blob e si specifica il valore DateTime dello snapshot nel parametro della query snapshot.
Non puoi eliminare un blob base finché ha snapshot attivi. Per eliminare un blob base e tutti i suoi snapshot insieme, chiama Delete Blob con l'intestazione x-ms-delete-snapshots impostata su include. Per eliminare solo gli snapshot e mantenere il blob base, imposta l'intestazione su only.
Gestisci gli snapshot con strumenti
Puoi gestire gli snapshot usando il portale, interfaccia della riga di comando di Azure e Azure PowerShell.
- Portal
- PowerShell
- interfaccia della riga di comando di Azure
Per creare uno snapshot di un blob utilizzando il portale Azure, segui questi passaggi:
- Nel portale di Azure passare all'account di archiviazione.
- Sotto Archiviazione dati, trova l'opzione Container , e poi seleziona il contenitore che contiene il blob.
- Seleziona il blob di cui vuoi creare un'istantanea.
- Nella scheda Panoramica del blob, seleziona Crea istantanea.
- Per visualizzare gli snapshot del blob, seleziona la scheda Snapshots . La scheda elenca ogni snapshot insieme alla data e all'ora in cui è stata catturata.
Supporto delle funzionalità
Questa funzione non è abilitata per gli account Data Lake Storage Gen2. Inoltre, il protocollo Network File System (NFS) 3.0, o il protocollo SSH File Transfer Protocol (SFTP), potrebbe influire sul supporto di questa funzione. Se abiliti una di queste funzionalità, consulta il supporto alle funzionalità di gestione rete virtuale di Azure negli account Archiviazione di Azure per valutare il supporto a questa funzione. Considera meccanismi alternativi. Esempi includono Soft delete per i BLOB, AzCopy e Vaulted Backup.
Interazioni tra le funzionalità
Versioning
Quando abiliti il versioning, gli snapshot sono solitamente ridondanti per i blob a blocchi. Se abiliti sia il versioning che gli snapshot contemporaneamente, fare uno snapshot crea sia uno snapshot che una nuova versione. Questo processo aumenta il numero di oggetti memorizzati senza aggiungere una protezione. Per altre informazioni, vedere Controllo delle versioni del BLOB.
Eliminazione morbida
L'eliminazione temporanea si applica agli snapshot: quando elimini uno snapshot, questo viene eliminato temporaneamente. Puoi ripristinarlo durante il periodo di conservazione usando Undelete Blob. Inoltre, il modo in cui crei e fatturi gli snapshot varia a seconda che il versioning sia abilitato o meno. Quando il versioning è disabilitato, sovrascrivere un blob crea uno snapshot soft-delete. Quando il versioning è abilitato, viene creata una nuova versione. Se imposti esplicitamente il tier su un blob base, paghi la lunghezza completa del contenuto per eventuali versioni precedenti o snapshot del blob cancellato in modo soft. Per dettagli su questo comportamento di fatturazione, consulta la sezione Prezzi e fatturazione. Per maggiori informazioni sulla cancellazione soft, vedi Blob Soft Delete.
Replica di oggetti
Non puoi replicare snapshot. Solo il blob di base viene replicato. Per maggiori informazioni, vedi Replica degli oggetti.
Gestione del ciclo di vita
La gestione del ciclo di vita può mirare ed eliminare istantanee utilizzando il sottotipo di snapshot nelle regole di policy. Per maggiori informazioni, vedi Gestione del ciclo di vita.
Prezzi e fatturazione
La creazione di uno snapshot, ovvero una copia di sola lettura di un BLOB, può comportare costi aggiuntivi per l'archiviazione dei dati per l'account. Quando progetti la tua applicazione, fai attenzione a come questi costi potrebbero accumularsi per ridurre al minimo i costi.
Gli snapshot del BLOB, come le versioni del BLOB, vengono fatturati alla stessa tariffa dei dati attivi. Il modo in cui vieni fatturato per gli snapshot dipende dal fatto che tu stia esplicitamente impostando il tier per il blob base o per uno qualsiasi dei suoi snapshot (o versioni). Per altre informazioni sui livelli di accesso del BLOB, vedere Livelli di accesso dei dati del BLOB.
Se non cambi il livello di un blob o uno snapshot, ti vengono addebitati i costi per i blocchi di dati unici su quel blob, i suoi snapshot e qualsiasi versione che possa avere. Per altre informazioni, vedere Fatturazione quando il livello di accesso del BLOB non è stato impostato in modo esplicito.
Se cambi il livello di un blob o di uno snapshot, vieni fatturato per l'intero oggetto, indipendentemente dal fatto che blob e snapshot siano di nuovo nello stesso tier. Per altre informazioni, vedere Fatturazione quando il livello di accesso del BLOB è stato impostato in modo esplicito.
Per gli account di archiviazione che sfruttano il livello smart, le versioni e gli snapshot vengono fatturati sulla lunghezza completa del contenuto. Per ulteriori informazioni, consultare Ottimizzazione dei costi con il livello intelligente.
Per altre informazioni sui dettagli di fatturazione relativi alle versioni del BLOB, vedere Controllo delle versioni del BLOB..
Ridurre al minimo i costi con la gestione degli snapshot
Per evitare costi aggiuntivi, gestisci con attenzione i tuoi snapshot. Segui queste migliori pratiche per ridurre al minimo i costi sostenuti dall'archiviazione delle tue istantanee:
- Eliminare e ricreare snapshot associati a un BLOB ogni volta che si aggiorna il BLOB, anche se si esegue l'aggiornamento con dati identici, a meno che la progettazione dell'applicazione non richieda la gestione degli snapshot. Eliminando e ricreando gli snapshot del blob, ti assicuri che il blob e gli snapshot non divergano.
- Se si gestiscono gli snapshot di un BLOB, evitare metodi di chiamata che sovrascrivono l'intero BLOB quando si aggiorna il BLOB. Invece, aggiorna il minor numero possibile di blocchi per mantenere bassi i costi.
Fatturazione quando non si imposta esplicitamente il livello del blob
Se non imposti esplicitamente il livello del blob per un blob di base o per uno qualsiasi dei relativi snapshot, paghi per i blocchi o le pagine univoci nel blob, nei relativi snapshot e in qualsiasi versione possa avere. Paghi per dati che un blob e i suoi snapshot condividono solo una volta. Quando aggiorni un blob, i dati in un blob di base si discostano dai dati memorizzati nei relativi snapshot e paghi per i dati univoci per blocco o pagina.
Quando sostituisci un blocco all'interno di un blob a blocchi, poi paghi per quel blocco come blocco unico. Questa regola si applica anche se il blocco ha lo stesso ID del blocco e gli stessi dati che ha nello snapshot. Dopo aver effettuato nuovamente il commit del blocco, questo si discosta dal suo corrispettivo nello snapshot e si paga per i suoi dati. La stessa regola si applica a una pagina in un page blob che viene aggiornata 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, ricorda che aggiornare un blob quando quel blob ha snapshot o versioni comporta blocchi unici extra e costi aggiuntivi.
Quando un BLOB contiene snapshot, eseguire 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 dimostrano come si accumulano le spese per un blob di blocco e i suoi snapshot quando non si imposta esplicitamente il tier del blob.
Scenario 1
Nello scenario 1, il BLOB di base non è stato aggiornato dopo l'acquisizione dello snapshot, pertanto vengono addebitati solo i blocchi univoci 1, 2 e 3.
Scenario 2
Nello scenario 2 è stato aggiornato il Blob di base, ma non è stato acquisito lo snapshot. Il blocco 3 è stato aggiornato, e sebbene contenga gli stessi dati e lo stesso ID, non è lo stesso blocco 3 dello snapshot. Di conseguenza, all'account vengono addebitati quattro blocchi.
Scenario 3
Nello scenario 3 il BLOB di base è stato aggiornato, ma lo snapshot non è stato acquisito. Il blocco 3 è stato sostituito con il blocco 4 nel BLOB di base, ma lo snapshot continua a riflettere il blocco 3. Di conseguenza, all'account vengono addebitati quattro blocchi.
Scenario 4
Nello Scenario 4, il BLOB di base è stato completamente aggiornato e non contiene nessuno dei blocchi originali. Di conseguenza, all'account vengono addebitati tutti gli otto blocchi univoci.
Suggerimento
Per mantenere bassi i costi, evita di chiamare metodi che sovrascrivono l'intero blob. Invece, aggiorna i singoli blocchi.
Fatturazione quando si imposta esplicitamente il livello del blob
Se imposti esplicitamente il livello del blob per un blob, snapshot o versione, 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. Si pagano per blocchi unici in qualsiasi versione o snapshot che rimane nel tier originale, 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 per un blob o snapshot quando lo sposti su un nuovo livello.
| Quando imposti esplicitamente il livello blob su... | Allora sarà addebitato... |
|---|---|
| BLOB di base con uno snapshot | Il BLOB di base è nel nuovo livello di accesso e lo snapshot meno recente è nel livello di accesso originale, insieme a eventuali blocchi univoci di altri snapshot.1 |
| BLOB di base con una versione precedente e uno snapshot | Il blob base nel nuovo tier, la versione più vecchia nel tier originale e lo snapshot più vecchio nel tier originale, più eventuali blocchi unici in altre versioni o snapshot. 1 |
| Uno snapshot | Lo snapshot è nel nuovo livello di accesso e il BLOB di base è nel livello di accesso originale, insieme a eventuali blocchi univoci di altri snapshot.1 |
1 Se ci sono altre versioni o snapshot precedenti che non hai spostato dal loro tier originale, paghi in base al numero di blocchi unici che contengono, come descritto in Billing quando il blob tier non è esplicitamente impostato.
Il diagramma seguente illustra come gli oggetti vengono fatturati quando si sposta un blob con istantanee 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:
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 la cancellazione soft del blob è abilitata, se elimini o sovrascrivi un blob base per cui hai esplicitamente impostato il livello, paghi per la lunghezza completa del contenuto di eventuali versioni precedenti o snapshot del blob cancellato in modo soft. Per maggiori informazioni su come funzionano insieme la versione dei blob e la cancellazione soft, vedi Interazioni tra le caratteristiche.
La seguente tabella descrive la modalità di fatturazione di un BLOB eliminato temporaneamente, a seconda che il controllo delle versioni sia abilitato o disabilitato. Abilitando il controllo delle versioni, viene creata una nuova versione quando si elimina temporaneamente un BLOB. Disabilitando il controllo delle versioni, l'eliminazione temporanea di un BLOB crea uno snapshot con la funzione eliminazione temporanea abilitata.
| Sovrascrivendo un BLOB di base con il relativo livello di accesso impostato in modo esplicito... | Allora sarà addebitato... |
|---|---|
| Se si abilitano sia l’eliminazione temporanea che il controllo delle versioni dei BLOB | Tutte le versioni esistenti in base all’intera lunghezza del contenuto, indipendentemente dal livello di accesso. |
| Se l'eliminazione temporanea del BLOB è abilitata, ma il controllo delle versioni è disabilitato | Tutti gli snapshot esistenti con la funzione eliminazione temporanea abilitata in base all’intera lunghezza del contenuto, indipendentemente dal livello di accesso. |
Limitazioni note
Non puoi creare snapshot per i blob nel tier di accesso archivio.
Il supporto per lo snapshot degli account Data Lake Gen2 non accetta più nuovi clienti. Invece, usa blob soft delete, AzCopy o Vaulted Backup.
Non puoi eliminare un blob mentre ha snapshot attivi a meno che la chiamata di eliminazione non includa
x-ms-delete-snapshots.La replica degli oggetti non replica gli snapshot.
Non puoi modificare gli snapshot dopo la creazione.
Non è possibile acquisire un lease su uno snapshot.
Monitoraggio e risoluzione dei problemi
Non posso cancellare il mio blob base: il blob ha snapshot attivi. Usa Delete Blob con
x-ms-delete-snapshots: includeper eliminarli entrambi contemporaneamente.Il mio snapshot è scomparso dopo aver cancellato il blob base: eliminare il blob di base elimina definitivamente gli snapshot a meno che il blob non sia abilitato. Abilita la cancellazione soft per proteggere dalla cancellazione accidentale.
I costi del mio snapshot sono più alti del previsto: se cambi esplicitamente il livello di accesso del blob, paghi per la lunghezza completa del contenuto invece che solo per blocchi unici. Evita cambiamenti espliciti di livello sui blob con snapshot attivi quando possibile.
Visualizzazione e inventario degli snapshot: Nel portale, gli snapshot appaiono sotto il blob nel Storage Browser quando è abilitato Mostra snapshot blob . Per inventariare il conteggio degli snapshot e l'uso dello storage su un account, usa Archiviazione di Azure Blob Inventory e la metrica BlobCapacity in Monitoraggio di Azure.