La sauvegarde d’un système d’informations est toujours importante. On l’apprend toujours à ses dépends.
Je devais intervenir sur une dedibox pour mettre en place un groupware (eGroupware) afin de lui permettre de proposer à ces étudiants une plate-forme d’échange. Rien de compliqué à cela car la machine était déjà en place (sous Ubuntu, j’aurais préféré un Debian, mais bon…) avec une installation eGroupware qui était presque fonctionnelle. Afin, de ne pas casser l’existant, j’ai décidé de faire une nouvelle installation d’eGroupware en nommant cette nouvelle instance egroupwarenew. L’installation s’est déroulée sans problème. Arrive le moment fatidique de la configuration : la connexion vers la base de données (mySQL) ne se fait pas. Je décide, donc, de dropper la base egroupwarenew que j’avais créée à la main et laisser l’installeur effectuer cette opération. Je me connecte, donc, sur le serveur mysql, je tape “drop database egroupware;” et valide la commande joyeusement en tapant sur la touche “entrée”.
Et là, c’est le drame. L’instance d’eGroupware qui était en place utilisait une base nommée egroupware ; la base que je devais dropper était egroupwarenew. J’ai été incapable de trouver une sauvegarde de la base droppée sur la machine. Pourtant, egroupware propose, en option, une méthode pour effectuer une sauvegarde tous les jours. Malheureusement, cette option ne semblait pas avoir été activé. Après avoir déprimé pendant une demi-heure, j’ai terminé l’installation. Tout semble fonctionner…
Comme je le disais au début de mon poste, les sauvegardes sont importantes qu’on soit un particulier ou professionnel. Dans ma courte vie d’informaticien, j’ai dû faire 3 ou 4 grosses conneries et toutes étaient liées à des suppressions malencontreuse de fichiers.
- La première était une suppression de /etc : un malheureux “rm -rf *” en étant au mauvais endroit. Sur ce coup, j’ai eu de la chance. C’était sur une machine de prod au boulot et on avait une sauvegarde. Le truc à ne pas faire dans le cas de la suppression de /etc/, c’est surtout ne pas se déconnecter et ne pas paniquer (là ce n’est pas dur, je savais que j’avais un backup à jour). Donc, restauration du contenu sur une autre machine (car une fois que /etc n’existe, plus, il n’est plus possible de se connecter, hein) et transférer les données. D’ailleurs, quand il y a un truc marrant avec SSH lorsque le /etc/passwd n’existe plus et qu’on est encore connecté, il passe son temps envoyer des messages du genre “I don’t know you. Go away!“.
- La deuxième série de suppression était moins grave dans la mesure où c’était sur mes machines perso. Un script m’a viré tout mon home directory et un malheureux “rm -rf *” qui entraîné la suppression de la configuration de mon serveur Apache. J’ai pu récupéré mon “home” à partir d’une vieille sauvegarde car jusqu’à ce jour, je m’étais dit que cela n’arrive qu’aux autres. Concernant la config du serveur Apache, ce fût un peu plus compliqué. La configuration de base était simple à récupérer, il suffit de réinstaller les packages (merci Debian). Quant à la récupération des mes virtuelhosts et la configuration spécifique, j’ai eu de la chance, car j’avais activé le handler “server-info” qui liste la configuration du serveur. Ce n’est pas simple de récupérer la config. d’un serveur en partant d’une page html qui regroupe trop d’informations mais c’est quand même plus facile qu’à partir de rien.
- Les 2 autres fois, c’était vraiment débile. Je fais toujours des copies de sauvegarde en utilisant un schéma de nom un peu nul : par exemple, je fais une copie de fichier “index.php” en “index.php-ORI” ou appeler une base “egroupwarenew” alors qu’il existe déjà une base egroupware. Et, à chaque fois, la fatigue aidant, je n’allais pas jusqu’au bout du mot et finis par supprimer le mauvais fichier ou la mauvaise base (comme egroupware ou index.php).
En presque 10 ans, je n’ai pas encore perdu mes données suite à problème matériel. Chaque fois que j’ai perdu des données c’était suite à une suppression
involontaire.
Donc,
- Il faut toujours réfléchir à 2 fois avant de faire des “rm -rf *“.
- Faire une sauvegarde régulièrement. Il existe pleins d’outils pour ça. J’utilise backupninja. Une page wiki du projet Debian en cite d’autres.
- Faire attention de la façon dont on nomme les copies de fichier de sauvegardes. Il vaut mieux faire une copie de fichier “index.php” en “ORI-index.php” plutôt que “index.php-ORI”
EDIT 14/10/2007 à 09h30
- Lorsqu’on accède à une machine pour la première fois, s’assurer qu’elle est bien sauvegardée.
Je viens de tomber sur un
post qui parle aussi de l’importance des sauvegardes. C’est étrange de constater que d’autres font face aux mêmes soucis au même moment…
Tags:
old | Posted on 13/10/2007 at 15:24 by
Glennie Vignarajah |
Permalink |
Comments: 0
