Fabio Muzzi kurgan@xxxxxxxxxx [mlerlug/Lista ERLUG] wrote:
Ancora una volta sono qui a chiedere qualcosa sui massimi sistemi,
sulla Pura Teoria.
Questo sito e in particolare questa pagina sono interessanti:
http://www.backupcentral.com/toc-free-backup-software.html
Pensavo alle strategie di backup, e a quale consente di ottimizzare
al meglio i tempi di down in caso di grave guasto (tipo esplosione
del disco).
Escludendo il raid o il mirroring, parliamo solo di copie su nastro
o simili... il miglior modo per ripristinare un sistema da zero (sul
disco vuoto) a mio avviso e` quello di fare una immagine del disco
fisico (con programmi tipo DriveImage, Ghost o simili) e ricaricarla
sul disco nuovo. Fare questo pero` implica che il sistema deve
rimanere fermo per il tempo necessario a fare l'immagine del disco,
e questo deve succedere tutte le volte che si fa un backup. Cosi` i
fermi dovuti al backup sono molto piu` lunghi dell'eventuale fermo
dovuto al restore.
Ecco, non sono d'accordo. Il motivo è semplice: non ho mai visto una
soluzione del genere funzionare. In teoria, tutte dovrebbero funzionare
ma come tutti sanno nell'informatica finchè non provi non ne sei sicuro
(il motivo è la complessità, non c'è niente di mistico: una persona che
pensa "dovrebbe funzionare" sta semplificando troppo). Provare vuol
dire provare un restore (dò per scontato un passaggio di verifica dopo
la scrittura): meglio, vuol dire provare che la procedura di restore
funzioni.
L'immagine del disco ha i problemi che hai individuato, e aggiungo che
al ripristino si possono avere delle sorprese. Per esempio: se vengo da
un disastro serio (incendio) tipicamente ho una macchina che *non ha*
lo stesso hardware della macchina originale, non si trova più. Ne segue
che il kernel ottimizzato per Athlon sull'immagine del disco non parte
sul mio Pentium 6. Niente che un sistemista non sia grado di gestire,
ovviamente, ma il discorso comincia a cambiare da "un click e si
ripristina tutto da solo" a "allora, prima installo il kernel, poi
recupero tutto tranne il kernel ... e i moduli ... però ora devfsd
ha una configurazione diversa ..." e l'esempio è meno campato in
aria di quanto pensiate perchè:
- i server hanno in genere hardware che funziona bene, dura nel tempo
e non si ricompra con tanta allegria;
- i guasti sui server Linux e Unix sono rari, in particolare una volta
messa a punto la configurazione (ecco, una immagine una tantum non
la vedo male invece);
- l'hardware evolve velocemente;
- Linux evolve velocemente.
Altrimenti si va di nastro e tar, ma una cosa mi sono sempre
chiesto: salvo /dev/ o no? E se no, come la ricostruisco in seguito?
La procedura di restore deve obbligatoriamente prevedere che io
prima ripartizioni il disco, poi che monti le partizioni girando da
una root diversa (tipo un cd di quelli di emergenza) e poi che
ricarichi tutto sulle varie partizioni... e il boot loader? e i
devices?
Qual'e` la procedura piu` rapida per fare tutto cio`?
Secondo me, vale la pena di cercare una procedura rapida se qualcosa
accade di frequente e quindi lo devo fare spesso. Per qualcosa che
accade di rado occorre una procedura *sicura* nel senso che mi dia
la certezza del risultato, tenendo ben presente che se accade di rado
non sono allenato a farlo, di solito lo devo fare in circostanze un
pò particolari e quindi la procedura deve fare più controlli di quanti
ne faccia io.
Per quel che riguarda le macchine di cui mi occupo io:
- salvo l'elenco degli RPM installati;
- escludendo aree, p. es. /home, che non sono "di sistema" e per cui
valgono strategie diverse (volendo anche nessun backup per gli
antipatici, stile BOFH), salvo tutto ciò che è cambiato rispetto
a quanto installato oppure non è stato installato da RPM e quindi
potrei non riuscire a recuperarlo;
- quanto detto va a finire in un .tar.gz, uno per host, e tutti i
.tar.gz vanno su nastro (sono piccoli);
La mia procedura per un disastro è:
- mi procuro una macchina funzionante;
- ci installo la distribuzione più vicina alla distribuzione originale
che funziona su tale macchina;
- installo gli aggiornamenti di sicurezza;
- ripesco il .tar.gz, lo esplodo a parte e armato di diff, con santa
pazienza e con le manine della festa rimetto tutto a posto;
- per finire lo attacco alla rete.
Tale procedura è "sicura" nella misura in cui mi fido della mia
capacità di mettere a posto le cose e del sostanziale buon
funzionamento di Linux. D'altra parte, se Linux sull'hardware nuovo
non va e l'hardware vecchio non lo trovo ...
Ora, evidentemente se lavorassi in Google dove hanno migliaia di host
e se ne guasta più di uno al giorno dovrei adottare una strategia
diversa. Con pochi host, tuttavia, mi pare che inseguire il ripristino
rapido sia una strategia i cui benefici non sono bilanciati dai costi.
Se ci fosse uno strumento che "migra" una installazione Linux
funzionante da un host a un altro (perchè questo è il problema),
sarei felice di saperlo.
Davide Bolcioni
--
There is no place like /home.
|