Biscotti al burro

biscotti

EDIT (2014-02-07):

  • ho aggiunto lo screenshot di un “pool” di snapshot;
  • ho aggiornato lo script updatesnapshots in modo da poter far convivere sullo stesso server remoto backup di due o più volumi btrfs appartenenti ad un unico host locale.

ATTENZIONE: in questo post non è di biscotti che si parla, ma di btrfs (butter-fs) il nuovo strabiliante filesystem di Linux. Vedremo perché con un po’ di “burro di mucca” non solo i biscotti diventano più buoni, ma anche i nostri backup.
Recentemente mi sono avvicinato ai file system di “prossima generazione” (http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/) perché, grazie ad un paio di loro caratteristiche (supporto agli snapshot CoW e possibilità di trasferire tali snapshot su server remoti come copie incrementali) consentono di implementare un pratico ed elegante sistema di backup remoto. Ma analizziamo le due caratteristiche (snapshot CoW e trasferimenti incrementali) separatamente.

Due parole sulla mucca (CoW)

Innanzi tutto, uno snapshot (istantanea) altro non è che un salvataggio dell’intero volume effettuato in un determinato istante di tempo, in modo da poter ripristinare, in caso di evento catastrofico, il volume  esattamente come era al momento dello snapshot. Tradizionalmente si realizza mediante la copia completa di tutto il contenuto del volume su una sottocartella, su un’altra partizione, su un altro disco oppure su un server remoto. Caratteristiche salienti degli snapshot “vecchio stile” sono: a) ogni snapshot occupa una quantità di spazio uguale a quella del volume originale; e b) l’operazione di copia richiede una (notevole) quantità di tempo, proporzionale alla quantità di dati presenti nel volume. La tecnica CoW (Copy on Write), tipica dei file system più avanzati, consente di superare entrambi questi inconvenienti.  Il CoW lavora così: durante la creazione dello snapshot, i dati sul disco non vengono effettivamente copiati, ma vengono semplicemente duplicati i relativi riferimenti (fino a qui assomiglia alla tecnica degli hard link usata da Time Machine di Mac OS X e rsnapshot). Questa situazione di due copie logiche (“live volume” e snapshot) che condividono un’unica copia fisica permane fintantoché non viene modificato un file. Al momento della modifica, e solo a questo punto, il sistema operativo crea una copia del blocco di dati interessato, assegna la nuova copia al live volume (mentre lascia lo snapshot “agganciato” al blocco di dati originale), ed applica la modifica solamente alla copia, lasciando invariato l’originale. Et voila: se si accede attraverso lo snapshot si continua a vedere il file come era in origine, mentre se si accede attraverso il volume, si vede il file aggiornato alle ultime modifiche. Una volta noto il meccanismo, è facile comprendere come lo spazio occupato su disco non dipende tanto dal numero di snapshot che sono stati creati, ma piuttosto dal numero e dalle dimensioni delle modifiche che sono state apportate al volume successivamente alla creazione degli snapshot. In altre parole, lo spazio occupato aumenta in maniera proporzionale alla “divergenza” tra snapshot e live volume: fino a che nessuna modifica è stata fatta, avere zero, uno o 100 snapshot non cambia lo spazio occupato. Inoltre, cosa molto importante, la creazione di uno snapshot è un’operazione praticamente istantanea, indipendentemente dalla dimensione del volume: creare uno snapshot di un volume di 10MB impiega lo stesso tempo che creare uno snapshot  di un volume di 120 GB, ossia meno di un secondo!

Una nota a proposito di programmi, come Time Machine di Mac OS X e rsnapshot, che usano il metodo degli hard link; gli hard link sono nomi di file distinti che, però, condividono lo stesso inode (bovinamente, la stessa area dati) del file system. La differenza principale rispetto alla tecnica CoW è che, nel caso degli hard link, se il file A e il file B sono l’uno l’hard link dell’altro, le modifiche effettuate sul file A vengono scritte sull’unico inode realmente esistente, e quindi risultano applicate anche al file B. Viceversa, con la tecnica CoW, i file A e B sono liberi di divergere. È per questo motivo che sia Time Machine che rsnapshot, prima di apportare modifiche ad un file, in modo da mantenere l’originale intatto, lo “sganciano” da eventuali altri hard link, effettuando un’operazione in più che, nel caso di file system con CoW, viene effettuata “gratis” dal sistema operativo. Inoltre, mentre il CoW lavora a livello di blocchi di dati dell’ordine di pochi KB, gli hard link riguardano i file interi. Questo significa che se viene modificato un file della dimensione di, facciamo un esempio, 20 GB (come potrebbe essere l’immagine di un disco di un virtual PC), nel caso degli hard link si otterrebbero due file da 20 GB, per un totale di 40 GB occupati, mentre nel caso del CoW otterremmo un totale di 20 GB + le modifiche.

Trasferisco tutto, o solo un po’?

Adesso veniamo alla seconda caratteristica: il trasferimento incrementale. Quando si tratta di mantenere sincronizzato un clone remoto dei nostri snapshot ci si può scontrare con i limiti di banda delle connessioni Internet (nostrane, ma non solo). Si pensi che, con una banda di upload di 500 kbps, per trasferire uno snapshot di 20 GB occorrono circa 343.600 secondi, pari a quasi 4 giorni. Un sacco di tempo! E ci si deve augurare che in quei 4 giorni, durante i quali la propria connessione Internet sarà praticamente “inchiodata”, vada tutto liscio come l’olio, perché ogni intoppo costringerebbe a ricominciare da capo. Proprio per ovviare a questi problemi, ecco che si è pensato ad un sistema per cui, in remoto, vengono trasferite solamente le differenze che lo snapshot più recente presenta rispetto ad uno già trasferito in precedenza (tecnica nota come trasferimento “incrementale”). In questo modo, solo la sincronizzazione iniziale sarà gravosa, mentre tutte le sincronizzazioni successive potranno essere effettuate trasferendo una quantità di dati molto esigua. Grazie al trasferimento incrementale si rende possibile uno scenario in cui, anche con una connessione ADSL domestica, è possibile mantenere aggiornato un archivio remoto costituito da un certo numero di snapshot passati dei propri file system, con un’occupazione irrisoria di risorse di calcolo, spazio disco e banda passante.

Vai: sono pronto! Ma… in pratica?

Accedere a questo set di vantaggi, però, richiede di utilizzare, sia in locale che in remoto, un file system “moderno” che abbia le due caratteristiche di cui si è parlato sopra. Tra i due più in voga al momento, ZFS e btrfs, entrambi hanno le caratteristiche richieste (come anche altre – quali la gestione di vari livelli RAID – che non servono in questo contesto). Ho scelto di fare esperimenti con btrfs perché è nativo di Linux e ormai è supportato dalle distribuzioni più diffuse. ZFS è più stabile (è nato prima e quindi è più collaudato), ma è stato sviluppato inizialmente da Sun per il suo Solaris, solo recentemente registra una certa diffusione anche su Linux e, di solito, richiede l’aggiunta manuale dei relativi driver.

Ho preparato due PC con una versione recente di Ubuntu Linux (la 13.10, per la precisione) ed ho installato su entrambi il pacchetto btrfs-tools. Su entrambi i PC ho creato una partizione di 10 GB e le ho formattate con il file system btrfs (comando mkfs.btrfs). Il primo PC, d’ora in avanti “PC-A”, l’ho usato come PC di produzione, quello sul quale normalmente si lavora. Il secondo PC, ovviamente “PC-B”, l’ho usato come server di backup, l’host remoto sul quale trasferire gli snapshot del PC-A via rete. Sul PC-A, ho montato la partizione btrfs sulla posizione /mnt, mentre, sul PC-B, ho montato la relativa partizione btrfs sulla posizione /backups. Siccome la comunicazione tra il PC-A e il PC-B avverrà attraverso il protocollo ssh, sul PC-B ho installato il server ssh (pacchetto openssh-server). Inoltre, in modo da connettersi con ssh da PC-A a PC-B senza dover inserire la password, ho creato su PC-A una coppia di chiavi ssh per l’utente root, e ho copiato la chiave pubblica di root@PC-A sulla configurazione ssh di root@PC-B (qui ci sono istruzioni più estese su come fare: http://www.html.it/articoli/come-autenticarsi-in-linux-senza-password-con-le-chiavi-ssh-1/). Quindi ho scritto lo script di shell updatesnapshots (scaricabile sotto), da eseguire come utente root su PC-A, che svolge le operazioni seguenti:

  1. appena lanciato, crea un nuovo snapshot locale del file system montato su /mnt nella posizione /mnt/.snapshots/snapshot_2014-01-23 T11:56:59+0100, dove il nome è il timestamp dello snapshot;
  2. verifica che il server remoto (PC-B) sia raggiungibile;
  3. se PC-B è raggiungibile, si trasferiscono su PC-B tutti gli snapshot locali non ancora trasferiti;
  4. per non occupare troppo spazio sul disco remoto, e se PC-B è raggiungibile, si cancellano gli snapshot remoti più vecchi, in modo da non avere mai più di 10 snapshot archiviati;
  5. per non occupare troppo spazio sul disco locale, se il numero degli snapshot locali è maggiore di 5, si cancella lo snapshot locale più vecchio.

Il risultato finale, dopo qualche ripetizione, è quello dell’immagine (cliccaci sopra per ingrandire):

screenshot

I nomi delle cartelle – locali e remote -, l’indirizzo di PC-B, e altri parametri, sono inseriti nello script, e non è affatto difficile personalizzarli come si vuole. Lo script andrebbe lanciato periodicamente mediante cron, con frequenza dipendente dalle proprie politiche di backup. Ad esempio, una volta ogni ora, una o due volte al giorno, una volta alla settimana, etc. Questo è un punto di partenza, molto semplice, ma già funzionante: ovviamente ognuno è libero di usare e modificare il mio script come meglio crede. Applicando lo stesso paradigma è possibile pensare di avere PC-B non nella propria rete locale, ma “off site” (a casa di un amico, in ufficio, o su un server “on the cloud”) e raggiungerlo attraverso Internet. L’uso di ssh garantisce la riservatezza e l’integrità dei dati durante il trasferimento, e avere i backup in remoto pone al riparo anche da furti, incidenti domestici, incendi, alluvioni etc.: di questi tempi… non si sa mai!

Spero di aver stuzzicato la fantasia di qualcuno e… alla prossima!

Download

Advertisements

Un pensiero su &Idquo;Biscotti al burro

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...