rsync

Backup incrementale automatico con Rsync

rsyncOK, visti i miei precedenti sono costretto ad ammetterlo: sono un maniaco dei backup 😉

Sempre secondo la logica già indicata in precedenti post, i backup validi devono essere il più possibile indipendenti dalla volontà dell'utente.

Vediamo come effettuare un backup incrementale automatico e frequente (più volte al giorno) con RSYNC.

La destinazione del backup può essere un hard disk esterno, un NAS o un apposito server di backup Linux o Windows.

Nell'esempio seguente spiegherò come farlo da un client Linux verso un backup server sempre Linux, ovvero un'ottima soluzione all'interno di una LAN.

Per farlo è sufficiente un comando simile al seguente:

rsync -avz --delete --stats -e ssh --exclude='*.tmp' --exclude='Thumbs.db' --exclude='*~*' /home/utente-client/Documenti <utente-server>@<IP_Server_Backup>:/Backup/<utente-client>/ > ZLog_Bck_Documenti.log

In questo esempio viene sincronizzato in modo unidirezionale (quindi sempre dalla sorgente verso la destinazione) tutto il contenuto della sorgente (/home/<utente-client>/Documenti) verso la destinazione (/Backup/utente-client sul backup server).

Il significato delle varie opzioni è il seguente:

-a: ricorsività nelle directory

-v: verbose (emette l'output per ogni singola operazione che esegue)

-z: comprime prima di trasferire

--delete: fa in modo che vengano eliminati sulla destinazione i files che non esistono sulla sorgente

-e ssh usa ssh per la comunicazione

--exclude=PATTERN esclude i files simili al PATTERN indicato (ad esempio –exclude='*.tmp' esclude dalla sincronizzazione tutti i file con estensione “.tmp”)

/home/<utente-client>/Documenti directory sorgente

<utente-server>@<IP_Server_Backup>:/Backup/<utente-client>/ - server e directory destinazione

--stats da in output statistiche simili alle seguenti:

Number of files: 494
Number of files transferred: 22
Total file size: 573141407 bytes
Total transferred file size: 53623750 bytes
Literal data: 774074 bytes
Matched data: 52849676 bytes
File list size: 11883
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 246933
Total bytes received: 86384
sent 246933 bytes  received 86384 bytes  60603.09 bytes/sec
total size is 573141407  speedup is 1719.51

> LogDocumenti.log scrive l'output del comando nel file LogDocumenti.log

Ovviamente l'esecuzione di questa istruzione richiede la password dell'utente del server e quindi non sarebbe automatizzabile.

Per renderlo indipendente dalla password bisogna creare una chiave SSH dell'utente locale (del client) e quindi copiare la chiave pubblica sul server.

Quindi creiamo una chiave ssh col comando:

ssh-keygen

premere “INVIO” alle domande poste senza imputare nessuna informazione:

  • Enter file in which to save the key (/home/<utente>/.ssh/id_rsa):
  • Enter passphrase (empty for no passphrase):
  • Enter same passphrase again:

quindi copiare la chiave sul server:

ssh-copy-id -i /home/<utente>/.ssh/id_rsa.pub <utente-server>@<IP_Server_Backup>

A questo punto, eseguendo nuovamente il comando rsync come indicato sopra, non chiede più niente.

Quindi è possibile automatizzare l'esecuzione del backup inserendolo in cron con il comando:

crontab -e

aggiungere una riga simile alla seguente:

*/15 * * * *    rsync -avz --delete --stats -e ssh --exclude='*.tmp' --exclude='Thumbs.db' --exclude='*~*' /home/<utente-client>/Documenti <utente-server>@<IP_Server_Backup>:/Backup/<utente-client>/ > ZLog_Bck_Documenti.log

In questo caso la sincronizzazione verrà eseguita automaticamente ogni 15 minuti. Per cambiare l'intervallo di tempo è sufficiente agire sui parametri di crontab.

Se di volesse fare la stessa cosa ma indirizzando il backup su un server Windows (o un NAS)con condivisioni samba si può fare uno script come il seguente:

#!/bin/sh
mount -t smbfs -o username=<utente-windows>,password=<password-utente-windows> //IP_Server_Windows_(o_NAS)/<percorso-sul-server> /<percorso-locale-dove-montare-la condivisione>
rsync -avz --delete -e shh --exclude='*.tmp' --exclude='Thumbs.db' --exclude='*~*' /<percorso-locale-da-salvare> /<percorso-locale-dove-montare-la condivisione>
umount /<percorso-locale-dove-montare-la condivisione>

In pratica, lo script, non fa altro che:

  • montare la condivisione windows-samba
  • eseguire la sincronizzazione con rsync della directory che gli interessa verso la condivisione
  • smontare la condivisione

Se ipotizzassimo che:

  • IP Server Windows (o del NAS): 192.168.1.250
  • utente-windows: ginetto
  • password-utente-windows: ranocchio
  • percorso-sul-server: /utenti/ginetto
  • percorso-locale-dove-montare-la condivisione: /mnt/WinServer
  • percorso-locale-da-salvare: /home/ginetto/Documenti

lo script finale sarebbe così:

#!/bin/sh
mount -t smbfs -o username=ginetto,password=ranocchio //192.168.1.250/utenti/ginetto /mnt/WinServer
rsync -avz --delete -e shh --exclude='*.tmp' --exclude='Thumbs.db' --exclude='*~*' /home/ginetto/Documenti /mnt/WinServer
umount /mnt/WinServer

Ovviamente è necessario creare la directory in cui verrà montata la condivisione Windows utilizzando il comando mkdir:

sudo mkdir /mnt/WinServer

ATTENZIONE: questo script va eseguito solo come root in quanto l'utente normale non può montare una condivisione di rete. Quindi se si desidera schedularlo utilizzare il “cron” di root.

Per sincronizzare con un hard disk esterno come destinazione, è ancora più semplice. E' sufficiente sostituire la parte relativa alla destinazione con il percorso della directory dell'hard disk esterno. Esempio:

rsync -avz --delete --stats -e ssh --exclude='*.tmp' --exclude='Thumbs.db' --exclude='*~*' /home/utente-client/Documenti /media/<nome-utente>/<nome-volume>/Backup/ > ZLog_Bck_Documenti.log 2>/dev/null

Al posto di <nome-volume> va indicato il nome con cui viene montato l'hard disk e al posto di <nome-utente> va indicato il nome utente con cui si sta lavorando.

Inoltre, in questo caso, io aggiungo alla fine anche la seguente opzione:
2>/dev/null
mi permette di non scrivere da nessuna parte eventuali errori in output. Non è necessaria ma la consiglio se schedulate il comando in crontab con quest'ultimo impostato per inviare eventuali segnalazioni alla vostra e-mail. In questo caso è sufficiente che l'hard disk esterno sia spento o scollegato per fare in modo che il sistema continui ad inviarvi e-mail di errore.

 

Per sincronizzare ignorando le differenze di orario (datetime) si può utilizzare l'opzione --ignore-times:

rsync -avz --delete --stats --ignore-times /home/utente-client/Documenti /media/hdbackup/Backup/

in questo modo rsync valuterà solo la dimensione (size) dei file. Questo è abbastanza pericoloso perchè è possibile avere file della stessa dimensione ma con orario di modifica diverso.

Un metodo più sicuro è usare l'opzione --checksum (o -c). Con l'opzione --checksum vengono ignorate le differenze di orario e il file viene trasferito solo se varia per dimensione (size) o per il checksum che è un algoritmo che calcola l'hash MD5 (o l'MD4 per le versioni di rsync inferiori alla 3.0.0+). Esempio:

rsync -avz --stats --checksum /home/utente-client/Documenti /media/hdbackup/Backup/

questo metodo è molto sicuro ma anche molto lento, però può essere necessario quando sincronizzo file tra due filesystem diversi (ext4 e NTFS) che possono in alcuni case gestire il datetime in modo diverso.

Un altro parametro molto utile quando si utilizza rsync col vecchio file system FAT di windows è --modify-windows=1: questo parametro permette di ignorare differenze di timestamp di 1 secondo che possono verificarsi a causa del diverso modo di gestire il timestamp. Esempio:

rsync -avz --stats --modify-windows=1 /home/utente-client/Documenti /media/hdbackup/Backup/

Se la sincronizzazione deve anche cancellare le directory piene che sono state eliminate sulla sorgente, bisogna utilizzare l'opzione --delete-excluded, esempio:

rsync -avz --stats --delete-excluded --delete /home/utente-client/Documenti /media/hdbackup/Backup/

se non viene specificata questa opzione rsync, nel caso trovasse sulla destinazione una directory piena che non esiste più sulla sorgente, non la cancellerà e darà il seguente messaggio:

cannot delete non-empty directory: paolo/mia-directory

ATTENZIONE: per un backup schedulato verso un hard disk esterno conviene assicurarvi che l'hard disk venga montato sempre con lo stesso nome come descritto nel post assegnare un nome fisso a memoria usb.

ATTENZIONE 2: rsync da anche la possibilità di simulare l'azione per vedere come si comporterebbe. E' sufficiente aggiungere l'opzione –dry-run. In questo caso viene mostrato cosa farebbe senza fare nessuna modifica. E' un ottimo modo per capire se l'istruzione scritta risponde alle vostre esigenze.

(Letto 8.995 volte di cui 1 negli ultimi 30gg)
twitterlinkedinmailby feather

5 thoughts on “Backup incrementale automatico con Rsync

  1. Ciao,
    Grazie per la guida, ma non riesco a non farmi chiedere la password

    per prima cosa ho creato la chiave ssh su mac (client) con questo comando
    ssh-keygen -t dsa
    ho impostato la mia password
    dopodiché ho copiato la mia chiave ssh sul server Ubuntu con questo comando
    ssh-copy-id -i /Users/nomeUtente/.ssh/NomeMiaChiave.pub nomeUtente@ipServer (info per i mac user ssh.copy-id non è disponibile di default)

    per essere sicuro apro sul client con nano nomeMiaChiave.pub e lo confronto con quella del server che si trova in
    /home/nomeUtente/.ssh/authorized_keys

    vedo che sono molto simili ma non sono uguali (questo può essere il problema? )

    a Questo punto provo a loggarmi(da server) tramite ssh al client, e mi aspetto che non mi chieda la password…ma invece continua a chiedermela…
    provo anche rsync ma mi chiede ugualmente la password…dove sbaglio?

    1. “…a Questo punto provo a loggarmi(da server) tramite ssh al client, e mi aspetto che non mi chieda la password…ma invece continua a chiedermela…”

      grazie per i complimenti.

      le istruzioni dell’articolo ed anche le operazioni che hai compiuto tu non sono per collegarsi dal server al client ma viceversa dal client al server senza che il server ti chieda la password. Infatti tu hai copiato sul server la chiave pubblica del client quindi quando quest’ultimo si collega al server non dovrebbe chiedere la password perchè lo riconosce tramite la chiave. Se volevi fare il contrario dovevi creare la chiave sul server e copiarla sul client.
      Riguardo al fatto che un mac non so dirti se questo cambia qualcosa perchè non ho mai provato con un mac però derivando entrambi da nonno unix non dovrebbero esserci problemi 😉

      ciao

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *