Rsyncbackup per avere backup schedulati su debian etch

Oggi vedremo come effettuare backup schedulati, incrementali o statici, con rsyncbackup, un comodo script in perl che in collaborazione con l’utile comando rsync ci permetterà di effettuare il mirroring dei dati…

Perchè innanzitutto effettuare il backup?

Beh chi lavora in ambientazione server saprà sicuramente il perchè bisogna farlo, i crash dovuti a dischi che se ne vanno sono quasi all’ordine del giorno, se ci si trova a dover gestire un parco macchine di modeste dimensioni.

I backup ci salvano la vita, è sempre meglio schedularli settimanalmente o mensilmente in base alle nostre necessità, perchè quando avremo dei problemi ci basterà effettuare un ripristino e nel peggiore dei casi la perdita di dati sarà esigua.

Ci sono svariati tool su linux che permettono di farlo, anche se secondo molti “dd” è il migliore per effettuare backups a livello più basso;¹ noi oggi però vedremo come effettuare un mirroring dei dati tra un server di produzione e un server di backup.

Per l’esempio di oggi poniamo che il server di produzione abbia indirizzo ip uguale a 10.0.0.1 mentre il server di backup 10.0.0.2

Installazione del software:

Procediamo con l’installazione dei pacchetti necessari sul server di produzione:


apt-get install openssh-client openssh-server rsync unzip

e quindi sul server di backup:

apt-get install openssh-client openssh-server rsync

Chiavi SSH

con rsync faremo uso di ssh per il trasferimento dei files di backup tra i server, sarà quindi necessario creare le apposite chiavi per l’autenticazione:

Sul server di backup:
ssh-keygen -b 4096 -t rsa -C "Chiave RSA per il server di Backup"

Durante la creazione della chiave dovremmo avere queste domande:

Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory ‘/root/.ssh’.
Enter passphrase (lasciamo il campo vuoto per non impostare una password):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
23:e5:b2:2e:86:2f:e9:bc:76:56:83:6a:8d:f0:d6:23 Chiave RSA per il server di Backup

Adesso dobbiamo aggiungere questa chiave pubblica alla lista delle chiavi autorizzate:
cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

Adesso dobbiamo copiare questa chiave sul server di produzione:

scp /root/.ssh/id_rsa root@10.0.0.1:/root/.ssh/

adesso concludiamo il lavoro sul server di backup creando le cartelle necessarie ad ospitare i dati:

mkdir -p /backups/configs/
mkdir /backups/logs/ /backups/manual/

Operazioni sul server di produzione:

Adesso testiamo la connessione, se tutto è andato bene dovremmo poter loggarci sul server di backup senza problemi:
ssh -i /root/.ssh/id_rsa root@10.0.0.2

se tutto va bene possiamo sloggarci e cominciare a scaricare rsyncbackup sul server di produzione:

cd /usr/src
wget http://rsync-backup.googlecode.com/files/rsyncbackup.zip
unzip -d rsyncbackup rsyncbackup.zip

Una volta scaricato lo script dobbiamo copiare alcuni file in determinate cartelle:

cp /usr/src/rsyncbackup/rsyncbackup/rsyncbackup /usr/local/bin/
chmod 700 /usr/local/bin/rsyncbackup

e quindi creare i files di configurazione:

mkdir /etc/rsyncbackup/
mkdir /var/log/rsyncbackup/
touch /etc/rsyncbackup/config.conf /etc/rsyncbackup/destinations.conf \
/etc/rsyncbackup/sources.conf /etc/rsyncbackup/backupset.conf
ln -s /var/log/rsyncbackup/ /etc/rsyncbackup/logs

La configurazione:

Andiamo a modificare il file /etc/rsyncbackup/config.conf che contiene le opzioni generali per tutti i backups, in modo che il suo contenuto sia simile a questo:²

–stats
–progress
–links
–hard-links
–times
–recursive
–perms
–owner
–group
–compress
–backup

Adesso inseriamo in /etc/rsyncbackup/sources.conf le “sorgenti” ossia le cartelle che dovrebbero essere soggette a backup:³

configs|local:/etc|true|
logs|local:/var/log|true|

Ed ora nel file /etc/rsyncbackup/destinations.conf inseriamo le destinazioni, cioè dove i backup dovranno essere memorizzati:

store_configs|ssh[key=id_rsa,incremental=7,tag=increment]:root@10.0.0.2:/backups/configs/|/usr/bin/traceroute -m 2 10.0.0.2|–bwlimit=300 –delete
store_logs|ssh[key=id_rsa,incremental=7,tag=increment]root@10.0.0.2:/backups/logs/|/usr/bin/traceroute -m 2 10.0.0.2|–bwlimit=300 –delete
store_manual|ssh[key=id_rsa]:root@10.0.0.2:/backups/manual/|/usr/bin/traceroute -m 2 10.0.0.2|

