Skyduino:~#
Articles
tutoriel

[Mémo du sysadmin] Les sauvegardes et Backup-Manager

Bonjour tout le monde !

Ce n’est pas une surprise pour ceux qui me suivent sur Twitter, pour les autres, bonne nouvelle, depuis lundi je travaille comme un dingue pour mettre en ligne le serveur du site v2.
Le code de la beta du site v2 est fini, le débug aussi. Ne reste donc plus qu’à déployer le tout sur un serveur fraîchement installé.
Et c’est justement en déployant le serveur du site v2 que j’ai fait une découverte pas cool du tout.

TL;DR : Ne faites pas confiance à Backup-Manager pour vos sauvegardes. Du moins, pas avec la configuration et le code fourni dans le paquet Debian.

Parenthèse / hors-sujet

Désolé pour le retard par rapport à la date de mise en ligne que j’avais annoncée sur Twitter.
A l’origine, j’avais prévu de mettre en ligne la beta du site v2 le lundi 1er juin, jour officiel de mon début d’activité professionnelle.
Cependant, à cause d’un bug de dernière minute, d’une série de fichiers HTML vraiment trop moches et d’une série de fichiers de traduction pas traduits, je n’ai pu réellement finir le code que le mercredi 3 juin. Oups.

Relativisons, après deux mois de retard (pour rappel, la beta aurait dû sortir en avril normalement), une semaine du plus ou de moins, c’est plus trop grave 🙂

Mise en situation

Un serveur c’est quoi en réalité ?
Un serveur ce n’est rien de plus qu’une grosse station de travail sans écran, avec un hardware spécialisé pour tourner h24 7/7j sans broncher.
Mais ce qui différencie vraiment un serveur d’une station de travail, c’est les programmes qui tournent dessus.

Pour fonctionner, un service – quel qu’il soit – a besoin de stocker des données. Au minimum, un service demande qu’un fichier de configuration soit présent sur le disque.
Or, qui dit données, dit sauvegarde.
En informatique, il n’y a rien de pire que de perdre des données, surtout sur un serveur.

Anti-oups

Une première protection contre les pertes de données consiste à dupliquer les données sur plusieurs disques. C’est le principe du RAID-1 (et du RAID-5 si vous avez la chance d’avoir une montagne de disques en stock).
Mais même avec un duo de disques en RAID-1, rien n’empêche de perdre des données en cas d’incident majeur. Le jour où les deux disques meurent simultanément, ou qu’un incendie ravage la salle des serveurs, byebye les données.

Quand on fait des sauvegardes, il y a trois règles fondamentales à respecter :

  • Toujours avoir trois copies des données importantes, deux copies ce n’est pas suffisant,
  • Stocker les copies sur (au moins) deux supports de stockage différents,
  • Avoir une des trois copies hors site (un « cold backup » en terme technique).

Mais pourquoi faire tant de vent pour si peu ?

Situation 1 : Vous avez deux copies d’un fichier (exemple: une copie en local sur le serveur et une copie sur disque externe) et une des copies se perd ou se dégrade (disque du serveur HS).
Vous avez à présent une unique copie du fichier, si jamais il lui arrive quelque chose, vous êtes foutu (avec un grand F, comme dans FUCK).

Conclusion : Avec une troisième copie, en cas de problème, vous avez une solution de secours.

Situation 2 : Vous avez trois copies sur un même type de support de stockage.
Je ne vous apprends rien en vous disant que certains supports de stockage sont bien plus adaptés que d’autres pour faire des sauvegardes.
Tous les supports de stockage ont une durée limite de rétention des données. En faisant des sauvegardes sur un seul type de support, on s’expose à de gros problèmes avec le temps.
Outre la perte physique des données avec le temps, il faut aussi prendre en compte l’évolution des supports. Les sauvegardes sur disquettes d’il y a quelques années ne sont aujourd’hui plus utilisables par exemple.
J’imagine bien la tête des personnes ayant fait des sauvegardes sur HD-DVD (un équivalent des Bluray d’aujourd’hui, abandonné en 2008).

Conclusion : toujours faire ses sauvegardes sur plusieurs supports pour ne pas se retrouver avec des backups corrompus par le temps, ou rendus inutilisables par les avancées technologiques.
PS Pour les datacenters, le support de stockage le plus utilisé reste les bandes magnétiques. C’est old-school mais ça ne coûte pas cher, bien conservé c’est indestructible et ça a déjà sauvé des entreprises de la catastrophe (coucou Google).

Situation 3 : Vous avez trois copies, sur au moins deux types de supports différents. Mais ces copies sont toutes dans la même pièce … et pas de bol, un jour un incendie dévaste la pièce en question.
Vous venez de perdre toutes vos données.
En discutant avec des sysadmin professionnels, j’ai eu mainte fois le récit d’entreprises qui avait mal calculé le risque de catastrophe naturelle ou de sinistre. Et qui avait fini en faillite après avoir perdu toutes leurs données comptables et métiers.

Conclusion : toujours avoir une sauvegarde hors site, c’est impératif.
N.B. Même sans parler d’incendie, de chute de météorite, ou de guerre thermonucléaire, un simple voleur qui embarque toute l’informatique suffit à faire des dégâts.

Anti-oups 2 – Le retour

