[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sistema di backup, hash e par2?



Se, come dici, ti accorgi entro un lasso di tempo non troppo lungo di avere dei file corrotti, per avere la sicurezza di ripristinarli è sufficiente tenere un certo numero di versioni dei modificati.

Credo che con rsync e un minimo di #!bin/bash si possa ottenere il risultato desiderato.

Ecco una traccia:

rsync -avb --delete --backup-dir=$data_dir/$data_sync e --log-file=$log_dir/$log_job $source/ $target


devi solo impostare le variabili

$history/$data_sync per archiviare in cartelle separate i soli files modificati nella versione antecedente la modifica (in data_sync metto data e ora nella forma AAAAMMGGHHMMSS)

$log_dir/$log_job per archiviare i rapporti

$source e $target per sorgente e destinazione delle copie

Resta il problema di cancellare le cartelle "data_sync" più vecchie, quando si resta a corto di spazio su disco: se qualcuno si vuol cimentare e rendere la lista edotta del proprio sforzo .....

Il 15/06/2014 09:25, Davide G. ha scritto:

Un caldo saluto a tutta la lista (dato il clima).

Volevo chiedere se eravate a conoscenza di valide soluzioni per il seguente
problema:

Un insieme di tanti piccoli file abbastanza contenuto (< 500 GB) del quale fare
un backup locale regolare + uno manuale offline su disco usb. Devo controllare
l'integrità dei file che vengono backuppati per evitare che un eventuale file
corrotto prenda il posto di uno "buono" sul backup.

Si parlerà al 99% di probabilità di un sistema debian stabile md+lvm+ext4 (per
mia scelta, nessun vincolo).


Non ho trovato soluzioni "pronte" al mio scopo e avevo ipotizzato una cosa di
questo tipo:

- Backup locale con rsnapshot
- Un file contenente gli hash dei file al loro ultimo backup, questi hash
vengono controllati per i file che hanno un ctime uguale all'ultima versione
salvata, gli altri vengono "aggiornati"
- Il backup offline lo prendo dall'ultimo di rsnapshot con tar o dar previo
controllo hash e salvo offline anche un file di par2.

In caso di errori si interviene manualmente a controllare (l'idea è che non
dovrebbe accadere).
Il problema dei file "in uso" lo potrei risolvere facendo prima il giro di
rsnapshot e confrontando l'hash tra i 2 ultimi backup.

Sulla carta sembra semplice, in realtà ho riscontrato il problema che rsnapshot
non permette una "dry run" dove elenca solo i file che verrebbero aggiornati
(in modo da "grepparli" dal file contenente gli hash e controllare gli altri).


Avete idee un po' meno contorte?


Luciano


Reply to: