Sauvegarder un invité LVM XEN contenant des LV

Sauvegarder un invité LVM XEN contenant des LV

Dans mon travail quotidien, toutes nos machines Linux (sauf 3) sont des VM Xen. Je voulais un moyen de faire une sauvegarde de celles-ci sans le risque que les fichiers changent en cours de route. Pour des raisons de performance, je les exécute toutes sur des volumes logiques.

Dans ces VM, le système d’exploitation DomU utilise à nouveau LVM pour diverses raisons. Cela crée quelques maux de tête pour effectuer la sauvegarde.

L’idée de base est :

1. Créer un volume logique de snapshot
2. Permettre au Dom0 de voir les volumes logiques à l’intérieur du volume logique (ouf).
3. Monter les volumes logiques nouvellement découverts.
4. Effectuer la sauvegarde
5. Ranger

Il y a quelques hypothèses que j’ai faites. J’ai supposé que vous avez utilisé des noms personnalisés pour les groupes de volumes dans le Dom0 (hôte) ou le DomU (invité). Personnellement, j’utilise toujours un fichier kickstart pour créer mes DomUs, donc j’ai le VG principal défini sur XenVG00. Tous mes DomU sont dans un VG sur le Dom0 appelé vg_xen - ce n’est pas essentiel cependant.

La deuxième hypothèse est que vous avez un peu d’espace libre dans le groupe de volumes contenant les images DomU. Cela ne doit pas être beaucoup, car nous allons supprimer le volume de snapshot lorsque nous aurons fini avec.

Tout d’abord, nous devons créer notre snapshot :

[root@dom0 ~]# lvcreate -L 1G -s -n lv_snapshot /dev/vg_xen/lv_xen_snaptest

Logical volume “lv_snapshot” created

Cela crée un volume de snapshot appelé lv_snapshot d’un DomU qui utilise un LV Dom0 appelé lv_xen_snaptest. Cela est utile en soi car vous pourriez maintenant prendre une image de ce LV. Je fais exactement cela pour la récupération après sinistre (dd if=/dev/vg_xen/lv_snapshot | bzip2 | dd of=/path/to/dr_image.bz2). Dans le pire des cas, cette image pourrait être ddée dans un nouveau volume logique, sur un nouveau système, pour qu’une nouvelle instance de Xen fonctionne.

Ce que nous voulons faire cependant, c’est accéder aux fichiers dans ce snapshot. Comme le DomU utilise LVM, cela n’est malheureusement pas trivial. Tout d’abord, nous devons utiliser kpartx pour extraire les données LV :

[root@dom0 ~]# kpartx -av /dev/vg_xen/lv_snapshot

add map lv_snapshot1 : 0 208782 linear /dev/vg_xen/lv_snapshot 63  
add map lv_snapshot2 : 0 20755980 linear /dev/vg_xen/lv_snapshot 208845

Vous pouvez voir que 2 LVs ont été trouvés. Comme lv_snapshot1 est plus petit, nous savons que c’est le fichier d’échange et que lv_snapshot2 est le système de fichiers /. Nous devons maintenant faire en sorte que LVM voie ces LVs et les active.

[root@dom0 ~]# vgscan

Reading all physical volumes. This may take a while…  
Found volume group “vg_xen” using metadata type lvm2  
Found volume group “XenVG00” using metadata type lvm2  
Found volume group “VolGroup00” using metadata type lvm2

[root@dom0 ~]# vgchange -ay XenVG00

2 logical volume(s) in volume group “XenVG00” now active

Maintenant que les LVs sont actifs, nous pouvons les monter comme s’il s’agissait de n’importe quel autre disque.

[root@dom0 ~]# mount /dev/XenVG00/LVroot /mnt/

Et exécuter n’importe quelle commande que nous voulons

[root@dom0 ~]# rsync -avhp /mnt/ /backup/xen_test/

Évidemment, nous devons maintenant nettoyer après nous :

[root@dom0 ~]# umount /mnt  
[root@dom0 ~]# vgchange -an XenVG00

0 logical volume(s) in volume group “XenVG00” now active

[root@dom0 ~]# kpartx -d /dev/vg_xen/lv_snapshot  
[root@dom0 ~]# lvremove /dev/vg_xen/lv_snapshot

Do you really want to remove active logical volume “lv_snapshot”? [y/n]: y  
Logical volume “lv_snapshot” successfully removed

La chose importante ici est que nous n’avons à aucun moment mis notre VM en pause, mais nous avons pu faire une sauvegarde complète de celle-ci.

La taille du volume de snapshot est la partie difficile ici. J’ai utilisé un LV de snapshot de 1G. Pour donner une idée de sa taille : au moment où une image DR de mon wiki a été prise, bzippée et envoyée par SSH à une autre machine pour stockage, l’utilisation du snapshot avait atteint près de 7%.