Intéressons nous un peu à la manière dont on gère concrètement les
transferts et les sauvegardes de jails sous FreeBSD. Il y a un avant et
un après ZFS, mais dans les deux cas, j’utilise le très pratique
ezjail
pour créer et administrer les jails. Il contient même une option pour
que les jails sous ZFS se créent automatiquement dans un nouveau système
de fichiers séparé.
Sans ZFS
J’utilise une partition
UFS2
avec les soft
updates activés
que je monte en /usr/jails. J’utilise ensuite le vieux mais très
performant couple dump/restore sur un snapshot de cette partition.
L’option -L de dump pourrait automatiser le snapshot, mais il se trouve
que l’idée est de minimiser l’arrêt des jails et que dump n’indique pas
de manière précise le moment où le snapshot est terminé. La séquence est
donc la suivante :
:::shell
ezjail-admin stop
time mksnap_ffs /usr/jails /usr/jails/.snap/2012.MM.JJ #(compter 4 à 20mn pour 10Go en fonction du nombre de snapshots déjà présents)
ezjail-admin start
mdconfig -a -t vnode -f /usr/jails/.snap/2012.MM.JJ -u 4
time dump -0auf /media/backup/2012.MM.JJ.dump /dev/md4 #(compter 1h30 pour 10Go)
mdconfig -d -u 4
Le mieux est de commencer par supprimer les snapshots précédents, car
cela joue un rôle très important pour minimiser le temps d’arrêt des
jails durant la création du snapshot.
Pour transférer les jails sur un autre serveur, il faut y copier le
fichier, puis formater la partition où l’on placera les jails et la
monter. Enfin, on lance :
cd /usr/jails restore -r -f /media/backup/2012.MM.JJ.dump
Si on veut ne restaurer qu’une jail, on utilise :
restore -f /media/backup/2012.MM.JJ.dump -x prison1 Specify volume? 1 Set owner mode? y
Ce qui est évidemment très appréciable est l’utilisation du snapshot :
4mn d’arrêt pour mon serveur domestique, cela reste vraiment très
acceptable. Alors que si j’archivais directement avec tar ou dump, il
faudrait plus d’une heure et demie d’arrêt des jails.
Ce qui est un peu pénible, c’est qu’il faut transférer ce gros fichier
vers le serveur et le restaurer, mais les niveaux de dump permettent
d’alléger l’opération et de faire des sauvegardes incrémentielles avec
une commande de type :
:::shell
time dump -1auf /media/backup/2012.MM.J1.dump /dev/md4
time dump -2auf /media/backup/2012.MM.J2.dump /dev/md4 etc.
Il est vrai qu’il faut être bien organisé et méthodique pour ne pas
faire de bêtises et mélanger les différents niveaux de dump sur le
serveur de sauvegarde.
Avec ZFS
Le principe est un peu différent et encore plus performant. Mes jails
sont dans un pool nommé prison. Elles se situent dans prison/jails et
sont montées sur /usr/jails
- Chaque jail est sur son propre système de fichiers : il n’est donc
pas nécessaire de faire un snapshot de l’ensemble des jails ; on peut
n’arrêter qu’une jail et la transférer. Ceci dit, vu la rapidité et
la performance du système de fichiers, je n’utilise même pas cette
possibilité pour l’instant.
- Les snapshots sont réellement instantanés – quel que soit le nombre
de snapshots déjà existants. Comme j’arrête quand même les jails (la
cohérence des données est pour moi plus importante qu’une toute
petite interruption de service), le temps d’arrêt des jails tient
simplement au temps d’exécution du script d’arrêt et de
démarrage d’ezjail.
- L’envoi des données modifiées depuis la dernière sauvegarde vers un
fichier ou vers un serveur est vraiment très rapide et facile.
Cela donne concrètement la séquence suivante :
:::shell
ezjail-admin stop
zfs snapshot -r prison/jails@2012.MM.J1
ezjail-admin start
On peut envoyer vers un serveur via ssh un flux complet ou les
modifications effectuées depuis la dernière sauvegarde : dans ce dernier
cas, l’avantage par rapport aux niveaux de dump des snapshots d’UFS2,
c’est que le système signalera toute erreur dans l’ordre des snapshots
importés.
:::shell
zfs send -R prison/jails@2012.MM.J1 | ssh adresse.de.mon.serveur zfs recv prison/jails
zfs send -Ri prison/jails@2012.MM.J0 prison/jails@2012.MM.J1 | ssh adresse.de.mon.serveur zfs recv -F prison/jails
On peut aussi envoyer les données – complètes ou incrémentielles – vers
des fichiers de sauvegarde. Vu la rapidité de l’opération, je les
compresse systématiquement :
:::shell
zfs send -R prison/jails@2012.MM.J1 | gzip > /media/backup/2012.MM.J1.zfs.gzip
zfs send -Ri prison/jails@2012.MM.J0 prison/jails@2012.MM.J1 | gzip > /media/backup/2012.MM.J1-diff-2012.MM.J0.zfs.gzip
Quelques chiffres pour donner une idée des choses, toujours avec des
jails d’environ 10Go en tout :
- 0.013s pour créer le snapshot – à comparer aux 4mn sous UFS2
- 20mn pour créer un fichier de sauvegarde complète sans compression –
à comparer à 1h30 sous UFS2
- 40mn pour créer le même fichier compressé en gzip
- 5 à 8 mn pour une sauvegarde incrémentielle d’environ 450Mo, que ce
soit vers un serveur ou vers un fichier
Par sa souplesse et sa rapidité, ZFS est donc remarquablement bien
adapté à la sauvegarde et au transfert des jails et permet d’optimiser
encore ce qui marchait déjà bien sous UFS2.