Pense-bête à moi-même : toujours vérifier ses sauvegardes.
La semaine dernière m’est arrivé une drôle d’aventure. Un petit grain de sable qui grippe une mécanique que l’on pensait bien huilée. Une succession de petits dysfonctionnements qui peuvent générer de gros soucis.
Des problèmes en chaîne
Ce vendredi matin, je devais intervenir sur une base de données (une migration de site web avec des changements d’URLs à réaliser directement en BDD). Par sécurité, avant toute opération sur les données, je réalise une sauvegarde de la base de données actuelles. Je procède à l’export des données et les modifie. Je supprime alors les données de la base et réimporte les données mises à jour.
Et là patatra. L’import est corrompu. Pas grave, me dis-je, je réimporte ma sauvegarde faite quelques minutes auparavant. Cette dernière ne fonctionne pas non plus.
Je me dirige alors vers mes sauvegardes automatiques : j’ai automatisé une sauvegarde dans la nuit du jeudi au vendredi. Je constate dépité que la sauvegarde ne s’est pas faite… je commence à stresser. Je trouve une sauvegarde valide à J-1. Au pire j’ai perdu 1 jour de travail.
3 sauvegardes à la suite qui ne marchent pas, c’est mon record.
Ce qu’il s’est réellement passé
- Jeudi soir (la veille donc), un utilisateur FTP a tenté d’envoyer de très très gros fichiers et a saturé l’hébergement. Comme l’hébergement était saturé, la sauvegarde automatique n’a pas pu se faire (plus de place).
- Un bug dans MySql est apparu lors de l’export manuel de PhpMyAdmin du vendredi matin : Le support de l’hébergeur botte en touche et constate en effet le souci. Les mêmes tests dans l’après-midi du vendredi avec le support technique montre que l’erreur est résolue. Le technicien me dit que parfois ça arrive et qu’on ne comprend pas toujours. Après investigation par le support, un conflit lors de l’import de la base en format GZIP est apparu avec la variable max_allowed_packet.
- Un bug dans ma config (navigateur ou OS) corrompt les exports PhpMyAdmin. Lors de mes tests avec le technicien, nous nous apercevons que les exports SQL fonctionnent alors que les exports .gz sont corrompus chez moi. Du côté du technicien, tout est OK. Et chez moi, ça plante. La veille ça marchait. Depuis ça ne marche plus… bizarre.
La leçon à retenir
Je pensais avoir bien balisé le chemin avec une sauvegarde automatique et une sauvegarde manuelle. Et pourtant ça n’a pas suffit.
Comme quoi, il faut toujours vérifier ses sauvegardes…
Photo : GotCredit
Tout à fait d’accord avec vous, une sauvegarde non testée ne vaut rien :o)
Comme dit dans cet article il y a eu un mauvais concours de circonstance … Toutefois, je conseille de toujours tester les sauvegarde en la restaurant avant d’effacer la base originale…. sinon oui c’est la cata :o)
Depuis 25 ans, je travaille dans une SSII et au cours de ma carrière, il m’est arrivé de piloter des projets en centre de services. Normalement, nous pourrions penser que nous sommes dans un cadre de professionnels de l’informatique et pourtant !
En effet, dans ma liste des contrôles à effectuer durant la vie d’un projet, j’ai une action de contrôle des sauvegardes/restauration qui m’a permis de détecter une fois que le robot de sauvegarde sur cassette demandait tous les jours une 2ième cassette, car l’espace disponible était insuffisant. Donc, avec l’ingénieur système, nous avons pu constater que le processus de sauvegarde n’était pas fiable.
Et une autre fois, le PRA était possible, mais seulement après un délai d’une semaine le temps de réinstaller le système et les applications.
Actuellement, j’évolue dans une assurance et lorsque l’ingénierie système a annoncé en comité de pilotage que le projet était de risque R2 et que le protocole prévoit une interruption de services d’une journée par an pour simuler un PRA en production, je peux vous assurer qu’il a fallu être diplomate pour expliquer l’importance de l’action
C’est sûr que c’est un réflexe qui se développe avec l’expérience. Je fais toujours des dump « au cas ou ». Certains hébergeurs web sont vraiment instables pour importer ou exporter une BDD.