Re: sauvegarde et virtualisation
Le Tuesday 18 November 2008 vers 22:04, tôba(tôba <toba@tsepa.net>) a
écrit:
> On Tue, 18 Nov 2008 21:32:08 +0100
Bonjour,
> Mais si on sauvegarde la machine virtuelle en tant que OS, çà ne
> risque pas de corrompre les fichiers plats non? Car ce sera des
> fichiers "normaux" que l'application de sauvegarde va traiter.
> Par exemple: On a une machine Debian sur laquelle on installe
> VMWARE. On en gagne après, un systeme virtuel Ubuntu et un
> Windows. Est-ce qu'installer directement une appli de sauvegarde
> cliente (Bacula Client par ex) ne resoudra pas ces problemes de
> gros fichiers? Car l'appli de sauvegarde traitera Ubuntu et
> Windows mais pas VMWARE (à moins qu'on sauvegarde aussi Debian).
> Corrigez-moi si j'ai tort.
En gros, on a:
Debian (Hôte)(SVG_HOTE_X
--------------
| |
| ----------- |
| |VM1(SVG_VM)| |
| |Ubuntu | |
| ----------- |
| |
| ---------- |
| |VM2SVG_VM)| |
| |Windows | |
| ---------- |
----------------
Politique de sauvegarde:
------------------------
Ce qui donne au moins 2 fichiers vmdk : 1 pour vm1 (2Go sur le
système hôte avec 500M occupés sur le système virtuelle) et 1 pour
windows(10G sur le système hôte avec 5G occupés sur le système
virtuelle).
* On fait une sauvegarde par bacula des OS VM1 et VM2 (SVG_VM).
* On fait également une sauvegarde du système hôte par bacula avec 3
policies(SVG_HOTE)):
1/ Sauvegarde totale de *tous* fichiers modifiés depuis la
sauvegarde précédente. On va sauvegarder, sans *précautions*
*particulière*, les fichiers .vmdk de VM1 et VM2 *tous* *les*
*jours* car ces fichiers sont modifié presque tous les
jours(SVG_HOTE_1).
2/ Sauvegarde totale de *tous* fichiers modifiés depuis la
sauvegarde précédente *avec* un état stable de Vmware (arrêt des
machines virtuelles ou pause de la machine VM + snapshot de LVM). On
va sauvegarder les fichiers .vmdk de VM1 et VM2 *tous* les jours car
ces fichiers sont modifié presque tous les jours(SVG_HOTE_2).
3/ Sauvegarde totale de *tous* fichiers modifiés depuis la
sauvegarde précédente, mais en excluant les fichiers .vmdk (dans
l'exemple, cela donne 15Go de moins à sauvegarder, SVG_HOTE3)
Politique de restauration:
--------------------------
* Restauration d'un fichier des OSs installés dans VM1 ou VM2 : pas
de problème on va chercher directement la sauvegarde de ces machines
faite par bacula (SVG1, dans l'exemple)
* Crash disk de la machine hôte ou perte d'un fichier .vmdk (un
rm -rf malheureux bien placé) : dans ce cas on a besoin de la
sauvegarde SVG_HOTE. Sinon, il faut une installation complète de
l'OS et recréation des 2 VM. On a défini 3 politique de sauvegarde
SVG_HOTE. On peut directement exclure la sauvegarde SVG_HOTE_3, car
les fichiers .vmdk n'ont pas été sauvegardées. Il nous en reste 2:
* SVG_HOTE_1 : Cette sauvegarde permet de récupérer les
fichiers .vmdk, mais la machine virtuelle peut refuser de démarrer
car son système de fichier contenu dans le fichier .vmdk peut être
dans état instable car VMware était en exécution pendant la
sauvegarde. J'ai fait quelque tests. La machine virtuelle a toujours
démarré après un *fsck*. Mais, sur une machine prod, je ne prendrais
le risque...
* La seule sauvegarde valid est SVG_HOTE_3 car la sauvegardes
fichiers .vmdk s'est fait dans un état stable (arrêt de la VM ou
pause de la VM + snapshot LVM ==> faible downtime de la machine VM).
En conclusion :
---------------
* La sauvegarde des VM directement est de toute façon nécessaire.
Sinon, la restauration d'une liste de fichiers (par
exemple /etc/paasswd de la machine Ubuntu) est impossible sans
restaurer l'intégralité du fichier .vmdk
* La sauvegarde SVG_HOTE_3 est également nécessaire (cas de crash de
la machine hôte)
Donc,
* La sauvegarde idéale serait, donc, un outil capable de combiner la
sauvegarde SVG_HOTE_3 *et* SVG_VM. Je ne connais pas d'outil
permettant de faire pour VM Ware Server. Si quelqu'un en connaît un,
je suis prenneur
* La sauvegarde de l'admin qui veut une méthode sauvegarde et
restauration simple : faire SVG_HOTE_3 et SVG_VM tous les jours.
Mais,il faut tenir compte de la fenêtre de sauvegarde.
* La 3è méthode est une combinaison de de SVG_HOTE_* et SVG_VM :
* SVG_VM et SVG_HOTE_3 tous les jours et une SVG_HOTE_2
régulièrement (ou chaue modif de la config des VM).
Nous, pour l'instant on a opté pour la méthode 2, car on tient notre
fenêtre de sauvegarde pour *l'instant*
Je pense que c'est un point épineux de toutes solutions
virtualisation dont le système de fichiers d'une machine virtuelle
est contenu dans un fichier plat fichier présent sur la machine
hôte (vmware, virtualbox, kvm, qemu) n'est pas reconnu par l'outil
de sauvegarde.
Voilà, j'espère que c'est claire et que j'ai pas trop raconté de
conneries....
A+
--
http://www.glennie.fr
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.
Reply to: