linux user group brescia

immagine del castello

Archivio della mailing list

backuppare (e comprimere) un device intero con tar

Luca Coianiz luca a coianiz.it
Ven 16 Nov 2007 17:25:59 UTC
On Thu, 15 Nov 2007, Andrea Gelmini wrote:
>Il 15/11/07, Luca Coianiz<luca a coianiz.it> ha scritto:
>>  Andando a comprimere /dev/md0 da 35GB (su 40GB allocati) mi aspetto
>> performances di compressione peggiori, anche se spero in un 10-20%.
>questo non puoi saperlo a priori.
 Vero...

>intendo, se il contenuto del disco fosse principalmente di testo
>(mail, documenti, ecc), ovviamente il fattore di compressione potrebbe
>anche essere maggiore, ma se la facessero da padrone file video o
>musicali gia' compressi (avi/divx, ogg, mp3), l'ulteriore compressione
>risulterebbe del tutto inutile.
>tieni inoltre presente che a rendere il tutto meno efficace interviene
>la frammentazione e la struttura del filesystem.
 Come sempre, ci hai preso: l'HD da 30GB non è stato sufficiente. :/

 Pensavo che bzip2 sarebbe riuscito a comprimere il tutto, "recuperando"
quei 5GB di differenza tra i 30GB (spazio disponibile) ed i 35GB (spazio
usato sul RAID) ma pare che i dati siano troppo "sparsi" (o magari, come
dicevi, già compressi) per riuscire a comprimere bene.

 Toglierò un pò di roba (i soliti pornazzi, LOL) dal RAID e riproverò:
magari scendendo sotto i 30GB posso usare dd senza nemmeno comprimere (che
tanto è quasi come comprimere una jpeg).

>>  Rimane un po' il dubbio, salvo provare, se rasando /dev/hdb1 e
>> ricostruendolo (mkfs...) un bzip2 -d < /backup/hdb1.bz2 > /dev/hdb1 farebbe
>> tornare tutto come prima: mi fido o faccio la prova? :-D
>puoi fare la prova, ma non c'è ragione che non funzioni. ovviamente la
>partizione sara' marcata come corrotta, a meno che tu non abbia fatto
>il dump a freddo.

 Per chiarire: il sistema sta funzionando e lo "fotografo", anche se è una
foto con esposizione luuuuuuunga, mentre va (anche perchè backuppare a
dischi smontati non sarebbe impossibile, ma di sicuro un pò incasinato).
 L'idea era di avere, in caso di scassamentos del RAID, una sua "immagine"
da poter ripristinare "al volo" in questa maniera (spero di non scrivere
troppe cavolate):

[oggi]
 0) "salvo" l'intero RAID (/dev/md0) come "file" su un disco (/backup/) che
di solito è umounted.
(0-alt) (v. sotto) salvo /dev/hda (primo disco) invece del solo RAID: tanto
è un mirror, con RADI5 non potrei farlo ma con RAID1 mi sa di sì)

[nel caso in cui...]
 1) sostituisco il/i dischi danneggiati con altri uguali e/o più grossi
(perdendomi lo spazio in più, ok, chissene: importa che il server riparta,
non che sia ottimizzato) ;-)

 2) formattazione dei due dischi, giusto per avere un /dev/hda (e hdb) su
cui scrivere, o forse nemmeno serve visto che ci "passo sopra" (col
bulldozer dd).

 3) parto con un CD di recovery, per montare l'HD di backup tenendo smontati
i 2 HD nuovi.

 4) dd if=/backup/dev_md0 of=/dev/md0
(4-alt) (v. sotto) dd if=/backup/dev_hda of=/dev/hda (e hdb))

 ecco... il punto 4 è quello che mi fa sorgere qualche dubbio (assieme al
p.to 0): il RAID1 è fatto di 2 HD da 40GB ma è _software_.
 Forse farei meglio a backuppare solo uno dei due HD "interi" (dd
if=/dev/hda of=/backup/dev_hda): a quel punto, una volta sostituiti i due HD
(facciamo il caso di sfiga totale in cui saltano entrambi), potrei
ripristinare l'immagine dell'intero HD, con MBR, partizioni e tutto quanto.

 Rimane il 2.do HD da "sistemare", /dev/hdb, però il sistema dovrebbe
partire lo stesso, con performances degradate (uno solo dei 2 HD del RAID in
linea): forse potrei addirittura sbackuppare su _entrambi_ i dischi (nuovi)
in contemporanea, mentre sono ancora smontati:

dd if=/backup/dev_hda of=/dev/hda &
dd if=/backup/dev_hda of=/dev/hdb

 l'immagine dovrebbe poter esser letta in parallelo e scritta sui due
dischi, no? Anche se su hdb ci finisce l'immagine di hda non dovrebbe esser
un problema, visto che hda viene fatto partire al boot (IDE primary master)
ed hdb no, e poi un RAID1 è un mirror.

 A questo punto?.. un fsck di /dev/hda (e /dev/hdb) dovrebbe marcare il
disco come "buono" (penso)... o, visto che è partizionato, devo fare fsck
delle 3 partizioni ricreate da dd (/dev/hda1..3)?

 Le cose, ora, stanno così:
/dev/hda1	/boot	30 MB
/dev/hda2	swap	256 MB
/dev/hda3	(RAID: non montato via fstab) 40 GB

 Alla fine della scrittura avrei comunque "mezzo RAID" bootabile (se dd
fatto su /dev/hda ne salva anche l'MBR) ed il sistema dovrebbe partire in
degraded mode. Partendo mi fa anche un raidcheck.

 Dovrebbe bastarmi:
 1) creare il mountpoint /boot1 per /dev/hdb1 (inutile peraltro)
 2) via swapon attivare anche /dev/hdb2 (ma mi sa che viene fatto in
automatico alla partenza del sistema, visto che il disco c'è, è
partizionato, e la fstab riporta anche hdb2 come swap)
 3) raidhotadd /dev/md0 /dev/hdb3  rimettendo in linea il 2.do disco: a
questo punto il RAID dovrebbe iniziare a mirrorare da hda3 ad hdb3
"ricostruendo" di fatto l'integrità del mirror (ci mette 15-20' su 40GB).
(nota: a causa di fstab, al boot il sistema vede anche hdb, quindi forse i 3
punti qui sopra son tutti optional/inutili)

 Ora... il tutto potrei benissimo testarlo comprando preventivamente una
coppia di HD e semplicemente togliendo (senza distruggerli X-D) i due HD
attuali: m'interessava però capire se i ragionamenti di cui sopra erano
corretti o se mancava qualcosa.
 Se il procedimento è così semplice me lo segno e basta, se invece
risultasse dubbio o complesso allora sarebbe il caso di fare due prove...
just in case. ;-)
(toccatina di maroni)

	LC




Maggiori informazioni sulla lista Lug