linux user group brescia

Il giorno 24/feb/09, alle ore 08:45, Diego Guella ha scritto:
>> home:~# cat /etc/fstab
>> # /etc/fstab: static file system information.
>> #
>> # <file system> <mount point>   <type>  <options>       <dump>   
>> <pass>
>> proc            /proc           proc    defaults        0       0
>> /dev/md0        /               ext3    defaults,errors=remount- 
>> ro  0       1
>> /dev/hda1       /boot           ext3    defaults        0       2
>> /dev/hdb1       /boot1          ext3    defaults        0       2
>> /dev/hda2       none            swap    sw              0       0
>> /dev/hdb2       none            swap    sw              0       0
>> /dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
>> /dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0
>> home:~#
>>
>>  In pratica hda1/b1 fuori RAID per la partizione di boot, hda2/b2   
>> fuori RAID come swap, hda3/b3 con il root filesystem in RAID1.
> Giusto per capire meglio, cosa ti torna cat /proc/mdstat ?

home:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hda3[0] hdb3[1]
       156007104 blocks [2/2] [UU]

unused devices: <none>

  Solo hda3/hdb3 sono in RAID.

>>  Ora... se per effettuare il backup facessi semplicemente un "dd  
>> if=/ dev/hda of=/dev/hdd" (con tutte le opzioni del caso) montando  
>> come  hdd un disco da 160 GB esattamente uguale ai due in hda/hdb?
>>  Dovrei ottenere un "backup fisico" no? (compreso MBR caxxi e maxxi)
> dd if=/dev/hda of=/dev/hdd (senza nessuna opzione) ti clona l'hard  
> disk master sul canale primario sull'hard disk slave sul canale  
> secondario, incluso MBR, tabella delle partizioni, partizioni  
> estese, etch etch etch..

L'idea era quella, sì.

> Se lo fai a sistema acceso, tieni conto che il filesystem potrebbe  
> non essere consistente (prendi ad esempio il caso che mentre tu fai  
> dd qualcuno sta copiando un file da 10GB)

Ok... è corretto pensare sempre ad un server come "popolato da N  
utenti che possono fare N^M cose"... anche se, realisticamente, sul  
mio server di casa in quel momento ci sarò solo io. ;)
(mal che vada setto nologin :D)

>>  Pensavo che:
>>  1) dovendo recuperare un file o una directory "persa" (grazie al   
>> solito rm -f *  :D), mi basterebbe montare hdd in un eventuale / 
>> mnt/hdd
> si

ok

>>  2) volendo anche solo ripristinare un MBR su hda (o hdb) mi   
>> basterebbe prenderlo da hdd
> si

Perfetto (questo, in passato, mi ha creato problemi dato che facevo  
un backup incrementale dei soli file)

>>  3) e se si distruggesse ad esempio hda potrei sempre ripartire   
>> dalla copia fisica (hdd) anche su due nuovi dischi (tenendo hdb  
>> come  "disco dati" contenente un delta dall'ultimo backup su hdd).
> Puoi ripartire da hdd, ma la storia del delta non l'ho capita.
> Se intendi partire da hdd e montare hdb in /mnt/hdb, e usarlo come  
> disco contenente dati più aggiornati del backup, ok.

  No, il discorso del "delta" era dovuto al fatto che, montando il  
disco di backup come "primario" (in caso mi ceda hda intendo, che è  
quello che fa il boot) mi ritroverei con i dati "al tempo del backup"  
ed il disco secondario (hdb) più aggiornato, tutto qui: a 'sta cosa  
magari devo pensare, ma quanto meno il server torna su "all'ultimo  
backup".
  Se i backup li faccio tipo (almeno) una volta alla settimana,  
l'eventuale "perdita" l'avrei quasi tutta nei log dei servizi (e  
nella mail, ok)... forse sarebbe il caso, in questa occasione di far  
partire hdb come primario (spostandolo sul canale primario del primo  
controller IDE intendo) copiandogli sopra il MBR (meglio ancora se  
l'MBR lo copio ogni volta che aggiorno il kernel, forse... insomma,  
ci devo pensare ;))

  A parte quanto sopra, diciamo che, primariamente, avrei il backup  
dei dati, secondariamente quello dell'MBR e poi come terzo benefit  
(da architettare un pò bene) il restart "veloce" (o comunque  
"possibile" ;)).

>>  Ma a parte i contorcimenti mentali qui sopra, con un dd al   
>> contrario (fatto magari partendo da un CD di recovery) avrei il  
>> sistema che in poco tempo è ripristinato "all'ultimo backup" no?
>> (in generale stavo tentando di evitare cose come "sistemi di  
>> backup e  restore" ed altre cose come "backup incrementali e  
>> restore...  incerti" ;))
> La soluzione che uso io è un array raid1 con n+1 dischi.
> il +1 è il disco di backup, che se ne sta sempre fuori dall'array.
> Esempio con 3 dischi A, B, C:
>
> Avvii il sistema con con A, B (C fuori).
> Spegni, aggiungi C, togli B.
> B è ora il disco di backup, C è il secondo mirror.
> Accendi, e fai il resync di C (mdadm /dev/md0 -a /dev/hdc).
> Quando il resync sarà finito, avrai nuovamente ridondanza completa  
> dei dati.
> (se non vuoi mai perdere la ridondanza in nessun istante, usa 4+  
> dischi)
>
> Ogni volta che vorrai fare un backup, il backup sarà già pronto e  
> non dovrai far altro che scambiare i dischi.

  Ecco... pensavo di fare qualcosa di simile, ma senza spegnere/ 
accendere: mount/umount dovrebbero bastare, unitamente al mettere  
parzialmente fuori servizio parte del mirror, ma tutto via sw.
  In pratica l'idea sarebbe di aver sempre i tre dischi "online" (AKA  
visibili al controller): due montati ed in RAID ed il terzo unmounted.
  Ad intervalli regolari, mdadm -r /dev/hdb, umount /dev/hdb, mount / 
dev/hdc, mdadm -a /dev/hdc (ed in hdb ho il backup) e via così a  
rotazione (tra hdb ed hdc, per sicurezza).
  Fra l'altro ho visto che, per il momento, un resync dei due HD del  
mirror impiega c.ca 3 ore (che sarebbero le "ore pericolose" in cui  
il mirror va a mezzo servizio).

> Tieni conto che puoi anche fare il mirror di /boot (io lo sto  
> facendo, con Lenny), e puoi anche mettere un boot loader su ogni  
> disco, così che se hai la necessità puoi ripartire istantaneamente  
> con un backup.

  Ecco... anche questa era un'idea che volevo sviluppare: non mi  
dispiacerebbe poter tornare su con il sistema, in caso di crash  
fisico del disco primario, magari settando nel BIOS lo startup su hdb  
(se è possibile: da verificare)... o anche solo spostando il secondo  
disco del mirror (e spostando i jumper, se è secondario).

  Insomma, a parte qualche piccola verifica da fare, più o meno quel  
che pensavo è fattibile: ti ringrazio delle conferme, Diego, è un pò  
che devo sistemare il capitolo "backup" in modo sensato.

>
>>  Ultima cosa: volendo tentare l'upgrade da Etch a Lenny, un bel   
>> backup "totale" mi pare il minimo.
> eh si!

  Sarebbe il mio primo upgrade di distro... son curioso di vedere  
cosa succede.
  In genere mi tenevo "la distro presente" fino ad un crash ed  
aggiornavo installando direttamente quella dopo (estremamente poco  
professionale, lo so ;))

	LC