Con questo set di istruzioni, ad esempio la prima riga, noi indichiamo al server di produzione di autenticarsi al server di backup con la chiave ssh privata, terremo 7 bakcup incrementali che avranno nel nome la tag “increment” per indicare a quale stato di incrementazione siamo arrivati, inoltre abbiamo aggiunto un comando shell che indica di effettuare un traceroute verso il server di backup, se il server è attivo (quindi raggiungibile) ed è almeno a 2 hop dopo il server di produzione, il backup partirà, abbiamo settato anche un limite di banda per il trasferimento, ed infine aggiunto l’opzione delete, che indica che i file che vengono eliminati sul server di produzione, col prossimo incremento di backup, dovranno essere eliminati anche sul server di backup.

Per finire dobbiamo modificare il file /etc/rsyncbackup/backupset.conf in modo che il suo interno sia simile a questo:

[manual]
configs,logs|store_manual|true|

[daily]
logs|store_logs|true|

[weekly]
configs|store_configs|true|

Adesso che tutti i file di configurazione sono stati creati possiamo procedere al test di funzionamento:
Digitando
rsyncbackup -x /etc/rsyncbackup -vv -d -s manual

Dovremo ottenere un output di questo genere

PATH DIR:/etc/rsyncbackup/
LOG DIR:/etc/rsyncbackup/logs
CONFIG_FILE:/etc/rsyncbackup/config.conf
SOURCE FILE:/etc/rsyncbackup/sources.conf
DESTS_FILE:/etc/rsyncbackup/destinations.conf
BACKUPSET_FILE:/etc/rsyncbackup/backupset.conf
BACKUPSET:manual

Backup set 1 configs to store_manual
Source : configs
Source dir : [local] /etc
Source opts :
Source cond : true
Destination : store_manual
Destination dir : [ssh] root@10.0.0.2:/backups/manual/ [key=id_rsa,sshport=22]
Destination opts:
Destination cond: /usr/bin/traceroute -m 2 192.168.0.102
Config options : –stats –progress –links –hard-links –times –recursive –perms –owner –group –compress –backup
Backupset opts : true
All options : –stats –progress –links –hard-links –times –recursive –perms –owner –group –compress –backup
All conditions : /usr/bin/traceroute -m 2 10.0.0.2 true true

Backup set 2 logs to store_manual
Source : logs
Source dir : [local] /var/log
Source opts :
Source cond : true
Destination : store_manual
Destination dir : [ssh] root@10.0.0.2:/backups/manual/ [key=id_rsa,sshport=22]
Destination opts:
Destination cond: /usr/bin/traceroute -m 2 10.0.0.2
Config options : –stats –progress –links –hard-links –times –recursive –perms –owner –group –compress –backup
Backupset opts : true
All options : –stats –progress –links –hard-links –times –recursive –perms –owner –group –compress –backup
All conditions : /usr/bin/traceroute -m 2 10.0.0.2 true true

E’ andato tutto liscio? ok allora siamo arrivati al momento magico, diamo il via al nostro primo backup:
rsyncbackup -x /etc/rsyncbackup -b -s manual

Ok scheduliamolo nel nostro crontab:
crontab -e

inserendo:

# m h dom mon dow command
# Backups
00 02 * * * /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s daily >> /var/log/rsyncbackup/backup.daily.log
00 04 * * 0 /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s weekly >> /var/log/rsyncbackup/backup.weekly.log

Vi ricordate che nel file backupset.conf abbiamo settato tre direttive, manual, daily e weekly? Servivano proprio a questo, con la prima stringa richiameremo il backup set daily ogni giorno alle 2 di notte, mentre il weekly ogni domenica alle ore 04:00 (con la seconda stringa).

Non vi basta? non vi fidate? aggiungete allora il comando -e casella@dominio.it al comando rsyncbackup (prima degli >> per intenderci), e se ci saranno errori avrete una mail che parte in automatico che ve lo notifica.

1. con dd infatti avremo una copia esatta dei dati, con settori, numero di cilindri ecc, con rsync invece avremo un mirroring a livello più alto, dei file cioè, potremo infatti avere al massimo una copia dei file con i relativi permessi [↩]
2. notare che queste non sono altro che le opzioni da passare a rsync, potete anche utilizzare la sintassi compressa, tipo -p per –perms [↩]
3. Sintassi: tag|local:path|condizione, come vediamo per i log abbiamo scelto la tag “logs” con path “/var/log” e con condizione “true”, cioè abilitato al backup, viceversa avremmo usato “false” [↩]