Written by Cyril

Hier vers 12h40, une erreur humaine nous a fait perdre un petit nombre de bases de données clients. Nous avons été contraints de restaurer les bases concernées à partir des dernières sauvegardes. Tous les clients concernés ont reçu un email indiquant les bases touchées ainsi que la date de la sauvegarde précédente utilisée. Nous vous présentons nos plus sincères excuses, et revenons en détail dans ce billet sur ce qui s’est passé, ainsi que les mesures que nous allons prendre pour éviter que cela ne se reproduise à nouveau.

Ce qui s’est passé

Une commande de suppression (rm ‑fr) a été exécutée sur le serveur de production alors qu’elle était destinée à un serveur de développement. Cette commande a eu le temps de tourner environ une seconde avant d’être arrêtée, mais cela a suffi à supprimer une partie des bases de données. Nous avons alors immédiatement commencé à faire la liste des bases disparues. Une fois cette liste obtenue, nous avons recréé les bases à partir des dernières sauvegardes (effectuées chaque jour).

Et la redondance ?

Comme vous le savez, nos serveurs sont systématiquement redondés dans un second datacenter. Mais ce mécanisme n’est utile que lors des pannes de serveur ou de datacenter, pas pour les erreurs humaines. La synchronisation entre les datacenters se fait en temps réel, et les données modifiées sont immédiatement répercutées sur le serveur de secours.

Sitôt un fichier supprimé sur le serveur principal, il l’est également sur le serveur secondaire. Ce dernier ne nous est donc d’aucune aide dans ce cas précis, et seules les sauvegardes régulières peuvent nous aider à récupérer une version précédente des bases et fichiers.

Comment éviter un nouvel incident ?

Disons-le tout de suite : on ne pourra jamais exclure complètement l’erreur humaine, et cet incident n’a pas pour origine une négligence particulière de notre côté. Mais ça ne veut pas dire qu’on ne va rien faire suite à cet incident.

Il y a deux axes sur lesquels nous allons travailler : comment éviter une nouvelle erreur humaine, et comment être mieux préparé si elle devait se reproduire.

Éviter l’erreur humaine

À nouveau, il y a deux composantes pour atteindre cet objectif : par la technique, et par la prévention humaine.

Techniquement, nous allons réfléchir à mettre en place :

• un système de protection des suppressions sur les serveurs en production. safe-rm pourrait être une première solution ;
• un système de distinction visuelle (par exemple, des prompts de couleur différente) entre les serveurs en production et les autres.

Humainement, nous allons réfléchir à édicter des règles d’utilisation pour limiter les risques, par exemple :

• se déconnecter systématiquement d’un serveur en production une fois qu’on a effectué ce qu’on avait à faire dessus, pour éviter qu’une session inutile ne reste ouverte ;
• si on doit malgré tout garder une session ouverte, s’obliger à différencier le terminal, par exemple en évitant de rester sur le shell mais en démarrant une commande de type top ou nano.

Se préparer au pire

Une fois les fichiers supprimés, nous avons dû travailler à restaurer au plus vite les bases de données perdues. Une telle suppression sauvage des fichiers internes aux bases de données rend MySQL et PostgreSQL instables, et nous avons donc dû nous hâter de faire des tests sur un serveur temporaire pour s’assurer de la marche à suivre.

Par ailleurs, nous n’avions aucune méthode éprouvée pour détecter les bases supprimées puis réinstaller les dernières sauvegardes. Ce n’était pas très compliqué, mais cela a nécessité l’écriture de scripts et de tests pour s’assurer du bon fonctionnement de la procédure. C’est seulement ensuite que nous avons pu restaurer pour de bon les bases supprimées, d’où environ 2 heures de délai entre la suppression des fichiers et la restauration effective des bases.

Nous avons décidé il y a quelques semaines de lancer un programme de simulation des différents problèmes possibles sur notre architecture (panne de machine/réseau/datacenter, pénétration de nos systèmes, suppression de données). Ce n’est pas encore en place parce qu’il y a tout un travail technique en amont pour pouvoir dupliquer un serveur de production et y faire des simulations, mais cet incident nous montre une fois de plus l’intérêt d’être préparé à de multiples scénarios catastrophe.

Par ailleurs, nous sommes en train de travailler sur un nouveau système de redondance. Rien n’est encore fait, nous en sommes encore au stade de l’expérimentation, mais ce système pourrait nous permettre de faire des « snapshots » réguliers (par exemple, toutes les heures) de l’intégralité de nos données. S’il avait été en place, ce système nous aurait permis non pas de partir sur des sauvegardes datant de plusieures heures, mais maximum d’une heure. Nous aurons l’occasion de faire un billet à ce sujet si ce système se concrétise.

Ce qui a bien fonctionné

Terminons sur une note positive : nous pouvons relever que notre politique de communication en temps réel et de transparence, via notre compte Twitter, fonctionne bien en cas d’incident. Il faudrait encore l’améliorer en affichant, dans l’administration alwaysdata et sur notre forum, les incidents en cours (tout le monde n’est pas sur Twitter). Nous avons également pu contacter personnellement chacun de nos clients par email en leur indiquant précisément les bases touchées et la date de dernière restauration.

En outre, les sauvegardes ont été d’une grande utilité. Ce n’est pas une surprise, et chacun peut d’ailleurs accéder librement à ses sauvegardes via un répertoire de son compte. Mais c’était la première fois qu’elles ont été utilisées à grande échelle.

Pour conclure, j’aimerais présenter une nouvelle fois toutes nos excuses au nom de l’équipe alwaysdata pour ce malheureux incident. Merci à tous les messages d’encouragement que nous avons reçus, ils sont toujours très appréciés, a fortiori en situation de crise.