Quasi ogni provider cloud offre, con un clic, la possibilità di fare uno snapshot di un disco o di un'intera macchina virtuale. È veloce, economico e rassicurante. Molti progetti si fermano lì, convinti di essere protetti. In realtà uno snapshot risolve alcuni problemi e ne lascia scoperti altri, spesso proprio quelli più gravi.
Che cos'è uno snapshot
Uno snapshot è una fotografia dello stato di un disco in un preciso istante. Nella maggior parte dei servizi il primo snapshot copia tutti i blocchi usati, i successivi solo quelli cambiati. Per questo sono rapidi da creare e occupano relativamente poco spazio.
Gli snapshot sono ottimi per alcuni scopi:
- tornare indietro dopo un aggiornamento di sistema andato male;
- clonare un server per creare un ambiente di prova;
- spostare un disco in un'altra zona o regione;
- avere un punto di ripristino recente, con frequenza oraria o giornaliera.
I limiti dello snapshot
Stesso account, stesso destino
Lo snapshot vive di solito nello stesso account e spesso nella stessa regione delle risorse che protegge. Se qualcuno ottiene le credenziali di amministratore dell'account, può cancellare i server e gli snapshot nello stesso minuto. Lo stesso vale per un errore umano grossolano, come uno script che elimina tutte le risorse con un certo prefisso, o per un problema con il fornitore: un pagamento non riuscito, un account sospeso, una contestazione.
Un backup che può essere distrutto insieme all'originale con la stessa credenziale non è un vero backup.
Coerenza dei dati
Uno snapshot fatto mentre un database sta scrivendo è detto crash-consistent: corrisponde a ciò che troveresti staccando la corrente al server in quell'istante. I database moderni sono progettati per recuperare da questa situazione, ma non è garantito per ogni applicazione, e i dati in memoria non ancora scritti su disco vanno persi.
Per un ripristino affidabile di un database servono backup coerenti a livello applicativo: un dump fatto con gli strumenti del database stesso, oppure uno snapshot preceduto dal blocco momentaneo delle scritture, oppure i backup automatici del servizio di database gestito, che includono i log per il ripristino a un istante preciso.
Granularità
Per recuperare un singolo file cancellato da uno snapshot, spesso bisogna creare un disco nuovo dallo snapshot, collegarlo a una macchina, cercare il file e copiarlo. Funziona, ma è lento. Un backup a livello di file permette di recuperare un documento in pochi secondi.
Conservazione
Gli snapshot sono pensati per il breve periodo. Tenerne centinaia per anni diventa costoso e disordinato. Per conservare i dati a lungo, ad esempio per obblighi contabili o contrattuali, servono copie organizzate con regole di conservazione chiare.
Confronto in sintesi
| Aspetto | Snapshot | Backup vero |
|---|---|---|
| Velocità di creazione | Molto alta | Variabile |
| Dove si trova | Stesso account e regione | Separato, idealmente altro account o fornitore |
| Coerenza per database | Non garantita | Garantita con strumenti dedicati |
| Recupero di singoli file | Laborioso | Immediato |
| Protezione da cancellazione | Bassa | Alta, se immutabile |
| Conservazione lunga | Costosa | Pensata per questo |
Come costruire una protezione completa
La soluzione non è rinunciare agli snapshot, ma affiancarli a qualcosa di diverso.
- Snapshot frequenti per il ripristino rapido dopo errori o aggiornamenti, con conservazione di pochi giorni.
- Backup applicativi dei database e dei file importanti, fatti con gli strumenti adatti a ciascun tipo di dato.
- Copia fuori dall'account: i backup vanno trasferiti in un account separato, con credenziali diverse, oppure presso un altro fornitore di storage. Chi gestisce la produzione non dovrebbe poter cancellare questa copia.
- Immutabilità: molti servizi di object storage offrono il blocco degli oggetti, spesso chiamato object lock, che impedisce di modificare o cancellare un file fino a una certa data, anche all'amministratore. È la difesa più efficace contro il ransomware e contro chi ha rubato le credenziali.
- Cifratura dei backup, con chiavi custodite separatamente dai dati.
Il backup esiste solo se il ripristino funziona
Il punto più trascurato è il ripristino. Un backup mai provato è un'ipotesi. Periodicamente conviene ripristinare un database in un ambiente isolato, avviare l'applicazione e verificare che i dati siano completi e leggibili. È il momento in cui si scopre che mancava una cartella, che la password di cifratura era conservata solo su un portatile o che il ripristino richiede sei ore invece di una.
Nel mio lavoro la domanda che faccio per prima non è «avete un backup?», ma «quando avete ripristinato l'ultima volta, e quanto tempo ci è voluto?». La risposta dice molto di più sulla reale protezione dei dati.
In sintesi
- Gli snapshot sono rapidi ed economici, ottimi per tornare indietro dopo errori o aggiornamenti.
- Vivono nello stesso account delle risorse e possono essere cancellati insieme a esse.
- Per i database servono backup coerenti a livello applicativo, non solo snapshot dei dischi.
- Una protezione completa include copie in un account o fornitore separato, immutabili e cifrate.
- Solo un ripristino provato regolarmente dimostra che il backup funziona davvero.