Maintenant que vous avez bien stressé et lancé des sauvegardes de tous les côtés. Surprise ! Il reste deux règles à respecter !
Et malheureusement, ces deux règles-là, on les apprend à la dure. Le jour où vous apprenez ces deux règles, vous pleurez.
Je les ai apprises et croyez-moi, quand vous êtes devant le fait accompli vous l’avez vraiment mauvaise.

Règle n°1 : Vérifier que le script de sauvegarde s’exécute tous les jours.
Ce n’est pas le jour où vous avez besoin d’une sauvegarde qu’il faut découvrir que le script ne s’est jamais exécuté ou qu’il a cessé de s’exécuter il y a plus trois mois.

Toujours vérifier que le script de sauvegarde s’exécute correctement et régulièrement.

Règle n°2 : Vérifier régulièrement l’intégrité des sauvegardes.
Ne pas pouvoir restaurer une sauvegarde à cause d’un script mal configuré, ou pire, d’une sauvegarde corrompue, c’est la catastrophe assurée.
En général sur serveur, on utilise des scripts de sauvegarde dits « incrémentiels », c’est à dire, qui ne sauvegarde que les modifications des fichiers.
Pour restaurer une sauvegarde incrémentielle, il faut deux choses : le fichier de sauvegarde maître (le « master ») et les fichiers de modifications.

Pas de fichier maître = pas de restauration possible.
Pas de fichiers de modifications = restauration possible, mais uniquement à l’état du jour de la création du master.
Comme les fichiers maîtres sont générés en général une fois par semaine, voir une fois par mois. Je vous laisse imaginer le problème en cas de restauration forcée.

Toujours vérifier régulièrement l’intégrité des archives de sauvegarde en essayant de les restaurer en local sur une machine de test.

Quel rapport avec Backup-Manager ?

L’introduction a été un peu longue, je sais, mais une piqûre de rappel ne fait jamais de mal.

Le rapport avec Backup-Manager est simple : Backup-Manager ne permet pas de respecter les deux règles ci-dessus avec sa configuration par défaut.
Pire, un bug dans le code, qui traîne depuis plusieurs années sans correction empêche l’envoi sur un serveur distant des fichiers de modifications !
(la dernière mise à jour de Backup-Manager date d’il y a deux ans, donc pour moi le projet est clairement abandonné)

J’ai découvert le problème en testant le système de sauvegarde du serveur du site v2.

Tout d’abord, j’ai découvert que depuis la version 0.7.9.3, plus aucune tache CRON n’est installée par défaut pour faire les sauvegardes régulièrement.
Oui oui, vous avez bien lu. Par défaut Backup-Manager doit régulièrement être lancé manuellement en root pour faire les sauvegardes !

La solution la plus simple consiste à créer un fichier CRON, avec exécution automatique tous les jours :

sudo -i
cat <<EOT >> /etc/cron.daily/backup-manager
#!/bin/sh
# cron script for backup-manager
test -x /usr/sbin/backup-manager || exit 0
/usr/sbin/backup-manager
EOT

Le second problème est bien plus ennuyeux. Une explication plus détaillée est disponible ici.

Pour faire simple, quand Backup-Manager envoi les fichiers de sauvegarde sur un serveur distant par FTP (et surement aussi par SSH), seuls les fichiers contenant la date du jour sont transmis.
Les autres fichiers sont purement et simplement … ignorés.

Le problème ?
Avec le mode « tarball-incremential » deux fichiers sont générés : le fichier maître (*.master.tar.gz) et les fichiers de modifications (*.incremental.bin)
Les fichiers maîtres ont la date du jour dans leurs noms, ils sont donc envoyés sur le serveur distant.
Les fichiers de modification par contre ont des noms au format « chemin-vers-le-dossier-sauvegade.incremental.bin ». Pas de date, donc pas d’envoi sur le serveur distant.
Le jour où vous avez besoin de faire une restauration avec le backup du jour précédent … vous êtes foutu. Seul le fichier maître datant d’une semaine (ou d’un mois) est disponible sur le serveur distant.

Le quick-fix pour ce problème consiste à envoyer sur le serveur distant tous les fichiers portant l’extension « .incremental.bin ».

Dans « /usr/bin/backup-manager-upload », ligne 203 :

    else {
    	while (<$g_root_dir/*$date*>) {
            push @{$ra_files}, $_;
        }
	}

	return $ra_files;
}
    else {
    	while (<$g_root_dir/*$date*>) {
            push @{$ra_files}, $_;
        }
        while (<$g_root_dir/*incremental*>) {
        push @{$ra_files}, $_;
	}
	}

	return $ra_files;

(Mon Dieu que c’est moche le langage Perl … vive Python !)

Vous êtes maintenant prévenu. Pensez à vérifier vos FTP si vous avez des sauvegardes avec Backup-Manager qui tournent en ce moment.

En attendant, je retourne sur le serveur du site v2. J’ai encore Nginx, Gunicorn, Supervisord et Munin à installer et configurer … la journée va être longue.

Publicités

Discussion

Pas encore de commentaire.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Skyduino devient Carnet du Maker

Le site Carnet du Maker remplace désormais le blog Skyduino pour tout ce qui touche à l'Arduino, l'informatique et au DIY.