View Full Version : Backup Virtual Machine su Esxi 5
maurocheccoli
23-03-2014, 23:04
Ciao a tutti,
sto analizzando quale sia la soluzione di backup migliore per il mio sistema esxi free edition.
Ho testato vari softaware, tuttavia non sono riuscito ad avere dei backup che abbiano una velocità di esecuzione accettabile.
Ad esempio, adesso sto testando Unranium Backup, la versione che mi permette di collegarmi all'host esxi per intenderci, è tutto molto bello e semplice, se non per il fatto che per effettuare il backup di 5 VM è in esecuzione da 2 giorni e non ha ancora finito.:muro:
Anche con altri software i tempi di backup sono assurdi se consideriamo che le VM in totale non superano 1 TB, che è la capacità fisica dell'host.
La configurazione del backup è la seguente:
Ho installato Uranium Backup su una VM con Windows Server 2008;
ho attaccato fisicamente all'host via usb 2.0 un hdd da 3TB che deve ospitare il backup delle VM.
Creo il Job di copia da Uranium che si interefaccia tra l'host esxi l'hdd usb.
Risultato, ore e ore di backup inifinito.
Non riesco a capire dove sta il collo di bottiglia, usb 2.0 ha comunque una velocità accettabile di 480 Mbit/s, quindi per copiare 1TB non ci dovrebberero volere 2 giorni!
Qualche consiglio su come implementare al meglio il backup delle VM???
Software a parte!
PhoEniX-VooDoo
24-03-2014, 08:22
stai usando questi esxi in produzione o in laboratorio?
Tasslehoff
25-03-2014, 00:10
Non riesco a capire dove sta il collo di bottiglia, usb 2.0 ha comunque una velocità accettabile di 480 Mbit/s, quindi per copiare 1TB non ci dovrebberero volere 2 giorni!
Qualche consiglio su come implementare al meglio il backup delle VM???
Software a parte!Beh insomma tieni presente che quei 480Mbps (Mbit eh, non MB) rappresentano la banda passante teorica di una connessione usb 2.0, più realisticamente devi considerarla tra i 160 e 200 Mbps (ovvero 20-25 MB/s).
Anche considerando il caso migliore movimentare 1TB di dati richiederebbe più di 11h e mezza, questo senza alcuna altra interferenza, ovvero attività di I/O durante la copia.
Ma sappiamo tutti che questo è impossibile se intendi fare uno snapshot a caldo, perchè nel frattempo Vmware gratta su quel datastore, e "gratta pesante" :asd:
Se poi lo storage è SATA (quindi poco performante in termini di IOPS, specialmente per attività concorrenti) e ci girano sopra diverse VM capisci bene che la previsione di quel tool di backup non è poi così campata per aria.
Tieni presente poi che gli snapshot non sono la panacea di tutti i mali, dipende tutto da cosa gira sulle vm però ci sono servizi (es molti tipi di database) che digeriscono davvero male un restore da un backup di questo tipo, quindi in questo caso rischi di ritrovarti con un backup perfettamente inutile.
Gli snapshot sono utilissimi per preparare il campo in caso di disaster recovery, però in molti casi devono essere affiancati da un backup tradizionale preparato con i tool specifici dei servizi su cui si sta lavorando (insomma ogni backup è una storia a se e non esistono soluzioni valide sempre in tutti i casi).
Il mio consiglio è quello di effettuare snapshot periodici (es una volta al mese) e affiancare ad essi un backup tradizionale.
Per ridurre la finestra temporale richiesta dagli snapshot puoi "spalmare" l'attività su più giorni effettuando snapshot di vm differenti in giorni differenti, oppure puoi mettere offline o sospendere determinate vm durante il backup in modo da ridurre il carico di I/O sul datastore e agevolare il backup.
maurocheccoli
25-03-2014, 19:46
Sto usando il datastore nella mia azienda, per passare da fisico a viruale alcuni server.
Le considerazioni fatte per i backup devo dire che sono state davvero esaustive, grazie mille :)
maurocheccoli
25-03-2014, 19:52
e se esporto manualmente le VM in file OVF?
puo' essere una buona soluzione per il riprisitno in caso di crash?
Tasslehoff
26-03-2014, 00:02
e se esporto manualmente le VM in file OVF?
puo' essere una buona soluzione per il riprisitno in caso di crash?Rispetto allo snapshot non credo cambi molto, l'unica differenza è che esportando in quel formato ottieni uno snapshot che può essere scambiato anche con altri hypervisor.
Il dettaglio di cui parlavo riguardo all'uso degli snapshot come backup non riguarda solo le virtual machines, è comune a un po' tutti i sistemi di snapshot a caldo, anche ad esempio snapshot lvm su GNU/Linux o shadow copy su Windows.
E' la logica di fondo che può creare problemi, ci sono servizi che partono con datastore o datafile offline solo per il fatto che rilevano un avvio senza aver registrato una chiusura, oppure che effettuano rollback di transazioni, oppure nella migliore delle ipotesi richiedono un semplice fixup di datafile.
Gli snapshot sono un ottimo strumento per rimettere in pista un sistema in caso di disastro nel più breve tempo possibile.
Pensa alla casistica più catastrofica in cui hai perso tutta una macchina, con un semplice backup dei "dati" (qualunque cosa questo significhi, da dei semplici file al dump o backup di un database) la finestra di disaster recovery equivale al tempo di reinstallazione dell'OS + reinstallazione dei servizi + riconfigurazione dei servizi + restore del backup, ovvero tanto "tempo uomo" e tanto "tempo macchina".
Con uno snapshot + backup la finestra di disaster recovery si riduce tantissimo, sia in tempo materiale che in complessità (ci sono servizi che richiedono fino a una settimana per un setup iniziale), in pratica hai solo il restore dello snapshot + restore del backup, ovvero quasi soltanto "tempo macchina".
E' un bel vantaggio, non credi?
maurocheccoli
26-03-2014, 09:40
direi proprio di si! grazi mille per le dritte:D :D
Io in azienda ogni notte faccio circa 750Gb di backup senza troppi problemi, direttamente su un disco (rimovibile). Uso uno script tipo ghettoVCB.sh ma meno complesso (non avevo voglia di leggere la documentazione e qui mi frustano se perdo tempo :D): XSIBACKUP (http://sourceforge.net/projects/xsibackup/files/).
Ti sputa fuori i backup così:
http://i61.tinypic.com/11i0dae.png
Spero di non arrivare "tardi" con la mia esperienza :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.