Alla ricerca del Backup Perfetto

/images/backup.thumbnail.png

English version here

Backup: perché farlo

Da che mondo è mondo, tutto può essere perso. Sia per ragioni accidentali che per ragioni ben ponderate, qualsiasi cosa può essere fatta sparire o può sparire per errore. Quante volte ci sarà capitato di perdere un oggetto e non trovarlo mai più?

Da quando esiste l'informatica, poi, questo concetto si è espanso a dismisura. Mentre è difficile perdere un oggetto, è molto più facile cancellare un file o una informazione dal computer, oppure voler ripristinare una versione precedente.

Molte persone pensano che sia sufficiente garantire che il supporto di memorizzazione sia ridondato, e si è a posto. SBAGLIATO!: un raid senza dubbio aiuta a non perdere tutto in caso di guasto di un disco, ma cosa accade quando il dato viene accidentalmente cancellato, quando viene compromesso per colpa di un virus o di una qualsiasi entità esterna, oppure quando l'elaboratore (raid o meno) viene rubato, o prende fuoco, o una situazione di questo tipo?

Ho collezionato esperienze di ogni genere. Tanto per elencarne alcune:

  • sale server finite sott'acqua per colpa di alluvioni

  • server distrutti dal terremoto, ovvero da crolli murari che hanno investito le sale macchine

  • ransomware vari, che ultimamente colpiscono molto più che in passato

  • danno volontariamente causato da qualcuno che ne ha tutto l'interesse (es: aziende informatiche che, poco correttamente, causano danni per crearsi lavoro. Sì, ho visto anche questo, e non una sola volta, purtroppo. E sto gestendo una situazione del genere proprio in questi giorni.)

  • errori da parte dell'amministratore (può succedere a chiunque)

Se poi parliamo di server esposti su Internet (es: e-commerce, server di posta elettronica, ecc.), la situazione diventa ancor più delicata in quanto oltre che la correttezza dei dati, c'è bisogno di garantire anche la continuità operativa del servizio.

La soluzione migliore, dunque, è avere sempre dei backup a disposizione. Ma quali caratteristiche dovrebbero avere questi backup?

Backup: come farlo

Di strumenti di backup ne esistono moltissimi, ognuno focalizzato su uno specifico elemento. Da suite completissime come Bacula e Amanda, a piccoli strumenti focalizzati solo a delle specifiche necessità.

Nel complesso, non è facile orientarsi nel mondo degli strumenti, open source o a pagamento, per cui la prima cosa da fare è porsi una serie di domande:

"Quanto sono disposto a rischiare? Cosa voglio preservare? Quanto fermo posso permettermi di avere in caso di perdita dei dati? Quanto e quale spazio ho a disposizione?"

La prima domanda è la più delicata, e a volte è sia causa che conseguenza delle scelte tecniche fatte. Alcune persone ritengono che sia sufficiente avere una copia di sicurezza all'interno della stessa macchina che si vuole "backuppare". La scelta può essere semplice & pratica, ma cosa accade in caso di guasto della macchina stessa? Il classico disco USB collegato e su cui vengono copiati i file ogni giorno è a rischio di guasto tanto quanto il resto dell'hardware. E no, non ditemi che il gruppo di continuità assicura l'assenza di sbalzi forti. Ho visto gruppi da migliaia di euro bruciarsi e bruciare tutto ciò che c'è dietro. Con buona pace dell'amministratore che si sentiva al sicuro. Andate pure a chiedere i danni all'assicurazione. Probabilmente i soldi arriveranno, di certo non i vostri preziosi dati.

Il primo passo, quindi, è avere un piano di gestione. Decidere a priori se la bilancia deve pendere di più verso la sicurezza o verso l'economicità.

Il backup più sicuro, infatti, è quello più distante possibile dalla macchina che si vuole mettere in sicurezza.

