Le istantanee sono importanti sia che tu stia eseguendo una semplice macchina virtuale sul tuo computer di casa sia che si tratti di un database aziendale che viene costantemente aggiornato e modificato. Avere delle istantanee, cioè una copia dell’intero filesystem com’era in un dato periodo di tempo è importante.
La gente spesso perde traccia di dove le cose sono andate male, un file è stato cancellato e nessuno ha notato che era sparito. Sono passati diversi backup e ora ci si rende conto che un file importante manca da tutti i backup disponibili delle ultime 5 settimane. In questo tutorial, vedremo come usare le istantanee ZFS e toccheremo varie politiche di snapshotting che funzionerebbero in modo ottimale, sia in termini di utilizzo delle risorse che di recuperabilità.
ZFS ha sia la visione di alto livello di file e directory che capisce come i dati vengono scritti sul disco. Quando si scrivono fisicamente i dati su un disco, lo si fa in blocchi discreti. Tipicamente, la dimensione del blocco può andare fino a 1 MB ma il default è di solito 128 KB. Ora, questo significa che ogni modifica (lettura, scrittura o cancellazione) avverrà nei blocchi discreti.
Il meccanismo copy-on-write assicura che ogni volta che un blocco viene modificato, invece di modificare direttamente il blocco, si fa una copia del blocco con le modifiche richieste fatte sul nuovo blocco.
Questo è particolarmente utile nei casi in cui, diciamo, c’è un’interruzione di corrente e il sistema si blocca mentre nuovi dati vengono scritti sul disco. Se questo accade in un filesystem tradizionale, i vostri file verranno corrotti o lasciati con dei buchi. Ma se state usando ZFS, potreste perdere la transazione in corso mentre ciò stava accadendo, ma l’ultimo stato valido dei vostri file rimarrà intatto.
Anche gli snapshot si basano su questa funzionalità, e abbastanza pesantemente in effetti. Quando si prende uno snapshot di un dato dataset (‘dataset’ è il termine ZFS per un filesystem), ZFS registra solo il timestamp quando lo snapshot è stato fatto. Questo è tutto! Nessun dato viene copiato e non viene consumato spazio extra.
Solo quando il filesystem cambia, e i dati al suo interno divergono dall’istantanea, l’istantanea inizia a consumare spazio extra. Quello che succede sotto il cofano è questo: invece di riciclare i vecchi blocchi nel tempo, ZFS li mantiene. Questo migliora anche l’utilizzo dello storage. Se fai uno snapshot di un dataset di 20GB e modifichi solo qualche file di testo qua e là, lo snapshot può richiedere solo pochi MB di spazio.
Creazione di snapshot
Per dimostrare l’uso degli snapshot, iniziamo con un dataset che ha molti file di testo, giusto per mantenere la questione semplice. La macchina virtuale che userò per la demo esegue FreeBSD 11.1-RELEASE-p3 che è l’ultima versione stabile disponibile al momento di questo scritto. Il filesystem di root è montato di default sul pool zroot e molte delle directory familiari come /usr/src, /home, /etc sono tutti i loro dataset montati su zroot. Se non sai cosa significa un pool (o uno zpool) nel gergo ZFS, varrebbe la pena di documentarsi prima di continuare.
Uno dei molti filesystem, o dataset, che sono di default su FreeBSD è: zroot/usr/src
Per vedere le sue proprietà, esegui il seguente comando.
:~$ zfs list zroot/usr/src
Come puoi vedere usa 633 MB di spazio. Contiene l’intero albero dei sorgenti del sistema operativo.
Facciamo uno snapshot di zroot/usr/src
:~$ zfs snapshot zroot/usr/
Il simbolo @ funge da delimitatore tra il dataset e il nome dello snapshot, che nel nostro caso è snapshot1.
Ora guardiamo lo stato dello snapshot mentre viene creato.
Eseguendo il comando:
zfs list -rt all zroot/usr/src
Si può vedere che lo snapshot non usa spazio extra quando nasce. Non c’è nemmeno spazio disponibile, perché è un dataset di sola lettura, lo snapshot stesso non può crescere, modificarsi o ridursi. Infine, non è montato da nessuna parte, il che lo rende completamente isolato dalla gerarchia del filesystem dato.
Ora, rimuoviamo la directory sbin in /usr/src/
:$ rm /usr/src/sbin
Guardando lo snapshot si vedrà che è cresciuto,
Questo è previsto perché il meccanismo di copy-on-write è al lavoro qui e cancellando (o modificando) i file ha portato a più dati associati solo allo snapshot e non al dataset effettivamente in uso.
Nota la colonna REFER nell’output precedente. Vi dà la quantità di dati accessibili sul dataset mentre la colonna USED vi mostra solo quanto spazio è occupato sul disco fisico.
Il meccanismo Copy-On-Write di ZFS dà spesso questi risultati controintuitivi, dove la cancellazione di un file farebbe sembrare che sia stato usato più spazio di prima. Tuttavia, avendo letto fin qui, sapete cosa sta realmente accadendo!
Prima di finire, recuperiamo lo sbin dallo snapshot1. Per farlo basta eseguire:
:/usr/src$ zfs rollback zroot/usr/
Politica di snapshoting
La prossima domanda da porsi è – Quanto spesso vuoi prendere le snapshot? Anche se può variare da un’impresa all’altra, prendiamo l’esempio di un database molto dinamico che cambia ogni tanto.
Per cominciare si inizierebbe a prendere le istantanee ogni 6 ore circa, ma poiché il database cambia così tanto, diventerebbe presto impossibile memorizzare tutte le numerose istantanee create. Quindi il passo successivo sarebbe quello di eliminare le istantanee che sono più vecchie di, diciamo, 48 ore.
Ora, il problema sarebbe quello di recuperare qualcosa che è stato perso 49 ore fa. Per aggirare questo problema, si possono tenere una o due istantanee da quella cronologia di 48 ore e tenerle in giro per una settimana. Eliminatele quando diventano più vecchie.
E se potete continuare in questo modo, potreste stipare istantanee fino alla genesi stessa del sistema, solo in ordine decrescente di frequenza. Infine, vorrei sottolineare che queste istantanee sono READ-ONLY, il che significa che se vieni infettato da un ransomware e tutti i tuoi dati vengono criptati (modificati). Queste istantanee sarebbero, molto probabilmente, ancora intatte.