Hier vers 12h40, une erreur humaine nous a fait perdre un petit nombre de bases de donn\u00e9es clients. Nous avons \u00e9t\u00e9 contraints de restaurer les bases concern\u00e9es \u00e0 partir des derni\u00e8res sauvegardes. Tous les clients concern\u00e9s ont re\u00e7u un email indiquant les bases touch\u00e9es ainsi que la date de la sauvegarde pr\u00e9c\u00e9dente utilis\u00e9e. Nous vous pr\u00e9sentons nos plus sinc\u00e8res excuses, et revenons en d\u00e9tail dans ce billet sur ce qui s\u2019est pass\u00e9, ainsi que les mesures que nous allons prendre pour \u00e9viter que cela ne se reproduise \u00e0 nouveau.<\/p>\n
Une commande de suppression (rm \u2011fr) a \u00e9t\u00e9 ex\u00e9cut\u00e9e sur le serveur de production alors qu\u2019elle \u00e9tait destin\u00e9e \u00e0 un serveur de d\u00e9veloppement. Cette commande a eu le temps de tourner environ une seconde avant d\u2019\u00eatre arr\u00eat\u00e9e, mais cela a suffi \u00e0 supprimer une partie des bases de donn\u00e9es. Nous avons alors imm\u00e9diatement commenc\u00e9 \u00e0 faire la liste des bases disparues. Une fois cette liste obtenue, nous avons recr\u00e9\u00e9 les bases \u00e0 partir des derni\u00e8res sauvegardes (effectu\u00e9es chaque jour).<\/p>\n
Comme vous le savez, nos serveurs sont syst\u00e9matiquement redond\u00e9s dans un second datacenter. Mais ce m\u00e9canisme n\u2019est 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\u00e9el, et les donn\u00e9es modifi\u00e9es sont imm\u00e9diatement r\u00e9percut\u00e9es sur le serveur de secours.<\/p>\n
Sit\u00f4t un fichier supprim\u00e9 sur le serveur principal, il l\u2019est \u00e9galement sur le serveur secondaire. Ce dernier ne nous est donc d\u2019aucune aide dans ce cas pr\u00e9cis, et seules les sauvegardes r\u00e9guli\u00e8res peuvent nous aider \u00e0 r\u00e9cup\u00e9rer une version pr\u00e9c\u00e9dente des bases et fichiers.<\/p>\n
Disons-le tout de suite : on ne pourra jamais exclure compl\u00e8tement l\u2019erreur humaine, et cet incident n\u2019a pas pour origine une n\u00e9gligence particuli\u00e8re de notre c\u00f4t\u00e9. Mais \u00e7a ne veut pas dire qu\u2019on ne va rien faire suite \u00e0 cet incident.<\/p>\n
Il y a deux axes sur lesquels nous allons travailler : comment \u00e9viter une nouvelle erreur humaine, et comment \u00eatre mieux pr\u00e9par\u00e9 si elle devait se reproduire.<\/p>\n
\u00c0 nouveau, il y a deux composantes pour atteindre cet objectif : par la technique, et par la pr\u00e9vention humaine.<\/p>\n
Techniquement, nous allons r\u00e9fl\u00e9chir \u00e0 mettre en place :<\/p>\n
Humainement, nous allons r\u00e9fl\u00e9chir \u00e0 \u00e9dicter des r\u00e8gles d\u2019utilisation pour limiter les risques, par exemple :<\/p>\n
Une fois les fichiers supprim\u00e9s, nous avons d\u00fb travailler \u00e0 restaurer au plus vite les bases de donn\u00e9es perdues. Une telle suppression sauvage des fichiers internes aux bases de donn\u00e9es rend MySQL et PostgreSQL instables, et nous avons donc d\u00fb nous h\u00e2ter de faire des tests sur un serveur temporaire pour s\u2019assurer de la marche \u00e0 suivre.<\/p>\n
Par ailleurs, nous n\u2019avions aucune m\u00e9thode \u00e9prouv\u00e9e pour d\u00e9tecter les bases supprim\u00e9es puis r\u00e9installer les derni\u00e8res sauvegardes. Ce n\u2019\u00e9tait pas tr\u00e8s compliqu\u00e9, mais cela a n\u00e9cessit\u00e9 l\u2019\u00e9criture de scripts et de tests pour s\u2019assurer du bon fonctionnement de la proc\u00e9dure. C\u2019est seulement ensuite que nous avons pu restaurer pour de bon les bases supprim\u00e9es, d\u2019o\u00f9 environ 2 heures de d\u00e9lai entre la suppression des fichiers et la restauration effective des bases.<\/p>\n
Nous avons d\u00e9cid\u00e9 il y a quelques semaines de lancer un programme de simulation des diff\u00e9rents probl\u00e8mes possibles sur notre architecture (panne de machine\/r\u00e9seau\/datacenter, p\u00e9n\u00e9tration de nos syst\u00e8mes, suppression de donn\u00e9es). Ce n\u2019est pas encore en place parce qu\u2019il 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\u2019int\u00e9r\u00eat d\u2019\u00eatre pr\u00e9par\u00e9 \u00e0 de multiples sc\u00e9narios catastrophe.<\/p>\n
Par ailleurs, nous sommes en train de travailler sur un nouveau syst\u00e8me de redondance. Rien n\u2019est encore fait, nous en sommes encore au stade de l\u2019exp\u00e9rimentation, mais ce syst\u00e8me pourrait nous permettre de faire des \u00ab snapshots \u00bb r\u00e9guliers (par exemple, toutes les heures) de l\u2019int\u00e9gralit\u00e9 de nos donn\u00e9es. S\u2019il avait \u00e9t\u00e9 en place, ce syst\u00e8me nous aurait permis non pas de partir sur des sauvegardes datant de plusieures heures, mais maximum d\u2019une heure. Nous aurons l\u2019occasion de faire un billet \u00e0 ce sujet si ce syst\u00e8me se concr\u00e9tise.<\/p>\n
Terminons sur une note positive : nous pouvons relever que notre politique de communication en temps r\u00e9el et de transparence, via notre compte Twitter<\/a>, fonctionne bien en cas d\u2019incident. Il faudrait encore l\u2019am\u00e9liorer en affichant, dans l\u2019administration alwaysdata et sur notre forum, les incidents en cours (tout le monde n\u2019est pas sur Twitter). Nous avons \u00e9galement pu contacter personnellement chacun de nos clients par email en leur indiquant pr\u00e9cis\u00e9ment les bases touch\u00e9es et la date de derni\u00e8re restauration.<\/p>\n En outre, les sauvegardes ont \u00e9t\u00e9 d\u2019une grande utilit\u00e9. Ce n\u2019est pas une surprise, et chacun peut d\u2019ailleurs acc\u00e9der librement \u00e0 ses sauvegardes via un r\u00e9pertoire de son compte. Mais c\u2019\u00e9tait la premi\u00e8re fois qu\u2019elles ont \u00e9t\u00e9 utilis\u00e9es \u00e0 grande \u00e9chelle.<\/p>\n Pour conclure, j\u2019aimerais pr\u00e9senter une nouvelle fois toutes nos excuses au nom de l\u2019\u00e9quipe alwaysdata pour ce malheureux incident. Merci \u00e0 tous les messages d\u2019encouragement que nous avons re\u00e7us, ils sont toujours tr\u00e8s appr\u00e9ci\u00e9s, a fortiori en situation de crise.<\/p>\n","protected":false},"excerpt":{"rendered":" Hier vers 12h40, une erreur humaine nous a fait perdre un petit nombre de bases de donn\u00e9es clients. Nous avons \u00e9t\u00e9 contraints de restaurer les bases \u2026 Keep reading<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"wp_typography_post_enhancements_disabled":false,"footnotes":""},"categories":[1],"tags":[134,181,188],"class_list":["post-959","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-base-de-donnees-fr","tag-mysql-fr","tag-postgresql-fr"],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts\/959","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/comments?post=959"}],"version-history":[{"count":0,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts\/959\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/media?parent=959"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/categories?post=959"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/tags?post=959"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}