A quoi ça sert ?
Historiquement, les snapshots ont étés conçus pour permettre les sauvegardes des serveurs qui ne pouvaient pas être arrêtés pendant une longue période. Imaginons le cas suivant. Vous avez un serveur utilisé par des programmes qui font de nombreuses lectures/écritures à n’importe quel heure du jour et la nuit. Sauvegarder tous les fichiers de ce serveur prend des heures. Mais comme il s’agit d’un serveur « critique », il n’est pas question de l’arrêter plus de quelques minutes par jours, grand maximum. Alors, comment faire les sauvegardes ?
Tout d’abord, j’espère que tout le monde comprend qu’il n’est pas question de sauvegarder un système de fichier en cours d’utilisation. Même si les lectures sont plus nombreuses que les écritures, le système de fichier est monté, il est en cours d’utilisation. Vous pouvez essayer de le sauvegarder si vous voulez, mais vous pouvez être certain que la restauration va très mal fonctionner. « Il y a en qui ont essayé, ils ont eu des problèmes… »
Alors on fait comment ?
On fais un snapshot du système de fichier. Un snapshot, c’est une photo. On « fige » le système de fichier tel qu’il est à un instant T, et de préférence bien sur à un instant ou il est dans un état cohérent, et donc sauvegardable. Ensuite, les applications peuvent continuer à utiliser le système de ficher, pendant que nous on sauvegarde la photo.
Les étapes d’une sauvegarde réussie (et que l’on pourra restaurer sans erreurs) devraient donc ressembler à ça :
- Arrêt des programmes qui tournent sur le serveur
- Démontage du système de fichier à sauvegarder
- Snapshot de ce système de fichier (opération instantanée)
- Montage du système de fichier
- Relance des applications
Toutes ces étapes peuvent généralement se faire en moins d’une minute. Ce sera le temps total d’indisponibilité du serveur
Enfin, dernière étape (qui prendra plusieurs heures mais comme le serveur est de nouveau opérationnel, rien ne presse), la sauvegarde du snapshot. Voici ce que ca pourrait donner en terme de commandes, pour sauvegarder un système de fichier de 1 To monté sur /data :
/etc/init.d/mon_application stop umount /data lvcreate -s -n mon_snapshot -L 20G /dev/monvg/monlv mount /data /etc/init.d/mon_application start
Toutes les données sont maintenant accessibles dans /data.
Vous devez vous demander a quoi correspond le « -L 20G » de la création du snapshot. En fait, un snaphost peut prendre de la place, car il doit stocker toutes les modifications qui sont faites sur les données depuis la réalisation du snapshot. Cette taille doit être choisie avec soin, il ne faut surtout pas prendre une valeur trop faible. Si vous pensez que pendant la durée de vie du snapshot, quelques centaines de Mo seront écrits dans /data, alors mettez au moins 1 ou 2 Go. Si vous pensez que 4 ou 5 Go seront écrits, mettez en 10 ou 20… (voir plus si vous pouvez vous le permettre). Bref, soyez large. Il est toujours possible de vérifier le taux de remplissage du snapshot avec la commande : lvs
Il ne reste plus maintenant qu’a lancer la sauvegarde du snapshot :
mount /dev/monvg/mon_snapshot /mnt cp -a /mnt/* /backup
Pour la sauvegarde j’espère que vous avez des outils beaucoup mieux que la commande « cp » hein… C’est juste un exemple. Une fois la sauvegarde terminée, on peut détruire le snapshot :
umount /mnt lvremove /monvg/mon_snapshot
Note importante :
Vous trouverez ailleurs sur le net les mêmes informations, mais sans la partie démontage du système de fichier. Et si vous faite le test, ca fonctionnera. Un snapshot d’un système de fichier monté et en cours d’utilisation donnera directement un snaphost cohérent, sauvegarde et restorable dans 99% des cas. Comment ça fonctionne ? Et pourquoi je conseil quand même de démonter son système de fichier alors ?
De façon totalement contradictoire avec le principe de fonctionnement en couche, LVM sait reconnaitre l’existence de certains systèmes de fichier. (Je n’ai pas réussit à trouver la liste précise sur le net). Bref, il reconnait donc le FS présent dans le volume et « freeze » le FS en question, réalise le snapshot et fait encore pas mal d’autres choses. (Il faut notamment faire en sorte que les deux FS, disposant d’un même UUID puissent être quand même utilisé en même temps etc). Plein de choses cachés donc, qui dépendent du type du FS présent. Globalement, il est beaucoup plus prudent de choisir une approche qui fonctionnera dans 100% des cas, le démontage du système de fichier. La au moins, on est sur que le FS n’est plus utilisé et qu’il est dans un état cohérent…
C’est tout ?
Non bien sur. Ca c’est ce que l’on faisait il y a des années. Les fonctionnalités des snapshots ont quand même bien évolués. Avant, le snapshot était en lecture seul. Maintenant, il est possible d’écrire dessus, comme on le ferai avec un système de fichier normal.
Imaginons que vous voulez lancer plusieurs machines virtuelles sur votre serveur. Chaque machine virtuelle aura le même OS et donc globalement les mêmes données. Seul quelques détails (adresse IP, un ou deux logiciels installés ou non etc) seront différent d’une machine à l’autre. Si on à 8 machines virtuelles, ce serait dommage de devoir allouer 8 fois 10 Go d’espace disque par exemple, alors que 99% des données seront identiques sur les 8 machines. Dans ce cas, on peut créer un volume principal de 10 Go, installer une version basique de l’OS et des applications communes. Ensuite on va créer des snapshots en lecture/écritures, en attribuant à chaque snapshot qu’une toute petite quantité d’espace disque, correspondant à la quantité d’espace qui risque de varier par rapport au volume original. Par exemple 1 Go. Au total on aura donc utilisé 10 + 7×1 = 17 Go d’espace, au lieu de 10*10 = 100 Go.
Bien sur, ce n’est qu’un exemple, et dans ce genre de cas, de la para-virtualisation serait encore bien plus efficace mais… C’est juste pour vous donner une idée de ce qu’on peut faire avec des snapshots 🙂
Autre chose bien sympathique, il est théoriquement possible, depuis le noyau 2.6.33, de faire un retour arrière (rollback) sur un snapshot. Cela peut par exemple permettre de faire des tests avec un retour arrière possible.
Le principe est le suivant :
- On crée un snapshot
- On fait son test (applications de patchs, mise à jour d’une application…)
Soit tout fonctionne parfaitement, et on détruit le snapshot Soit, c’est une catastrophe, et on veut revenir à la situation initial, celle qui existait au moment de la création du snapshot.
Une commande permet alors de retrouver le système tel qu’il était à ce moment la. N’ayant pas de serveur de test avec le bon niveau de noyau, je n’ai pas encore pu tester cette fonctionnalité. Plus tard sans doute 🙂
