Come eseguire il Backup di un Virtual Private Server

rsnapshot, uno strumento open source per il Backup di un VPS (Virtual Private Server).

Backup, croce e delizia di tutti i sistemisti (e non)! In informatica il Backup è inteso come un processo che prevedere la realizzazione di una copia di un dato (informazione) digitale per scopi e utilizzi futuri.

Il Backup può essere realizzato per diverse finalità:

  • preservare alcune viste (snapshot) di informazioni per un confronto;
  • ripristinare dati erroneamente cancellati;
  • eseguire attività di ripristino in caso di disaster recovery;
  • altre attività.

Quando si pianifica un’attività di Backup è necessario:

  1. avere una rendicontazione dell’attività di backup, la più dettagliata possibile;
  2. avere un monitoraggio dell’attività di backup (l’attività di backup deve essere rendicontata, con evidenza della corretta esecuzione);
  3. definire una pianificazione certa dell’esecuzione dell’attività di backup, preferibilmente automatizzata ed indipendente da attività legate all’operato umano;
  4. individuare una corretta localizzazione dei dati di backup rispetto ai dati originali;
  5. prevedere un’attività di verifica dei dati copiati, al fine di certificare il corretto ripristino in caso di necessità (in genere vengono simulate delle attività di ripristino e vengono eseguite delle analisi di corretta esecuzione sui dati ripristinati nell’area di test);
  6. definire il Recovery Point Objective (RPO), cioè il momento nel passato a cui risalgono i dati di backup;
  7. definire il Recovery Time Objective (RTO), cioè il momento nel futuro in cui il backup sarà di nuovo attivo e funzionante.

Possiamo considerare questa checklist come una guida per calibrare correttamente un backup di dati. Le tecniche e gli strumenti per realizzare il backup sono fortemente dipendenti dalla sorgente e dalle finalità.

In questo articolo verificheremo come mettere in sicurezza i dati localizzati in un VPS (Virtual Private Server) localizzato in un datacenter di un provider.

In linea generale, tutti i provider di datacenter consentono di pianificare backup integrali della macchina virtuale sotto il loro diretto controllo. Consiglio vivamente di abilitare queste forme di backup, perché consentono di ripristinare l’intero ambiente all’ultima versione stabile dell’ambiente, nel più breve tempo possibile.
In realtà questa soluzione non è priva di rischi, basti pensare al recente incendio che si è sviluppato al datacenter di Strasburgo della OVH.
In questo evento disastroso coloro che non avevano un backup di disaster recovery, localizzato fuori dal datacenter, hanno perso letteralmente tutto (dati ed ambiente).

Il backup offerto dai provider, da solo, non è sufficiente per mettere veramente in sicurezza i dati custoditi all’interno del VPS.

Facciamo il Backup…

Vediamo una possibile implementazione di backup aggiuntivo per una casistica molto comune (gestionali web, siti web, repository di dati, ecc.) di VPS. Il caso preso in esame prevede:

  • VPS basato su sistema operativo GNU/Linux con installato rsync;
  • dati localizzati sul file system e/o alcuni dati all’interno di un database relazionale come MySql, Postgresql;
  • accesso dall’esterno attraverso protocollo SSH con autenticazione a chiave pubblica/privata.

La soluzione proposta è basata sulla realizzazione di un VPS secondario localizzato obbligatoriamente fuori dal datacenter dove è localizzato il VPS principale. Il VPS di backup può essere realizzato con sistema operativo GNU/Linux Debian, con ridotte risorse operative come CPU e RAM (i.e.: 1CPU e 256/512MB di RAM), per quanto riguarda la quantità di spazio disco è dipendente dalla quantità di dati da custodire. Il VPS di backup può essere localizzato anche nella propria sede operativa o presso altro provider differente da quello principale.

Gli strumenti software da impiegare per ottenere il risultato desiderato sono (si potranno poi impiegare altri strumenti come checkmk per poter eseguire un’attività di monitoraggio del VPS di backup):

Obiettivo da raggiungere

Ottenere un repository dove siano localizzati dati strutturati in momenti temporali (RPO) ben precisi, che consentano di ricostruire un fotografia dei dati localizzati all’interno del VPS principale, per eseguire operazioni di ripristino mirato in caso di cancellazioni indesiderate o ripristino dell’ambiente per attività di disaster recovery. Questo meccanismo di backup è da intendersi come ultima risorsa da impiegare, quando le altre soluzioni messe in campo non possono essere utilizzate!

in pratica…

Il cuore di questo meccanismo di backup è rsnapshot, che opportunamente configurato consente di eseguire una copia programmata in istanti di tempo precisi.

  • In GNU/Linux Debian installiamo con il seguente comando:
apt install rsnapshot
  • modificare il file /etc/rsnapshot.conf ([[TAB]] carattere tabulazione, [[SPAZIO]] carattere spazio):
...
verbose 4
...
rsync_long_args[[TAB]]--stats[[SPAZIO]]--delete[[SPAZIO]]--numeric-ids[[SPAZIO]]--relative[[SPAZIO]--delete-excluded
...
retain[[TAB]]hourly[[TAB]]6
retain[[TAB]]daily[[TAB]]7
retain[[TAB]]weekly[[TAB]]4
...
backup[[TAB]]root@vps:/etc/[[TAB]]vps/[[TAB]]exclude=mtab,exclude=core
backup[[TAB]]root@vps:/root/[[TAB]]vps/
backup[[TAB]]root@vps:/data/[[TAB]]vps/
backup[[TAB]]root@vps:/backup/databases/[[TAB]]vps/
...

Questa modifica consente di:

– elevare il livello di descrizione delle attività di backup (verbose 4);

– definire dei livelli (retain) di backup nominali che conservino un determinato numero di backup precedenti. Si noti che, quando si configurano questi livelli, il primo nell’elenco sarà l’unico che esegue effettivamente il backup dei file dal file system, ruotando il numero del backup. Quindi, l’ordine in cui sono elencati nel file di configurazione è molto importante. I livelli sono legati tra loro perché condividono i file non modificati nel tempo mediante il meccanismo del link hardware, implementabili sul file system linux come ext2/3/4, xfs, zfs, reiserfs ed altri. Questo aspetto è molto importante, poiché consente di avere backup di rilevanti dimensioni con un’ottimizzazione dello spazio consumato. Con questa tecnica è possibile avere istantanee del contenuto delle porzioni di file system, senza dover obbligatoriamente archiviare duplicati del medesimo file con inutile spreco di spazio. Questa tecnica inoltre consente di verificare velocemente le differenze intercorse tra varie versioni del medesimo file nell’arco di ore, giorni o settimane. I livelli definiti sono: hourly, che verranno impiegati per conservare i backup infra giornaliero (sei in questo caso); daily per conservare i backup giornalieri (sette in questo caso); weekly per conservare i backup settimanali (4 in questo caso).

– indicare le sorgenti di backup che rappresentano le porzioni di file system da prendere in considerazione. Nel caso in esame le cartelle /etc, /root, /data e /backup/databases che contengono i dati che vengono ritenuti vitali. Se i file presenti in queste porzioni di file system risultano sufficienti, sarà possibile utilizzarli per ripristinare l’ambiente operativo con il backup ultimo o precedente.

  • copiamo un file di utilità per la reportistica
cp /usr/share/doc/rsnapshot/examples/utils/rsnapreport.pl /usr/local/bin/
chmod +x /usr/local/bin/rsnapreport.pl
  • modifichiamo quindi il file /etc/cron.d/rsnapshot con il seguente contenuto
0 */4 * * * root /usr/bin/rsnapshot hourly | /usr/local/bin/rsnapreport.pl | mail -s "Report rsnapshot del server VPS XXX" vpsbackup@maurosalvia.it
30 3 * * * root /usr/bin/rsnapshot daily
0  3 * * 1 root /usr/bin/rsnapshot weekly

Quest’ultimo file indica la schedulazione dell’attività di backup. Il livello hourly verrà eseguito ogni 4 ore (00:00, 04:00, 08:00, 12:00, 16:00, 20:00), il livello daily verrà eseguito una volta al giorno alle 3:30, il livello weekly verrà eseguito ogni lunedì alle alle 3:00. Un esempio di listato delle cartelle che si otterrà, estratto tra le 16:00 e le 20:00 di un 9 aprile, sarà similare al seguente:

apr  8 04:00 daily.0
apr  7 04:00 daily.1
apr  6 04:00 daily.2
apr  5 04:00 daily.3
apr  4 04:00 daily.4
apr  3 04:00 daily.5
apr  2 04:00 daily.6
apr  9 16:00 hourly.0
apr  9 12:00 hourly.1
apr  9 08:00 hourly.2
apr  9 04:00 hourly.3
apr  9 00:00 hourly.4
apr  8 20:00 hourly.5
mar 28 04:00 weekly.0
mar 21 04:00 weekly.1
mar 14 04:00 weekly.2
mar  7 04:00 weekly.3

All’esecuzione del backup di livello hourly viene generata una reportistica che verrà inviata via email al destinatario indicato nel comando.
Segue l’occupazione complessiva delle cartelle di backup:

7,8G	daily.0
230M	daily.1
257M	daily.2
251M	daily.3
189M	daily.4
299M	daily.5
240M	daily.6
420M	hourly.0
48M	hourly.1
37M	hourly.2
30M	hourly.3
27M	hourly.4
29M	hourly.5
571M	weekly.0
656M	weekly.1
826M	weekly.2
575M	weekly.3

Nel caso riportato, l’ultimo backup realmente pesa 7,9GB (hourly.0), quindi se volessimo ipotizzare un backup primitivo/brutale dei dati originali, saremmo costretti ad eseguire un trasferimento ogni volta, di circa 7,8G con relativi problemi di consumo di banda ed occupazione dello spazio.
La potenza di rsnapshot, che impiega le funzionalità di rsync e il meccanismo del link hardware, si manifesta:
– in un risparmio di spazio, passando da un teorico consumo di 132,6 GB a circa 12GB reali;
– in un risparmio di banda, visto che nell’ultimo trasferimento (hourly.0) vengono copiati 420MB contro i 7,9GB di dati complessivi.
rsnapshot, si è dimostrato un ottimo strumento da impiegare per backup di porzioni di file system.
Abbinato ad una corretta configurazione dell’ambiente di esecuzione consente di avere una corretta implementazione dello strumento di backup.

Questo sito raccoglie dati statistici anonimi sulla navigazione attraverso i cookie, nel rispetto della tua privacy. Informativa Cookie Policy