Newsgroup: it.comp.os.linux.iniziare
Titolo: Backup e ripristino LVM

Ciao,
Ultimamente ho sperimentato un po' con LVM (fondamentalmente per creare un 
file system per i backup abbastanza grande riciclando un paio di hard disk), 
e sono rimasto molto piacevolmente impressionato da quel che ci si può fare!
Capite le basi, è veramente comodo!
A beneficio di tutti, ho messo qui qualche appunto in proposito:
http://gerlos.altervista.org/creazione-backup-ripristino-volumi-logici-lvm
Spero possano essere utili a qualcun altro... Mi raccomando, se trovate 
errori segnalateli!!! :-)
ciao
gerlos
-- 
"Solo lo scienziato è vero poeta: ci dà la luna, ci promette le stelle,
 ci farà un nuovo universo se sarà il caso."
                 < 
http://gerlos.altervista.org
 >
 gerlos  +- - - >  gnu/linux registred user #311588

 errori segnalateli!!! :-)
Domanda:
Se uno dei dischi usati per LVM va a "signorine facili",
si riesce a salvare i dati o... tutti i dati vanno ^^ ?
Altrimenti, per archiviazione|BackUp sarebbe meglio un raid[¹]
[¹] Direi un raid 5. Non l'antizanzare.
-- 
#include <std.disclaimer.h>
Signature automatica inserita a mano.
In God we trust, all others we monitor.(NSA)
Punteggiatura: Nel caso mancasse nel messaggio, aggiungete!!

 [¹] Direi un raid 5. Non l'antizanzare.
ZZZZzzzzzzz..... ;-)


> si riesce a salvare i dati o... tutti i dati vanno ^^ ?
Dimenticavo di ricordare che non c'è sistema RAID che possa sostituire una 
solida politica di backup periodici... sembra ovvio ma è qualcosa spesso 
sottovalutato!
Tutte queste misure sono *ulteriori*, in aggiunta, ai backup, che vanno 
*sempre* fatti e *verificati*[1]. Ripeto: vanno fatti e verificati.
ciao
gerlos
[1] pare banale, ma mi è capitato di veder impallidire un amministratore di 
rete Win 2000 nello scoprire che non gli era possibile ripristinare dei 
backup creati con MSBackup, e perciò non poteva recuperare un sistema 
Windows 2000 che era andato in crash malamente... Ora, non conosco windows e 
non mi pronuncio sull'aspetto tecnico, fatto sta che è proprio brutto 
accorgersi che ci si è fidati ciecamente di qualcosa che non funziona (i 
backup dell'esempio).


 backup dell'esempio).
E infatti per i backup NON mi fido dei formati proprietari.

 E infatti per i backup NON mi fido dei formati proprietari.
Neanche io (e infatti evito il software proprietario come la peste). 
Ma vedendo la cieca fiducia con cui certe persone ci si affidano ti viene da 
pensare che li abbiano provati tante e tante volte, e perciò almeno 
l'esperienza li sostiene nella fiducia. E invece poi scopri che la fiducia 
si basa sulla fama del programma più che sull'esperienza, e che non hanno 
mai provato a verificare né a ripristinare un backup, che tengono 
praticamente come talismano, visto che non sanno se funziona o no, ma ci 
credono soltanto.
Io che di pasticci ne ho fatti davvero tanti, ormai mi fido solo di tar, 
gzip, bzip2, dar, par2, dump, cp -a ed rsync. Non saranno l'ultimo grido in 
termini di backup ma so che funzionano, ciascuno nel suo contesto specifico.
ciao
gerlos


 backup dell'esempio).
Di solito uso tar, neanche compresso, si sa mai!
Ultimamente mi sto autoconvincendo a provate rsync ma devo crearmi la 
struttura.[²]
[²] Per uso domestico!


 Di solito uso tar, neanche compresso, si sa mai!
come verifichi i dati in un tar?
il checksum sull'intero tar non mi  pare granch� utile, perch� � un
prendere o buttare sull'intero archivio, mentre magari c'� solo un
file corrotto. 
come dicevo in un altro thread ho trovato "tarsum",
uno script python per la verifica con checksum dei singoli file
all'interno di un tar (senza doverli estrarre), ma non l'ho ancora
testato

 testato
Io uso file compressi, anche per le ragioni dette prima, e uso parchive per 
generare un file di controllo in grado di verificare e riparare un danno di 
dimensioni pari alla ridondanza impostata al momento della creazione del 
file di controllo (ovunque sia il danno). 
Chiaramente, il prezzo è un maggior ingombro, per cui se scelgo di avere una 
ridondanza del 10% su un archivio di 1 GB, mi devo accollare di avere un 
file di controllo di 100 MB. Ma imho il gioco vale la candela.
In proposito, fresco fresco:
http://gerlos.altervista.org/verifica-integrit-dati-md5-sha1-par
ciao
gerlos


 file di controllo (ovunque sia il danno). 
interessante.
segnalo anche l'utility storeBackup, che archivia in file compressi
(uno per file originario, se ho ben capito)
http://www.linuxfocus.org/Italiano/January2004/article321.shtml
http://www.nongnu.org/storebackup/
e permette di verificare i file con le sum md5
http://www.nongnu.org/storebackup/node24.html
storeBackupCheckBackup.pl verifies the consistency of a backup by
using the md5 sums generated during the backup in .md5CheckSums and
compares these with just calculated ones.

Enrico C ha scritto:

Non lo conoscevo!!! Sembra interessante...
Ma allora perché non citare anche dar:
http://dar.linux.free.fr/
Che analogamente comprime i singoli file, e al momento del test, oltre al 
controllo basato sui gzip o bzip2, fa degli ulteriori controlli crc sugli 
originali?
