La Knowledge Base di Kurgan (2.0)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== Rsync per fare backup remoti o locali, storicizzando le modifiche ====

==== QUESTA PAGINA CONTIENE DATI PROVVISORI, STO ANCORA PROVANDO ====

Frugando in internet ho trovato questa pagina http://www.mikerubel.org/computers/rsync_snapshots/, che parla dell' uso di Rsync per fare backup storicizzati. L'idea di fondo e` che ad intervalli di tempo predefiniti (o quando si vuole) si puo` fare un backup usando rsync e gli hard link, facendo in modo di avere, sul disco di destinazione, una serie di "snapshot" del disco di origine, ognuna delle quali contiene i dati cosi` come erano alla data X. Il vantaggio di usare i link per gestire le varie copie storiche e` che lo spazio sul disco dei backup non e` occupato realmente da tutte le copie presenti, ma solo dalle directory (che non possono essere linkate) e dai files modificati fra uno snapshot e l'altro. 

Per ottenere questo risultato ci sono due metodi: il primo consiste nel creare  una "finta copia" linkata usando il comando "cp -al" prima di fare il nuovo rsync; il secondo consiste nell'usare il sistema compreso dentro rsync stesso, mediante il comando "--link-dest". Io sto sperimentando il secondo metodo, perche` lo sto usando fra una macchina Linux (della quale voglio fare il backup) e un Lacie Ethernet Disk Mini (sul quale salvo il backup) opportunamente hackerato che contiene rsync ma non e` in grado di eseguire "cp -al".

Sulla macchina che contiene i backup (il Lacie Ethernet Disk Mini)  ho configurato Rsync per girare come demone, per giunta come utente root. So benissimo che non e` un setup sicuro, pero` e` quello che mi consente di fare funzionare tutto nonostante le limitazioni del sistema che gira nel Lacie. Usato in rete locale, magari in una rete apposita, disconnessa da quella dove si trovano i client, e chiuso in sala macchine, mi sembra accettabilmente sicuro.  Non e` veramente a prova di hacker, ma qui il mio scopo e` di essere a prova di disastro (o di utente che cancella un file per errore) e non di hacker. Per essere a prova di tutto ci sono le cassette tenute offline e offsite.

Fare girare rsync come root e` necessario per consentirgli di settare oid, gid e permission per i file che copio. Se lo faccio girare come utente normale, non posso settarli, quindi nella copia le permission e l' owner dei files sono totalmente sballati. Tra l'altro facendo cosi` rsync non "gradisce" le vecchie copie, e tutte le volte ricopia tutto da capo. Come root funziona.

La configurazione di Rsync (/etc/rsyncd.conf) sul Lacie e` questa:

<code>
uid=root
gid=root
use chroot = no
max connections = 4
pid file = /var/run/rsyncd.pid

[backup-mater]
        read only = false
        path = /home/backup-mater
        # use your subnet here, not mine
        hosts allow = 10.1.42.0/24
        # hosts deny = 0.0.0.0/0
</code>


Sulla macchina da backuppare (mater), eseguo questo script una volta al giorno:

<code>
#!/bin/bash

# backup con Rsync su una macchina linux remota.

# se il backup attraversa mezzanotte, la data cambia. Questo non e` bene.
# Quindi, mi segno la data di adesso, e la usero` per tutto lo script quando mi serve.
data=`date +%F`

# rsync di /ud0, usando gli hard link per la storicizzazione.
rsync --delete -a -v --link-dest=/ud0_`cat rsync_ud0_latest` /ud0/ edmini::backup-mater/ud0_$data > rsync_log_$data

# alla fine dell'rsync, segno la data dell'ultimo run.
echo $data > rsync_ud0_latest
</code>

Prima del primo run, occorre fare un 
<code>
touch rsync_ud0_latest
</code>

Il principio di funzionamento e`:

  * Mi segno la data di inizio della copia
  * Faccio rsync dalla directory locale "/ud0" alla remota /ud0_<data_di_oggi>, facendo riferimento alla vecchia copia remota(quella di ieri) per gestire i files uguali. Rsync in questo caso confronta i files di origine con quelli che trova nella copia di ieri: se sono uguali, crea un hard link fra la vecchia directory e la nuova. Se sono diversi, copia il file origine sulla directory dove sta facendo il backup.
  * Alla fine, scrivo in un file la data di inizio della copia. Alla prossima esecuzione, la data salvata qui mi servira` per sapere come si chiama la "vecchia copia" da usare come "link-dest".

Questo script e` una porcata, ma fatto cosi` mi consente di non avere alcuna "logica" a bordo del Lacie a parte il server rsync.

Il risultato dell'esecuzione di questo script e` che dentro al Lacie trovo tante directory, oguna delle quali con il nome "ud0_<data_del_backup>". Dentro ognuna di quelle directory, accessibili a mezzo di Samba, c'e` quella che sembra una copia completa del disco di origine a quella data. 

==== Limiti del sistema a cui fare attenzione: ====

Pare che se si modificano solo gli attributi dei files (gid, uid, permessi) e non il contenuto, queste modifiche non vengano "storicizzate" correttamente.

Questo sistema non prevede un meccanismo di eliminazione delle vecchie copie, quindi il disco del Lacie (il disco di destinazione del backup) tende a riempirsi all'infinito. Occorre uno scriptino che cancelli le copie piu` vecchie di X giorni, che giri sul Lacie.

Una porcata messa assieme in 10 minuti e` questa (da mettere in crontab, non credo che funzioni sul lacie, pero` funziona su una macchina linux)
<code>
00 17   * * *   root    find /percorso/files/ -maxdepth 1 -ctime +90 -type d -exec rm -r {} \;
</code>
Meglio fare le prove con un "ls -lad" al posto di "rm -r".

Questi non sono veri "snapshot", ovvero la copia puo`, se si lavora sul disco di origine mentre si esegue il backup, risultare "desincronizzata".  Cioe`, siccome rsync puo` impiegare ore a girare, puo` essere che le modifiche apportate ai dati originali vengano in parte copiate nel backup e in parte no. Questo e` sempre vero per qualsiasi backup che non gestisca un "freeze" del sistema (tipo ZFS o tipo il dump dei database SQL), e` importante pero` ricordarlo per chiarezza.

Ovviamente nel disco di destinazione non ci sono tante copie di ogni file, ma solo una per ogni volta che questo file e` stato modificato, quindi un danno ad un settore puo` farti perdere tutte le copie dello stesso file (che in realta` e` una sola con tanti link). Questo sistema