Questo però crea due problemi: più dati vogliamo tenere in sicurezza, maggiore sarà la necessità di spazio e di banda. Se vogliamo infatti memorizzare su un dispositivo separato, esso dovrà essere collegato (ragionevolmente via rete) al nostro hardware principale e dovrà poter ospitare tutti i dati che dobbiamo preservare. Se tutto ciò potesse avvenire in LAN, non dovremmo avere grossi problemi. Se invece volessimo tenere i nostri backup fuori dalla nostra rete, dovremo fare i conti anche con la connettività. Dunque potremmo decidere di memorizzare meno dati, per garantire una maggior velocità operativa, sia in fase di backup che, a maggior ragione, di eventuale ripristino.

Più sicuro, infatti, non vuol dire più pratico. Se avessi una connessione a 7 MBit/sec e 30 GB di dati nel backup, quanto tempo impiegherei per recuperare tutto in caso di perdita? Posso dunque permettermi un fermo così importante? Se si parla delle foto delle vacanze del 2000, probabilmente sì (a meno di un forte attacco di nostalgia), ma se parliamo di dati importanti che fermano la produttività di un'azienda, siamo sicuri di poter essere così pazienti? E se si parla di una cartella sanitaria?

Proprio per questa ragione, bisogna studiare al meglio la politica di backup più adatta alle proprie esigenze, ricordando che non esiste una soluzione che sia migliore in assoluto.

Backup dell'intero disco o dei singoli file?

Una delle prime domande che dobbiamo porci è proprio questa. Entrambe le soluzioni hanno dei vantaggi e degli svantaggi, elencherò i principali:

Intero disco (o storage)

Vantaggi

  • Facile ripristino completo in caso di perdita dati. Basterà fare un restore dell'intero backup sul disco originale, e tutto tornerà esattamente come prima

  • Spesso la soluzione integrata nei sistemi di virtualizzazione (es: Proxmox), semplice da gestire sia da riga di comando che da interfaccia

  • Sempre nell'ambito della virtualizzazione, ci sono prodotti (es: Veeam Backup) che permettono anche il recupero dei singoli file, consentendo una doppia possibilità.

Svantaggi

  • Su macchine fisiche, sarà praticamente sempre necessario spegnere la macchina per effettuare un backup di questo tipo, interrompendone l'operatività per tutto il tempo di elaborazione.

  • Lo spazio occupato può essere importante, in quanto verranno copiate anche alcune cose di cui potrebbe non importarci nulla.

  • L'operazione può essere lenta, in quanto il disco dovrà essere scansionato bit per bit. In caso contrario e/o con prodotti che utilizzano delle tecniche di analisi del file system per ottimizzare i tempi, la procedura potrebbe fallire in caso di impostazioni del file system in maniera non standard. (es: mi è capitato un cliente con un disco formattato direttamente, senza partizioni dentro. Tutto funziona, ma il Veeam non è in grado di effettuare un backup affidabile (tantomeno un recupero) proprio per questa scelta di configurazione).

In molti casi, questa può comunque essere la soluzione migliore. Oppure essere una base di partenza per avere un quadro completo, a cui poi far seguire dei backup più leggeri. Uno degli strumenti che utilizzo, in questi casi, è l'ottimo Clonezilla.

Singoli file

Qui la situazione si complica. A livello teorico, sembrerebbe la soluzione più semplice e comoda, ma non è sempre così.

Vantaggi

  • Realizzabile anche con utility di base del sistema (tar, cp, rsync, ecc.).

  • Maggior granularità: I singoli file possono essere backuppati, confrontati ai backup precedenti.

  • Possibilità di backup solo dei delta, copiando solo le parti modificate dei file riducendo sia lo spazio di stoccaggio che la quantità di dati da trasferire.

  • Portabilità: i file possono essere singolarmente spostati da un supporto all'altro.

  • Semplicità di ripristino parziale: si può scegliere cosa ripristinare e dove.

  • Possibilità di compressione/deduplicazione a livello di file o di blocco.

  • Possibilità di backup e ripristino senza la necessità di spegnere la macchina.

Svantaggi

  • Le soluzioni più semplici rischiano di richiedere moltissimo spazio di archiviazione.

  • Per un backup completo efficiente, sarebbe opportuno effettuare una snapshot (VSS, in terminologia Microsoft) del file system prima di iniziare la copia.

  • Potrebbero nascondersi delle insidie e restare celate fino al momento in cui si avrà bisogno del backup.

Backup: come lo faccio

Nel complesso, utilizzo entrambe le soluzioni, ovvero backup di macchine complete e di singoli file, a seconda delle necessità e delle situazioni. Le mie scelte, nel corso degli anni, sono state abbastanza costanti. Nello specifico, credo che avere dei backup a massima granularità sia la scelta migliore, anche perché in molti casi mi è capitato di dover recuperare qualche file o una serie di e-mail erroneamente cancellate da qualche cliente distratto.

Nello specifico, credo che un buon backup debba avere alcune caratteristiche di base:

  • possibilità istantanea di recupero, e velocità di elaborazione sufficientemente alta.

  • deve essere esterno.

  • sicurezza - no, non piazzerei mai un backup su Dropbox o Google Drive, ecc.

  • una gestione efficiente dello spazio.

  • compressione e deduplicazione, meglio se effettuati off-line.

  • il sistema deve essere il meno invasivo possibile. Non deve richiedere l'installazione di troppe componenti.

Ci sono varie correnti di pensiero, quelle che dicono che la macchina da backuppare dovrebbe avere accesso diretto al server di backup e quella che dice che è il server di backup a dover contattare i sistemi da mettere in sicurezza. Entrambe le soluzioni hanno i loro vantaggi e svantaggi, ma nel mio caso preferisco che sia il server a contattare i client, e per due motivi ben precisi: 1) a mio avviso è più facile tenere "nascosto" e sicuro un server che lasciare tante porte d'accesso ad esso da tutti i client e 2) in questo modo riesco a programmare i backup secondo una logica ben precisa (es: finito il primo, passa al secondo). Altrimenti diventa più difficile e c'è il rischio che si accavallino troppi backup, saturando le risorse della macchina.

rsync puro

Storicamente ho utilizzato (e lo utilizzo ancora, su alcuni server) uno script fatto da me basato su rsync e su hard link. In pratica, ogni backup parte dal precedente. Se il file non è cambiato, viene semplicemente creato un hard link e non viene occupato spazio ulteriore. Se è stato modificato, viene copiata solo la differenza (grazie a rsync), ma un nuovo file (con lo stesso nome) viene generato sul file system. E così via, giorno per giorno, per tutti i server.

Vantaggi

  • ho sempre una copia completa e immediatamente utilizzabile dei file, per cui il backup è "pronto all'uso". Ripristinabile in qualunque momento, recuperabile su qualsiasi supporto

  • lo spazio utilizzato non è la somma dei backup, ma la somma del primo e del totale dei file modificati. Attenzione: NON delle differenze dei file.

  • semplicissimo da realizzare

  • non richiede altro che rsync e un accesso alla macchina (normalmente, ssh)

Svantaggi

  • se non viene predisposto un sistema di snapshot, i file vengono copiati al volo. Nel caso di un database molto utilizzato, esso sarà inutile in quanto il ripristino genererà dei file non funzionanti

  • inefficiente a livello di spazio: a meno di usare dei file system con deduplicazione integrata (es: ZFS), ogni minima modifica ad ogni file richiederà uno spazio di archiviazione pari alla dimensione del file. Es: se aggiungo una riga ad un database di 10 GB, il backup successivo occuperà 10 GB in più del precedente, in quanto dovrà essere salvata una copia intera del file del database stesso

  • a meno di utilizzo di un file system compresso, tutti i file saranno non compressi

Questa è dunque un'ottima tecnica se si vuole tenere il backup di poche macchine o di macchine non enormi, e se non si vuole avere uno storico troppo ampio.

La mia attuale scelta preferita: BURP

Arrivato dunque al punto di avere centinaia di server (e i miei PC) da archiviare ogni giorno, alcuni anche più volte al giorno, ho dovuto necessariamente trovare un'alternativa più completa e "professionale".

Ho usato per circa un anno l'ottimo storeBackup, che ho integrato con alcuni miei script per centralizzarne il backup, ma l'ho scartato perché richiede che i backup partano appunto dal client stesso, non dal server. Molto efficiente, comunque, ed è una soluzione che consiglio senza riserve.

Ho poi effettuato alcuni test con altri prodotti (Obnam, Attic, ecc.) ma per varie ragioni sono stati scartati (nello specifico, o per la stessa ragione per cui ho abbandonato storeBackup oppure per ragioni di prestazioni). Ho iniziato ad usare BackupPC, soluzione che tutt'ora prediligo quando voglio dare ad un cliente un sistema di backup chiavi in mano, comodo da usare via web e da dimenticare, perché in caso di problemi sarà lui a contattarci e dircelo. BackupPC è una eccellente soluzione, lo utilizzo da più di 10 anni, ma ha il problema che richiede un backup "full" e una serie di incrementali, per cui ogni tanto ci vuole comuqnue un bel backup completo. Il risultato: in rete, può essere pesante o sovraccaricare. Ho dunque deciso di non utilizzarlo più per server interi o da remoto.

Alla fine, sono approdato a BURP, un eccellente sistema integrato. Esso ha soddisfatto quasi tutte le mie aspettative, rispondendo a meraviglia ai requisiti che ho elencato precedentemente:

  • c'è un server, che coordina, e i client. Le chiavi di comunicazione vengono generate al primo contatto, grazie ad una password, e vengono mantenute. I client potranno contattare il server in qualunque momento, ma è il server che decide se e quando il backup può avvenire, e come.

  • il software è piccolo e leggero, e sono riuscito ad installarlo senza problemi su tutti i miei server e relativi sistemi operativi, anche embedded.

  • ha un sistema intelligente di trasferimento: utilizzando la stessa libreria di rsync, copia solo le differenze dei singoli file (e non i file interi). A differenza di rsync, però. è in grado di memorizzare solo i "delta", ovvero le differenze, tra varie generazioni. Tanto per riprendere l'esempio precedente, in caso di aggiunta di una riga ad un database di 10 GB, lo spazio occupato dal backup successivo sarà all'incirca quello della riga.

  • ottimizzazione del backup "off-line": alla connessione del client, esso invierà la lista file. Il server la confronterà con ciò che ha, e chiederà al client di trasferire solo le differenze o i file nuovi. Alla fine, terminata la connessione, il server ottimizzerà il tutto e genererà al suo interno tutte le strutture necessarie, i collegamenti, ecc. Il client, a quel punto, ha già finito il suo lavoro.

  • tutti i dati possono essere compressi e deduplicati. Nella versione 1.x attraverso una utility esterna da loro fornita (che attivo una volta alla settimana), dalla versione 2.x (in sviluppo, non ancora stabile) esso verrà effettuato alla fine dei backup, in automatico.

  • Una comoda interfaccia ncurses (e web, anche se la uso meno) per controllare il tutto.

Da quando ho installato BURP, i miei backup sono diventati rapidissimi, leggeri e con un'ottima granularità. Il sistema si gestisce da solo, aggiungere un client è semplicissimo e arrivano delle comode e-mail che mi aggiornano sulla situazione.

Il supporto Windows è poi eccellente, esegue da solo il VSS delle unità e auto-aggiorna l'app (Windows, appunto) se lo si vuole. Grazie a delle guide reperibili sul sito del progetto stesso, è possibile recuperare un'intera installazione Windows da un backup e permetterne il boot, cosa non sempre scontata quando si decide di fare una copia dei singoli file.

Per concludere, non esiste IL sistema di backup perfetto, ma BURP, almeno per ora e già da circa un anno, è senza dubbio la mia scelta preferita. L'importante è ricordare sempre una regola generale: meglio avere un backup in più che uno in meno.

Per maggiori informazioni o per avere una consulenza sul vostro sistema di backup o su possibili soluzioni per la vostra realtà, contattate pure Dragas IT

Commenti