Articolo tradotto dal thread di
https://community.veeam.com/blogs-and-podcasts-57/snapshots-are-not-backups-2494
Molti di voi probabilmente hanno già sentito questa frase: gli snapshot non sono backup!
Solo per portare un esempio, la scorsa settimana un hosting provider tedesco ha perso 1500 snapshots a causa di un guasto hardware. E chi di noi non ha mai vissuto vere e proprie storie horror a proposito di snapshots dimenticati in VMware? Proprio per queste ragioni, ho voluto parlarne in questo blog post dedicato.
Cosa è uno snapshot?
In generale, uno snapshot è una istantanea nel tempo bloccata di un sistema o dato. Se spesso ci riferiamo agli snapshot in termini di macchine virtuali, è altresì vero che ci sono varianti di snap come storage o file.
Per le macchine virtuali, gli snapshot sono veri e propri dischi virtuali settati in sola lettura e tutte le modifiche relative a quel disco vengono reindirizzate su un altro file (relativo al disco stesso). Questo ovviamente varia a seconda della piattaforma virtuale utilizzata. Possono essere utilizzata per ripristini rapidi dello stato della virtual machine o anche durante i backup delle VM. E solitamente sono creati solo temporaneamente, o per lo meno dovrebbero.
Gli snapshot di file o dischi storage possono essere sfruttati per avere il versioning degli stessi ed essere replicati su differenti sistemi operativi, per venire incontro a una lunga conservazione dello stesso.
Chiariamo. Uno snapshot il più delle volte è dipendente (a livello temporale sempre in riferimento al versioning) alla sorgente del dato stesso. Non è una copia.
E cosa è invece un backup?
Un backup è molto simile ad uno snapshot, con l’unica differenza che si tratta di una copia indipendente dal file sorgente. Questa copia dovrebbe, non inteso come sarebbe meglio bensì come dovete farlo, essere conservata a livello di file su uno storage differente senza una correlazione diretta di credenziali/configurazione logica con la sorgente stessa (esempio semplificato: lo storage del backup non può avere le stesse credenziali dello storage di partenza del dato). Con la regola del 3-2-1-1-0, i backup andrebbero replicati su uno storage di tipo differente e tenuto offline e offsite.
Un ripristino da backup dovrebbe inoltre essere sempre “libero” e non legato all’hardware di partenza. Se ti esplode il server fisico devi poter ripristinare su un server differente il tuo backup.
Perché lo snapshot non è da considerarsi anche un backup?
Come avrete oramai già compreso, lo snapshot è dipendente dalla sorgente. Questo già lo esclude dall’essere considerato backup.
Se perdete l’origine del dato snapshottato (concedetemi l’italianizzazione di questo termine), perdete anche lo snapshot stesso poiché decade la catena di costruzione dei dati. Se a tutto questo poi aggiungiamo che gli snapshot delle virtual machine causano un maggiore carico di I/O sia quando attive che quando eseguite le operazioni di pulizia/merge, già questo ci dovrebbe portare a utilizzarle con parsimonia e dovuta attenzione. Snapshot dimenticati per troppo tempo ci possono complicare di brutto la vita.
D’altro canto, i backup sono indipendenti dalla sorgente e quindi qualsiasi cosa ad essa può succedere, dalla corruzione alla eliminazione, i backup restano funzionali e utilizzabili.
Quando usare allora gli snapshot?
Quando abbiamo necessità di basso Recovery Time Objective (RTO), ovvero la velocità necessaria per il ripristino. Esempi possono essere l’aggiornamento del OS, piuttosto che l’applicazione di patch.
Inoltre queste sono necessarie a programmi come Veeam per la creazione stessa dei backup, appoggiandosi temporaneamente a snapshot delle VM nel mentre delle operazioni pianificate e non. Durante un backup infatti, ci ritroveremo le vm con uno snapshot attivo.
Per quanto riguarda invece gli snapshot dei file, le shadow copies ne sono un chiaro esempio (tradotto in italiano in Versioni precedenti).
Per concludere, non bisogna mai scordare che se qualcosa si rompe gli snapshot non ci salvano la vita, ma i backup sì.
