Proxmox 2/3 : outil de sauvegarde incrémentale pour containers OpenVZ

EDIT 1 : Après plusieurs mois de gestation le projet est désormais disponible ici :

La doc est sera bientôt disponible, ainsi qu’un forum pour les retours d’expérience.

EDIT 2 : Openvz-diff-backups fonctionne avec Debian 6/7 + OpenVZ et/ou Proxmox 2 & 3.

EDIT 3 : L’outil de backup ayant énormément évolué (euphémisme), ce billet est complètement « outdated ».

« Boarf… Un bon gros tar.gz de 137 Go, ça n’a jamais tué personne… » (Patrice B., réfractaire aux backups journaliers)

Avant, j’utilisais vzdump et mes cheveux backups étaient gras

Faire des sauvegardes c’est bien, les répliquer sur un serveur distant c’est mieux.

Sauf que, si vous vous amusez chaque jour à transférer les archives générés par vzdump, à mon avis ça va mal se mettre au niveau de la bande passante (sans parler de l’espace disque nécessaire pour conserver un historique décent).

Pour l’instant ma nobox ne contient que 50 Go de données (libres, toussa…) mais vu l’upload tout moisi que l’on a derrière une misérable ligne ADSL et le fait que je voulais quand même disposer d’une sauvegarde distante et journalière, fallait bien trouver autre chose que le transfert des tar.gz classiques.

Maintenant, j’utilise rsync et mon delta est resplendissant

Bon, ok, même si dans la pratique cette affirmation est globalement vraie (si, si…), il y a certains cas « particuliers » où cela ne se passe pas aussi bien. (Ben tiens ! On s’en serait pas douté…)

A chaque appel du script de sauvegarde, celui-ci va faire sa tambouille puis, afin de créer un historique, stocker dans un nouveau répertoire les différences par rapport à l’ancien backup.

L’archivage se fait à l’aide de liens hard en utilisant la directive « –link-dest » de rsync. Le principal avantage de cette méthode, contrairement à « cp -al », est que les changements de propriétaires ou de permissions sont pris en en compte sans impacter rétroactivement les anciennes sauvegardes.

Donc, en français dans le texte, cela signifie que, dès qu’une modification est détectée sur un fichier (taille, données, permissions, etc), rsync ne va pas créer un hard link lors de l’archivage mais tout simplement copier intégralement le fichier modifié.

Étant donné qu’il s’agit du comportement attendu et souhaité, jusqu’ici tout va bien.

M’ouais… J’ai testé en prod (sic) et mon delta est tout pourrave

Là où ça devient un peu moins drôle, c’est lorsque vous utilisez, par exemple, MySQL et notamment le format InnoDB. Par défaut, toutes les bases de données sont stockées dans un seul et même fichier (au hasard, ibdata1 en autoextend).

Bilan des courses, au moindre changement dudit fichier et donc à chaque nouvelle sauvegarde via le script, rsync va considérer que le fichier a changé (logique) et fera alors une nouvelle copie complète (pas glop).

Si votre fichier ibata1 pèse au doigt mouillé 14 Go, ben… Le delta, vous pouvez vous le mettre au fond à gauche (et merci d’éteindre la lumière en sortant).

Il est cependant possible de limiter la casse en utilisant la directive innodb_file_per_table afin de séparer les différentes tables dans des fichiers distincts. Du coup, seules les tables réellement modifiées vont impacter le delta.

Fonctionnement du script « task_backup-openvz-container »

Concernant le nom, oui, je sais, il est d’une platitude affligeante mais bon, au moins on sait ce qu’il fait.

Bien. Voyons maintenant comment fonctionne le script :

1/10) Vérifications diverses et variées

Avant de s’exécuter, le script de sauvegarde va vérifier un minimum de choses :

  • présence d’arguments (CTID, paramètres optionnels)
  • présence de rsync, ionice & bzip2
  • existence du répertoire où sont stockés les containers OpenVZ (/var/lib/vz/private/)
  • existence du répertoire de sauvegarde (/home/backup/<nom de la machine>/openvz/)
  • vérification du fichier de configuration principal (/etc/vz/conf/<CTID>.conf)
  • status du container Openvz (exist, mounted, running)

2/10) Sauvegarde des fichiers de configuration du container OpenVZ

Généralement situés dans « /etc/vz/conf/ », le script va sauvegarder les différents fichiers de configuration associés au container OpenVZ.

Si le CTID du container est par exemple 100, les fichiers (s’ils existent) 100.conf, 100.start, 100.stop, 100.mount, 100.umout, 100.premount et 100.postumount seront archivés.

3/10) Synchronisation initiale (lent)

Avant de suspendre temporairement le container OpenVZ, le script va d’abord dégrossir le travail en effectuant une première synchronisation avec rsync : tous les fichiers du container vont être copiés vers le répertoire de sauvegarde à la vitesse phénoménale de 2 mo/seconde. (Modifiez le paramètre « RSYNC_BACKUP_SPEED » dans le fichier de conf si vous voulez accélérer la cadence)

Donc, la première fois que vous allez lancer le script de sauvegarde, cette étape va être relativement longue. Et si vous activez le mode « very verbose », vous pourrez voir l’avancement de cette étape au lieu de glander bêtement.

Ensuite, et si le container est inactif, le script passe directement à l’étape 10/10.

4/10) Seconde synchronisation (rapide)

Toujours avant de suspendre le container, le script effectue une seconde synchronisation avec rsync mais cette fois le plus rapidement possible afin de réduire au maximum le nombre de fichiers restants à synchroniser lors de l’étape 6/10.

5/10) Mise en pause du container OpenVZ (suspend)

L’exécution du container Openvz est suspendue à l’aide de la commande « vzctl chkpnt CTID –suspend ».

A partir de cet instant, tout est figé : fichiers, connexions réseau, état de la mémoire, sockets, etc. Le container n’est pas stoppé mais simplement « gelé ».

6/10) Synchronisation finale (rapide)

Le plus gros du travail ayant été fait avant, cette étape ne dure que quelques secondes, les derniers fichiers « récalcitrants » seront alors synchronisés le plus vite possible.

7/10) Sauvegarde de la mémoire du container OpenVZ (checkpointing)

L’état de la mémoire utilisée par le container est sauvegardé via la commande « vzctl chkpnt CTID –dump ».

Cette étape est très importante, notamment dans le cas d’utilisation de programmes (comme les SGBD) qui stockent en mémoire les données « chaudes » et/ou utilisent des systèmes de cache.

Si par la suite vous restauriez un container seulement à partir de ses fichiers, donc sans réinjecter l’état de la mémoire, vous risquez tout simplement la corruption de données.

8/10) Reprise d’activité du container OpenVZ (resume)

Une fois les fichiers et la mémoire sauvegardés, le container est « dégelé » avec « vzctl chkpnt CTID –resume »

Le nombre de secondes pendant lequel le container a été suspendu sera affiché.

9/10) Compression de l’image mémoire

Afin de gagner de l’espace, le dump de la mémoire du container est compressé avec bzip2 avant d’être archivé dans le répertoire adéquat. Le taux de compression est généralement très bon, entre 80% et 90%.

10/10) Création d’un point d’archive

Étape finale, les fichiers du container sont archivés dans un sous-répertoire à l’aide de rsync et de l’option « –link-dest ».

Et voilà ! C’est fini. 🙂

Paramétrage du script de sauvegarde

Tous les paramètres importants sont modifiables dans le fichier de configuration « openvz-diff-backups.conf ».

Sur une install classique de Proxmox les valeurs par défaut sont bonne mais, en fonction de votre configuration, pensez à ajuster certains paramètres :

CONFIG_DIR="/etc/vz/conf"

Répertoire où sont stockés les fichiers de configuration des containers OpenVZ

OPENVZ_DIR="/var/lib/vz/private"

Répertoire où sont stockés les fichiers des containers OpenVZ.

BACKUP_DIR="/home/backup/$SCRIPT_HOST/openvz"

Répertoire où seront stockés les backups : la variable $SCRIPT_HOST correspondant au nom de la machine hôte.

Donc si votre machine se nomme « www.mon-serveur.lan », alors le répertoire de sauvegarde sera « /home/backup/www.mon-serveur.lan/openvz/ ».

Pour plus d’infos sur les autres paramètres, voyez la documentation.

Description des fichiers et répertoires obtenus

Par défaut, le répertoire de sauvegarde est « /home/backup/<nom de la machine>/openvz/ » mais vous pouvez le changer en modifiant la variable « $BACKUP_DIR ».

Structure des sous-répertoires

Pour chaque container OpenVZ sauvegardé avec le script, différents sous-répertoires vont être créés :
(le CTID correspond à l’ID du container sauvegardé)

$BACKUP_DIR/CTID/conf/

Répertoire où sont stockés les fichiers de configuration du container OpenVZ (.conf, .mount, .umount, etc)

$BACKUP_DIR/CTID/dump/

Répertoire où sont stockées les images mémoire (compressées) du container OpenVZ

$BACKUP_DIR/CTID/private

Répertoire où sont stockés les archives des fichiers du container.

Au sein de ce répertoire vous allez trouver le sous répertoire « current » (utilisé pour les différentes synchro avec rsync) et à chaque nouveau backup, des sous-répertoires nommées « diff-YYYY-MM-JJ_HH-MM-SS ».

N’utilisez jamais le répertoire « current » pour restaurer un container car rien ne garantit que les données présentes à l’intérieur soient fiables.

Horodatage des sauvegardes

A chaque nouvelle sauvegarde, la date ainsi que l’heure sont utilisés pour horodater les fichiers et répertoires créés.

Donc, si vous effectuez un backup, le 12 juillet 2012 à 20 heures 59 minutes et 14 secondes, du container OpenVZ ayant l’ID 100, voici ce que vous allez trouver :

# Fichier de configuration
$BACKUP_DIR/100/conf/100_2012_07_12-20-59-14.conf

# Image mémoire (compressée)
$BACKUP_DIR/100/dump/100_2012_07_12-20-59-14.dump.bz2

# Racine des fichiers du container
$BACKUP_DIR/100/private/diff_2012_07_12-20-59-14/

Voilà, fin de l’histoire ! Il y a tout ce qu’il faut pour restaurer ou migrer le container vers un autre serveur.

Disclaimer, warnings en tout genre et précautions d’usage

Le script nécessitant d’être exécuté sous l’utilisateur root, je ne vous fais pas un dessin concernant les conséquences désastreuses si quelque chose se passait mal…

Donc, et même si je pense avoir pris toutes les précautions nécessaires afin que le script ne puisse pas causer de dommages, je vous invite à faire deux petites choses avant de l’utiliser :

  1. Sauvegardez vos containers OpenVZ avec vzdump et placez les archives sur un autre disque/serveur
  2. Prenez le temps de lire le code source ! Il est court (~ 4500 lignes en tout) et donc simple à comprendre

De mon côté, tout se passe gentiment : tous les containers OpenVZ sont sauvegardés 4 fois par jour avec une tâche cron, le delta est acceptable et je peux donc répliquer les backups sur un serveur distant sans pourrir ma bande passante.

Questions, suggestions, insultes et règlements de compte

Les scripts sont  publiés sous la licence GPL v3 (what else ?), libre à vous d’en faire bon usage.

Si vous avez des questions, n’hésitez pas ! 😉

A+

Il y a 8 commentaires de gens bizarres, ce sont sûrement des drogués

Oui Jean-Pierre, je souhaite publier un commentaire assassin sur ce blog minable

(Votre adresse email ne sera jamais publiée, divulguée, revendue, broyée, atomisée, etc.)