eXo Community ou la sauvegarde en 6 minutes !

Les bases du backup d’eXo Platform

La sauvegarde régulière de votre instance eXo Platform est un point indispensable pour assurer la pérennité de vos données en cas d’incident. La page Backup and Restore vous explique comment mettre en place une sauvegarde efficace de votre instance.

Prenons l’exemple d’une installation classique d’eXo Platform, les étapes pour effectuer la sauvegarde sont les suivantes :

• Stopper eXo Platform;
• Sauvegarder le répertoire EXO_DATA_DIR;
• Effectuer un dump sql de la base données;
• Relancer eXo Platform.

Cette procédure a l’avantage d’être facilement implémentable quelle que soit l’architecture en place mais est dépendante du volume de données à sauvegarder.
L’évolution dans le temps de vos durées de sauvegarde et de restauration pourrait alors fortement ressembler au graphique suivant :

Selon vos engagements en terme de disponibilité, la durée d’interruption peut vite devenir problématique pour une sauvegarde régulière.

Que faire lorsque le volume de données augmente ?

Chaque installation étant différente, il n’existe pas un moyen unique pour améliorer vos sauvegardes, mais autant que d’installations. [Appel à un consultant en cas de besoin ? ;)]

Dans la suite de cet article nous allons aborder comment nous avons résolu ce problème sur la Tribe eXo.
Ce site communautaire permet à qui le souhaite de tester et d’échanger autour des fonctionnalités d’eXo Platform. Les employés d’eXo Platform l’utilisent également dans le cadre de leur travail quotidien car nous sommes adeptes du dogfooding.
L’accroissement du nombre d’utilisateurs enregistrés (environ 90 000 aujourd’hui) entraîne une augmentation constante du volume de données à sauvegarder.
La durée de sauvegarde a ainsi pu prendre jusqu’à 3 heures et la restauration plus d’une journée, délais peu compatibles avec nos engagements de service.

Cela nous a obligé à revoir notre stratégie de sauvegardes.

L’infrastructure (simplifiée) utilisée est la suivante:

• Infrastructure mono serveur Linux;
• Base de données MySQL;
• Documents sur disque.

Changer de stratégie

Les bases de données supportées par eXo Platform possèdent toutes une section relative à la sauvegarde dans leur documentation :

• MySQL : http://dev.mysql.com/doc/refman/5.7/en/backup-and-recovery.html
• PostreSQL : https://www.postgresql.org/docs/9.1/static/backup.html
• Oracle : http://docs.oracle.com/database/121/BRADV/toc.htm
• SQLServer : https://msdn.microsoft.com/en-us/library/ms187510.aspx

La méthode choisie dépendra de votre architecture et de vos priorités.

Pour MySQL, le tableau suivant résume les différentes possibilités :

Pour eXo Tribe, notre priorité étant de minimiser le délai d’interruption ainsi que le temps de restauration, la combinaison Physique/Online/Snapshot est idéale.

Le snapshot permettant de garder une image d’un système de fichier prise à un instant T tout en autorisant sa modification en parallèle, nous pouvons alors effectuer la sauvegarde de la manière suivante :

• Arrêt d’eXo Platform;
• Snapshot de la base de données et des données d’eXo Platform;
• Redémarrage d’eXo Platform;
• Copie et sauvegarde des données depuis le snapshot;
• Suppression du snapshot.

L’implémentation

Puisque chez eXo Platform, LVM (Logical Volume Manager) est utilisé sur l’ensemble de nos serveurs pour gérer nos volumes disques, nous l’avons naturellement choisi pour la gestion des snapshots.

La commande lvscan permet d’afficher les volumes logiques d’un système :

# lvscan
...
  ACTIVE            '/dev/vg/lvsrv' [1.64 TiB] inherit
...

Dans notre cas, nous souhaitons effectuer un snapshot du volume /dev/vg/lvsrv.
Sa création sera instantanée mais il faudra réserver un espace au moins aussi important que la taille des écritures qui seront faites pendant son existence. Si cet espace venait à être insuffisant, LVM détruira le snapshot afin de ne pas pénaliser le volume principal.
La commande pvscan permet de vérifier l’espace disponible :

# pvscan
  PV /dev/sda5   VG vg   lvm2 [2.00 TiB / 300.00 GiB free]
  Total: 1 [2.00 TiB] / in use: 1 [2.00 TiB] / in no VG: 0 [0   ]

Il reste ici 300Go d’espace libre sur notre volume. Nous réserverons une taille empirique de 200Go ce qui devrait être suffisant par rapport à l’activité qui aura lieu pendant le temps de copie des données.

# sudo lvcreate -s -L 200G -n lvsrv-snapshot /dev/vg/lvsrv
  Logical volume "srv-snapshot" created

Si nous affichons de nouveau la liste des volumes, nous constatons l’apparition du volume de snapshot /dev/vg/srv-snapshot :

# lvscan
  ACTIVE   Original '/dev/vg/lvsrv' [1.64 TiB] inherit
  ACTIVE   Snapshot '/dev/vg/lvsrv-snapshot' [200.00 GiB] inherit

Il peut être utilisé comme un volume LVM classique, il nous donnera alors accès aux données du volume lvsrv au moment de la création du snapshot. Nous l’utiliserons en lecture seule afin de s’assurer que les données ne puissent être modifiées :

# mkdir /mnt/srv-snapshot
# mount -o ro /dev/vg/lvsrv-snapshot /mnt/srv-snapshot

Pour vérifier à tout moment la consommation de l’espace réservé, nous utiliserons la commande lvs :

# lvs
  LV             VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
  lvsrv          vg   owi-aos--   1.64t
  lvsrv-snapshot vg   swi-aos-- 200.00g      lvsrv    2.39

2.39% des 200G alloués sont utilisés, cela nous permet de sauvegarder les données sans risque de suppression du snapshot.

Les snapshots et MySQL

Avant de créer le snapshot, nous devons nous assurer que MySQL ait bien persisté sur le disque toutes ses données en mémoire. En procédant ainsi, nous pouvons éviter un redémarrage de la base de données et s’affranchir d’un rechargement des données depuis le disque.
Il faut également s’assurer qu’aucune écriture ne sera faite au moment de la création du snapshot (warm backup). Les instructions suivantes permettent cela :

# Ecriture sur le disque et vérouillage
FLUSH TABLES WITH READ LOCK;
# Dévérouillage
UNLOCK TABLES;

Point important, la session ayant servi à créer le verrou doit être maintenue ouverte pendant la création du snapshot sinon le verrou sera supprimé. Dans le cadre d’une sauvegarde automatique, l’utilisation d’un tube nommé (ou named pipe) permet de résoudre ce point :

# Prepare les instructions sql
cat << EOF > ${LOCK_CMD}
SET AUTOCOMMIT=false;
FLUSH TABLES WITH READ LOCK;
EOF

cat << EOF > ${UNLOCK_CMD}
UNLOCK TABLES;
EXIT;
EOF

# Création du tube nommé
mkfifo ${PIPE_PATH}

# Création de la connection à mysql
# Elle restera active pendant la crèation du snapshot
# pour éviter la suppression du verrou
cat ${PIPE_PATH} | mysql &

# Vérouillage des tables
cat ${LOCK_CMD} > ${PIPE_PATH}

# Création du snapshot
…

# Déverouillage des tables et fermeture de la session
cat ${UNLOCK_CMD} > ${PIPE_PATH}

Redémarrage d’eXo platform et copie des données

Une fois le snapshot créé, le service peut être redémarré et la copie des données effectuée.

Les prochaines étapes seront:

• Copie du répertoire de données mysql;
• Copie des données d’eXo Platform;
• Démontage du snapshot;
• Suppression du snapshot.

Et voilà ! La sauvegarde est maintenant terminée ! Le travail de copie se faisant maintenant en arrière plan, application démarrée, le temps d’interruption se réduit au temps de redémarrage du service quelque soit la taille des données à sauvegarder.

Pour la Tribe eXo, cela représente environ 6 minutes. Des améliorations arriveront dans la prochaine version 4.4 d’eXo Platform qui devraient permettre de réduire encore ce délai.

D’ici là, s’il vous arrive d’être dirigé vers la page de maintenance du site vers 05:00 UTC, patientez, le service ne tardera pas à être rétabli.