Hanno detto:
La disumanità del computer sta nel fatto che, una volta programmato e messo in funzione, si comporta in maniera perfettamente onesta.
Argomenti nel blog
ArchLinux Small Business Server (29) - Backup (3)
Dopo aver "assimilato" il principio su cui si basa il concetto di hard link possiamo ora vedere in concreto come funziona la tecnica di snapshot backup usando semplicemente cp, mv e rsync. Questo lavoro si basa su una idea originariamente sviluppata da Mike Rubel in un suo articolo e ripresa e ampliata poi anche da altri. Vediamo di capirci qualcosa ;)
Strategia di esempio
Per semplificare la spiegazione supponiamo di voler realizzare questo:
- 3 snapshots giornalieri (daily.0 daily.1 daily.2)
- 2 snapshots settimanali (weekly.0 weekly.1)
I daily snapshots vengono creati il lunedì, mercoledì e venerdì, i weekly snapshots il sabato. Ribadisco che è un esempio, in realtà meglio fare qualcosa di più come vedremo alla fine.
Definiamo anche sorgente e destinazione dei backup:
- i nostri dati sono in /samba/share
- la nostra unità di backup è montata in /mnt/snapshots
Non facciamo troppo caso ora alla precisione dei comandi, poi utilizzeremo degli strumenti adatti che semplificato il processo.
Possiamo iniziare.
daily snapshots
Lunedì
Il primo giorno non dobbiamo fare molto, /mnt/snapshots è vuota e quindi dobbiamo sobbarcarci la fatica di copiare tutto (ma sarà l'unica volta), possiamo usare rsync:
rsync -a --delete /samba/share /mnt/snapshots/daily.0
Il lunedì successivo la situazione sarà ben diversa come vedremo dopo.
Ora, comunque, abbiamo questa situazione :

Niente di trascendentale.
Mercoledì
Il nostro backup più recente sarà sempre in daily.0, quindi il secondo giorno iniziamo con un bel :
cp -al /mnt/snapshots/daily.0 /mnt/snapshots/daily.1
Usando cp con i flag -al l'operazione è velocissima: infatti non vengono copiati i dati, ma vengono solo creati gli hard link di tutti i files presenti in daily.0 in daily.1 (ricordo che non è possibile creare un hard link di una directory). La situazione orà sarà questa:

Praticamente da entrambi le directory si accede agli stessi dati.
Ora eseguiamo di nuovo il nostro rsync su daily.0:
rsync -a --delete /samba/share /mnt/snapshots/daily.0
Cosa è successo ? Supponiamo che il nostro backup fosse di 10GB e che tra lunedì e mercoledì, semplificando, siano variati 2GB di dati. Dopo questo rsync la situazione sarà più o meno questa:

daily.0 punterà ai file non variati (zona 1) più ai nuovi files (zona 3), daily.1 alla zone "comune" (zona 1) più ai vecchi files che sono stati modificati (zona 2). rsync con il parametro --delete elimina dalla destinazione i files non più presenti nella sorgente, ma per la proprietà degli hard link (i dati non vengono fisicamente rimossi fino a quando esiste un hard link riferito ad essi) in realtà rimangono dove sono in quanto puntati dagli hard link in daily.1.
Complichiamoci ancora un po' la vita...
Venerdì
Facciamo "spazio" al nuovo backup che viene sempre eseguito in daily.0, quindi "trasliamo" le directory, copiamo gli hard link ed eseguiamo rsync di nuovo :
mv /mnt/snapshot/daily.1 /mnt/snapshot/daily.2
cp -al /mnt/snapshots/daily.0 /mnt/snapshots/daily.1
rsync -a --delete /samba/share /mnt/snapshots/daily.0
Ora il quadro si è complicato ancora un po', tipo così:

Senza tanti discorsi contorti :
- daily.2 -> 1+2
- daily.1 -> 1+3
- daily.0 -> 1+4
Mi pare che il concetto oramai sia chiaro. Entrando nelle varie directory di salvataggio ho l'illusione di avere a disposizione dei backup completi di tre giorni diversi, ma, tornando al nostro esempio, lo spazio occupato non è di 30GB ma di 10+2+2 supponendo che ogni due giorni il 10% dei dati risultino variati (percentuale che cala statisticamente all'aumentare della mole dei dati). Dunque già ora ho un risparmio di oltre il 50% di occupazione disco, senza mettere in preventivo il consistente risparmio di tempo che questa tecnica porta nell'esecuzione del backup.
Secondo ciclo
Ma andiamo avanti, cosa succede quando ritorna lunedì ? Abbiamo detto che ci bastano tre snapshots e quindi ci liberiamo del più vecchio, "trasliamo", copiamo/creiamo gli hard link e rieseguiamo rsync su daily.0:
rm -rf /mnt/snapshot/daily.2
mv /mnt/snapshot/daily.1 /mnt/snapshot/daily.2
cp -al /mnt/snapshots/daily.0 /mnt/snapshots/daily.1
rsync -a --delete /samba/share /mnt/snapshots/daily.0
Ma ora attenzione: cosa ha eliminato il comando rm -rf /mnt/snapshot/daily.2 ?
Abbiamo visto che, da figura 8, daily.2 contiene hard link che puntano alla "zona 1" e alla "zona 2". Eliminando la directory in realtà solo gli hard link e i rispettivi dati della "zona 2" vengono eliminati in quanto i dati della "zona 1" solo linkati anche da daily.0 e daily.1 e dunque non vengono rimossi (per la nota proprietà degli hard link, bla bla bla...)
Da questo momento in avanti il ciclo ha preso il via e prosegue sempre in questo modo.
weekly snapshot
Non abbiamo finito. Abbiamo detto che vogliamo mantenere due salvataggi settimanali, weekly.0 e weekly.1 per risalire anche ai dati di un paio di settimane prima.
Sabato
Stessa roba del daily, penserete voi, invece no :D. E' molto più semplice e rapido.
Abbiamo visto che dal secondo ciclo nel daily viene eliminato lo snapshot più vecchio (daily.2), allora non basta "metterci via" questo prima che venga eliminato ? Certo che sì, e basta un :
cp -al /mnt/snapshots/daily.2 /mnt/snapshots/weekly.0
operazione che dura pochissimo, ma che di fatto "congela" i dati più vecchi. Infatti a questo punto il comando rm -rf /mnt/snapshot/daily.2 del lunedì successivo non eliminerà "fisicamente" nemmeno i dati della "zona 2" essendo ora linkati da weekly.0. Ma come siamo fuuuurbi :D.
Il sabato successivo "trasliamo" weekly.0 così:
mv /mnt/snapshots/weekly.0 /mnt/snapshots/weekly.1
cp -al /mnt/snapshots/daily.2 /mnt/snapshots/weekly.0
al sabato ancora successivo si entra nel ciclo infinito, che comprenderà anche l'eliminazione dello snapshot settimanale più vecchio :
rm -rf /mnt/snapshot/weekly.1
mv /mnt/snapshots/weekly.0 /mnt/snapshots/weekly.1
cp -al /mnt/snapshots/daily.2 /mnt/snapshots/weekly.0
Lo snapshot settimanale, quindi, è estremamente rapido e non esegue nemmeno un rsync dalla sorgente: può anche essere tranquillamente schedulato in coda al daily del venerdì o immediatamente prima di quello del lunedì.
Tutto qua. Velocità (solo un backup "completo", poi solo incrementale/differenziale), e semplicità usando comandi disponibili in qualsiasi distro. E io aggiungo pure ingegnoso, quando ho scoperto questa tecnica sono veramente rimasto meravigliato.
La fantasmagorica e abbagliante TimeMachine di Apple sfrutta un meccanismo molto simile, reso più efficente e veloce dal fatto che mentre il nostro rsync deve comunque "spazzolare" l'intero file system per trovare i file modificati, TimeMachine più furbamente usa le informazioni memorizzati sugli inode per scovare i file da copiare o eliminare. Ma non escludiamo di arrivarci pure noi un giorno.
Ora se qualcuno stà già eleborando mirabolanti script in bash che automatizzano il processo descritto, dico di pazientare ancora un po': c'e' già chi lo ha fatto per noi.
A portata di pacman ;)
Alla prossima.
