Newsgroup: it.comp.os.linux.sys
Titolo: Backup - Info su bacula

Ciao a tutti
 
  avrei necessità di mettere su un bel sistemino di backup e per farlo 
ho pensato di utilizzare bacula. Ho letto rapidamente un po' di 
documenti in giro e mi pare di aver capito essere un sistema molto 
completo anche se non immediato nell'installazione/configurazione (ma 
questo non lo vedo come un problema insormontabile).
 
Mi sono venuti però alcuni dubbi che spero qualcuno di voi riesca fugarmi:
- se durante il backup un file di grosse dimensioni (mi viene ad esempio 
in mente un file qcow2 di una VM di 60GB) viene modificato, il backup 
resta comunque consistente e utilizzabile?
- stesso discorso di sopra ma su un DB MySQL...
 
Ora: premesso che una VM e un DB debbano comunque essere backuppati per 
i fatti loro, in caso di restore totale della macchina (/, /var ecc...) 
mi trovo comunque a dover restorare anche il DB o la VM corretto?
 
Altra domanda: mi pare di aver capito che è anche possibile (specie per 
le macchine linux) fare un bare metal recovery, ovvero tramite una 
qualunque live restorare in toto una macchina andata KO anche su un 
disco differente (posto di avere comunque un backup completo della 
macchina da restorare), me lo confermate? Funziona anche per macchine 
con LVM e/o controller RAID HW (ad esempio un server HP con controler 
P410) e con il RAID SW di linux?
 
Grazie a tutti
 
Beppe

 - stesso discorso di sopra ma su un DB MySQL...
 
Come sopra
 
Enrico

Grazie per la risposta.
Ho perň un ulteriore dubbio sul tuo "No" :-). Intendi no, la VM o il DB 
non sono piů utilizzabili (e questo mi pare pacifico) o l'intero backup 
della macchina non č utilizzabile?
Grazie ancora

 Grazie ancora
 
Come ti dice il buon Enrico il backup in questo modo non è consistente 
(inerente al solo DB), però puoi usare dei "trucchi", come? Bacula 
prevede la possibilità di eseguire degli script pre e post backup, 
quindi per MySQL ad esempio:
 
- pre script : dump del DB in apposita directory temporanea
- backup della directory di cui sopra
- post script : ravanamento della directory
 
Oppure se ti puoi permettere un tot di down, fermo servizio, backup, 
avvio servizio …
 
Per quanto riguarda le VM il discorso divrenta IMHO molto più 
complesso, e se vedi i post vecchi se ne è parlato parecchio (backup 
dei file sull'host vs backup dei file sul guest …).
 


 
Ottimo mi andrò a ricercare il vecchio post allora.
Grazie mille anche a te per il supporto

 altro per avere una conferma)
 
Si, ma è "giusto" che sia così.
Il dover ripristinare un backup del database è molto più frequente rispetto al dover ripristinare una intera VM.
Se non hai un backup del solo database (fatto magari con un dump sql in beforeJobs di Bacula) l'unico modo che avresti per ripristinare un db sarebbe quello di fare il restore di tutta la VM su una VM di appoggio. Inoltre, backuppare l'intera VM senza dumpare il database renderebbe il backup della parte DB inconsistente.
 
Fidati, dopo una grossa dose di bestemmie iniziali Bacula va da solo e fa il suo sporco lavoro egregiamente senza necessità di intervento, compreso backup (consistente) di database.
 
Noi, ad esempio, backuppiamo tutte le VM avendo un beforeJobs eseguito da bacula che richiama mysqldump. venendo eseguito prima del backup vero e proprio, il dump sarà poi preso su da bacula e backuppato. In caso di restore, faccio il restore del solo file sql inerente il db in questione senza ripristinare tutta la virtual machine.

Aggiungo alcune considerazioni a margine rispetto a quanto riferito 
giustamente da Gandalf.
 
Se cominci ad avere parecchi host da backupare (che siano host fisici o 
guest virtuali poco importa), considera di far eseguire il dump del DB 
da una procedura lanciata da cron (all'interno dall'host, non da bacula 
per capirci). In questo modo sei certo di quando verrà eseguito il dump 
(di solito fatto in periodi di poco lavoro).
 
Inoltre potresti pensare a creare 2 job distinti, uno per i vari files 
del guest, ed uno specifico per il db. In questo modo puoi adottare 
politiche di retention e livelli di backup (intendo qui full, 
incremental, differetial) differenti. La maggior complessità così 
introdotta ti potrebbe però portare il vataggio di consumare meno 
spazio, ed avere un backup del DB il più frequente possibile.
 
Ci sarebbbe poi da affrontare il discorso dell'uso di pool differenti, 
associati a storage differenti, ma vai avanti un passo per volta …
 
Diciamo che a seconda del filing che puoi avere con Bacula ci 
impiegherai qualche giorno per pianificare la configurazione e qualche 
mese per poi affinarla.
 

 della macchina non è utilizzabile?
 
Intendo che il backup della macchina o del db non sono utilizzabili, a causa 
dell'architettura stessa di questi sistemi. Per farti un esempio, mi e` 
successo spesso e volentieri di trovarmi a lavorare con macchine virtuali 
(Virtualbox, ma e` inifluente ai fini del discorso) che gli utenti hanno 
copiato a macchina accesa. Il risultato e` stato che la macchina per un 
motivo o per un altro non funzionava, ovvero il file vdi risultava corrotto 
anche se in qualche modo funzionava tutto, con la conseguenza di farmi 
perdere molto piu` tempo per risistemare il risistemabile piuttosto che 
ripartire con una macchina virtuale pulita
 
Enrico

 (di solito fatto in periodi di poco lavoro).
 
Perchè? se è una semplice questione di tempo, non cambia nulla.
Se vuoi backuppare un host alle 3 di notte, o fai partire il backup dei db alle 2 (e quindi comunque fuori dalle ore di basso lavoro) oppure lo fai backuppare a bacula, alle 3 che però può portare a terminare il backup in orario non appropriato.
 
Alla fine non cambia nulla, o anticipi, o arrivi lungo. Sposti solo il problema ma non lo risolvi.

 ripartire con una macchina virtuale pulita
 
Domanda, in caso di macchine virtuali, non conviene
fare lo snapshot di tutta la macchina e fare poi il
backup di quello (cioe` del file di snapshot)?
 
bye,
 
-- 
 
piergiorgio

 problema ma non lo risolvi.
 
Pi� o meno si. Consideriamo per un attimo solo il job di backup del db. 
Penso che dal punto di vista computazionale sia pi� oneroso fare il 
dump e magari la sua compressione, che il carico che provoca bacula-fd 
per copiarsi solo il tgz del dump. In questo caso con cron sei sicuro 
di fare il "grosso" del lavoro a server scarico, in una configurazione 
estesa di bacula magari non sei sempre certo che il backup verr� 
lanciato ad una determinata ora.
 

 lanciato ad una determinata ora.
 
Hai però due problemi:
1) se il dump dovesse rallentare, rischieresti di backuppare un dump non ancora terminato (bacula parte sempre e comunque alle 03:00, te il dump lo fai alle 02:00 ma se dovesse impiegare 65 minuti, sei fritto)
 
2) anche non considerando il problema 1, la copia dei file tramite bacula non è 'leggerissima'. Anzi, non escludo che sia più invasiva rispetto ad un dump. Quando copi lui si gira tutto il disco, facendo aumentare il load anche di parecchio in server con molti file. Il dump solitamente è più leggero.
 
Su server con molti file io ho come problema principale tenere il load basso nelle ore notturne, quando parte bacula (peggio ancora rsync, che è anche molto più lento di bacula) schizza alle stelle. Il dump del database l'ho eseguito spesso anche in pieno giorno per fare dei test allo script e non ho notato variazioni apprezzabili sul carico del server.
 

Il dump del DB viene già fatto durante le ore notturne, i miei inoltre 
erano dei dubbi di carattere generale (credo possano essere applicati su 
quasi tutti i sistemi di backup)...
 
Più che altro la mia intenzione era quella di modificare la politica di 
backup e disaster recovery: oggi viene fatto il dump del DB con 
mysqldump (e quello resterà comunque attivo) oltre ad un tar della 
macchina (uno della /etc ed uno del'intera macchina).
La mia intenzione era appunto modificare la seconda parte del backup e 
renderlo un po' più "fine" utilizzando appunto bacula. Così anche in 
caso di guasto HW e successivo cambio della macchina potrei comunque 
utilizzare le funzionalità di Bare Metal Recovery. A proposito qualcuno 
ha mai utilizzato questa "feature?".
Da quel che ho capito bisogna creare un CD per ogni macchina di cui si 
vuole una sorta di gold image.
Suppongo però che queste iso vengano create sulla macchina da backuppare 
e bisognerà poi manualmente spostarle su uno storage sicuro e facilmente 
accessibile in caso di emergenza.
Qualcuno ha esperienze in tal senso?

 - stesso discorso di sopra ma su un DB MySQL...
 
Io vado sicuramente contro corrente, oltretutto probabilmente anche OT.
Ci sono dei momenti in cui utilizzare dei software che non ci costano 
nulla può essere comodo e spesso ne ricavi anche performance e features 
migliori dei software commerciali (mooolto spesso), ed altri in cui il 
software commerciale effettivamente da qualcosina in più e fa la differenza.
 
Il backup, in taluni casi (nello specifico quando ci sono VM e database 
"delicati", ma anche tape library da gestire etc..) a mio parere, è uno 
di questi. Nulla togliendo a Bacula, che utilizzo e trovo splendido per 
il 99% delle situazioni, personalmente utilizzerei qualcosa di specifico 
quando invece ho necessità di tirar dentro VM senza far danni e senza 
preoccuparmi del loro contenuto. Semplicemente perchè c'è chi fa già 
questo "di mestiere", e spesso 400 o 600 euro di software di backup, per 
chi ha pagato magari 5.000 euro di licenza vmware, non è che faccia poi 
la differenza.
 
Ovviamente prendi questo mio parere al di fuori del tuo caso specifico, 
si tratta di una considerazione del tutto personale e generica. Lungi da 
me screditare il fantastico Bacula che, ripeto, utilizzo e apprezzo.
 

 la differenza.
 
Come non quotarti, Veeam Backup & Replication costa le cifre che dici e funziona benissimo, una volta installato e configurato te lo dimentichi. 


Pensavo proprio a quello :)

Completamente d'accordo con voi, il problema semmai è quando non si 
spendono neanche i soldi per le licenze di VMWare ma si usa solo la 
versione Free con tutti i limiti del caso :-(


C'è semrpe ghettoVCB che fa il suo dovere

 C'è semrpe ghettoVCB che fa il suo dovere
 
Questo non lo conoscevo, gli darò un'occhiata quanto prima, grazie per 
la dritta!
 

 C'è semrpe ghettoVCB che fa il suo dovere
 
Oppure la versione free di Veeam Backup & Replication
 
Enrico

 backup di quello (cioe` del file di snapshot)?
 
Dipende sempre dal costo dell'operazione, il backup di un applicativo e` 
molto piu` piccolo del backup di un sistema (e, inoltre, puo` essere piu` 
granulare). Di contro, il backup di un intero sistema permette di ottenere 
dettagli che nel backup applicativo potrebbero essere persi (e.g. 
configurazioni specifiche della macchina). Infine, nulla ti impedisce di 
fare tutti e due, ad esempio il backup del sistema una volta messo a punto 
ed ogni volta che fai qualche variazione mentre il backup dell'applicativo 
in ogni altro caso
 
Enrico

 Oppure la versione free di Veeam Backup & Replication
 
Oppure phdvirtual (
http://www.phdvirtual.com/
) che però (come la versione free di Veeam) non può essere schedulato.