[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xen + debian lenny + sauvegarde VM



Le 29/12/2010 16:59, Jean Baptiste FAVRE a écrit :
> Bonjour,
> 
> Le 29/12/2010 15:32, Thierry B a écrit :
>> Le 28/12/2010 10:51, Thierry B a écrit :
>>> Bonjour,
>>>
>>> Je voulais savoir si quelqu'un utilisait une config serveur xen + debian
>>> lenny à partir de laquelle il fait des sauvegarde VM régulières?
>>>
>>> Sur ma dedibox, j'utilise une lenny avec xen de testing et pour ma
>>> sauvegarde de VM, je fais un script qui pour résumer fait :
>>> - xm pause
>>> - Création d'un LV snapshot à partir du LV de la VM
>>> - xm unpause
>>>
>>> Qu'en pensez-vous?
> 
> Pas de raison que cela ne marche pas.
> 
> 
>>> Avant le xm pause / unpause, c'etait xm save VM / xm restore VM, mais
>>> une fois,  lors de l'exécution automatique du script, j'ai eu un
>>> plantage à cause de cela, et j'ai du redémarrer ma machine physique
>>> carrement pour pouvoir redemarrer ma VM, le pause /unpause a l'air moins
>>> méchant...
> 
> C'est juste totalement différent: save / restore est comparable à la
> mise en veille, pause / unpause à un freeze passager.
> 
> Si on compare avec un process, pause/unpause c'est comme si tu
> interdisais au noyau d'accorder du CPU à un processus.
> Avantage: bcp plus rapide que save / restore et moins douloureux.
> Inconvénient: peut-être embêtant avec des processus temps-réel (?)
> 
>>> Sinon, y'a aussi la solution, de faire un shutdown et de la relancer
>>> mais bon, c'est p-e pas top pour une config serveur non?
>>>
>>> J'attends vos avis.
>>>
>>> Merci :-)
>>>
> 
>> Hello,
> 
>> A priori, ça ne fonctionne pas trop mal en essayant de restaurer cela
>> sur un autre domU.
> 
>> Le soucis, c'est qu'il n'arrive pas à démarrer clamav et il me dit qe ce
>> n'est pas clean niveau mysql.
> Pour Clamav je ne sais pas trop (un fichier de lock, un socket qui
> traîne ?), mais pour MySQL cela ne m'étonne pas du tout. C'est comme si
> tu sauvegardais tes bases MySQL en faisant un snapshot LVM: les pools
> innodb sont utilisés, les tables MyISAM idem, ...
> 
> La restauration est alors comparable à un redémarrage de serveur après
> un arrête électrique !
> 
> Je m'étonne d'ailleurs que tu n'ais aucun message d'erreur concernant le FS.
> 
>> Idéalement, faudrait peutêtre stopper ces services avant le xm pause
>> puis les relancer après le xm unpause...
> Mouais, pourquoi pas.
> 
>> Comment puis-je faire cela?
> SSH ?

Ha ok, mais euh le problème c'est qu'il n'y a que root, qui puisse sur
ma VM stopper / lancer les differents serveurs, donc faudrait un systeme
de clé public - privée entre le root de mon dom0 et domU, pourquoi pas.

J'allais dire que c'est pas très secure, mais bon aprèd tout, on reste
sur la même machine physique lol.

> 
> Sinon, tu as une autre possibilité:
> 1. snapshot LVM
> 2. fsck sur le snapshot (peut-être besoin de kpartx avant, tout dépend
> de ta conf LVM)
> 3. montage du snapshot
> 4. effacement des sockets et lock
> 5. vérification MySQL à froid
> 6. umount snapshot
> 7. dd du snapshot dans une archive

Les lock se trouvent tous au même endroit?
Tu penses que ça garantie la cohérence du snapshot?

J'utilise rdiff-backup sinon, c'est nikel pour les sauvegarde
incrementales (1 complète en début de mois et une incrémentale par
exemple chaque jour jusqu'à la fin du mois) et pour se restaurer pile
poil la sauvegarde voulue :-)

> 
> 
> En conclusion, utiliser ce type de système pour sauvegarder des data
> (MySQL) ne sert à rien. Autant continuer à avoir des scripts "classiques".

Méthode classique cad dans mon cas?
Shutdown de la VM puis création du LV snapshot puis redémarrage de la VM?

A priori, même pour x serveurs tournant dessus dont du mail, une coupure
journalière de moins d'une minute, ne serait pas dramatique.
Ca resterait p-e la solution la plus sure.

> 
> Cordialement,
> JB

Merci :-)


Reply to: