Cinq techniques de sauvegarde, aucune fiable : la nuit où GitLab a effacé sa base de données

Avoir des sauvegardes n'est pas la même chose que pouvoir restaurer. La différence ne se voit que le jour où l'on en a besoin, et ce jour-là il est déjà trop tard pour la découvrir. En janvier 2017, un service cloud d'hébergement de code l'a découvert en direct, sous les yeux de milliers de personnes.

Une précision avant de commencer : Hábil n'a pas participé à ce cas. Nous le racontons à partir de ce que GitLab a publié dans son postmortem public et de ce qu'a rapporté la presse spécialisée.

Mardi, peu après vingt-trois heures

Nous sommes le 31 janvier 2017. GitLab.com, le service cloud où des équipes logicielles conservent leur code, leurs tâches et leurs revues, connaît des problèmes depuis des heures. Depuis l'après-midi, la base de données principale subit une charge anormale. L'équipe soupçonne du spam. Les utilisateurs ne peuvent pas publier de commentaires [1][2].

Derrière cette charge se cache une coïncidence que personne n'avait prévue. En plus du spam, un processus destiné à supprimer les données d'un employé de l'entreprise elle-même a été programmé par erreur, déclenché par un signalement d'abus [1]. Les deux ensemble mettent la base sous pression.

Vers vingt-trois heures (heure UTC), la pression entraîne une conséquence plus grave. La base principale a une réplique : une seconde copie tenue à jour en recevant chaque modification, prête à prendre la place de la première si celle-ci tombe en panne. Sous la charge, la réplique prend du retard. Et quand elle tente de le rattraper, les modifications dont elle avait besoin ne sont plus là : la base principale les a écartées avant que la réplique ne les reçoive [1].

Il n'existe aucune manière automatique d'en sortir. La réplique doit être reconstruite à la main [1].

Un ingénieur s'y attelle. Il efface le répertoire de données de la réplique pour le recopier depuis la principale. Il lance l'outil qui fait cette copie, et l'outil ne répond pas. Il semble bloqué. L'ingénieur ajuste des paramètres. La base refuse de redémarrer. Il en ajuste d'autres [1].

Ce que personne ne sait à ce moment-là, c'est que l'outil n'était pas bloqué : il attendait en silence que la base principale commence à envoyer des données, ce qui peut prendre plusieurs minutes. Ce comportement ne figurait ni dans les procédures de l'équipe ni dans la documentation officielle [1][2].

Il fait nuit aux Pays-Bas, où travaille l'ingénieur [4]. Le problème dure depuis des heures. Il croit que la copie ratée a laissé des déchets dans le répertoire de la réplique et décide de le nettoyer à nouveau.

Il tape la commande de suppression. Il l'exécute.

Une ou deux secondes plus tard, il s'en rend compte : il n'est pas sur la réplique. Il est sur la base principale [1][2].

Il l'arrête. Mais la commande de suppression ne demande rien et ne peut pas être annulée. Sur environ 300 Go de données, il en reste environ 4,5 Go [2][4].

La recherche

À cet instant, tout le monde se pose la même question : d'où restaurer ?

GitLab n'était pas une entreprise improvisée. Elle disposait, sur le papier, de plusieurs couches de protection. L'équipe commence à les passer en revue une par une, et les note dans un document Google qu'elle rend public pour que chacun puisse suivre l'avancement [1][3].

La sauvegarde quotidienne dans le cloud. Toutes les 24 heures, une tâche planifiée devait extraire un export complet de la base et le stocker dans un espace de stockage d'Amazon (S3). L'équipe ouvre le stockage. Il est vide [1][2][4].

Pourquoi ? La tâche exécutait l'outil d'export dans sa version 9.2 contre une base en version 9.6. L'outil choisissait sa version d'après le répertoire de données du serveur où il s'exécutait, et cette tâche s'exécutait sur un serveur d'application, qui n'avait pas de répertoire de données. Il prenait donc l'ancienne version et échouait [1].

Il échouait tous les jours. Et personne ne s'en apercevait ? La tâche envoyait bien un courriel en cas d'échec. Mais ces courriels étaient rejetés : le serveur destinataire les renvoyait parce que DMARC n'était pas activé pour les courriels des tâches planifiées, un mécanisme qu'utilisent les serveurs de messagerie pour vérifier qu'un message est légitime [1][5]. L'alarme existait. Elle n'est jamais parvenue à personne.

Les instantanés de disque du cloud. GitLab tournait alors sur Microsoft Azure, qui peut prendre des photos périodiques d'un disque entier. Ils étaient activés pour les serveurs de fichiers, mais pas pour ceux de base de données : l'équipe a supposé que les autres sauvegardes suffisaient [1].

La réplique. C'est la première chose à laquelle n'importe qui penserait. Mais une réplique n'est pas une sauvegarde : elle copie tout, y compris les erreurs, et sert à prendre le relais d'un serveur tombé, pas à revenir dans le temps. De plus, dans ce cas, elle n'existait plus : son répertoire avait été effacé quelques minutes plus tôt, dans le cadre de la reconstruction [1].

Les instantanés du serveur. Il restait une dernière couche : des photos du disque prises avec LVM, le gestionnaire de volumes logiques du système. Elles étaient prises toutes les 24 heures, non comme sauvegarde, mais pour copier les données réelles vers un environnement de test (staging). La plus récente programmée datait de presque un jour [1].

Cette nuit-là, le document public, qui comptait séparément les extractions quotidiennes et leur copie dans S3, a résumé la situation en une phrase qui a fait le tour d'internet :

« Sur cinq techniques de sauvegarde et de réplication déployées, aucune ne fonctionne de manière fiable, ou n'était même configurée. » (traduction propre) [2][4]

Six heures de chance

Et c'est alors qu'apparaît la seule bonne nouvelle de la nuit, presque par accident.

Le même jour, vers 17 h 20 UTC, un ingénieur avait pris à la main un instantané de la base pour le charger dans l'environnement de test. Il l'avait pris pour disposer de données récentes afin de tester un outil de répartition de la charge de la base de données [1]. Cette copie, faite pour autre chose, était désormais la seule à dater de six heures, et non de vingt-quatre.

L'équipe choisit cette copie. L'alternative était de perdre presque une journée entière [1].

Reste à la ramener. Et là surgit une autre décision que quelqu'un avait prise bien avant, pour de bonnes raisons. L'environnement de test tournait sur des disques économiques d'Azure, sans stockage haute performance, pour réduire les coûts. Ces disques étaient limités à environ 60 Mbit/s. Copier les données de l'environnement de test vers le serveur principal a pris environ 18 heures. Le goulet d'étranglement n'était ni le réseau ni le processeur : c'étaient les disques [1].

Dix-huit heures de copie, avec GitLab.com hors service.

La reprise, en direct

Ce que GitLab a fait pendant ces heures est l'autre moitié de cette histoire, et c'est celle qui la distingue.

Au lieu de fermer la porte et de publier un communiqué laconique à la fin, l'entreprise a informé publiquement de ce qui se passait pendant qu'elle se rétablissait. Son compte d'état sur Twitter l'a dit sans détour : « Nous avons supprimé par accident des données de production et nous devrons peut-être restaurer à partir d'une sauvegarde » (traduction propre) [1][2]. Le document de travail, avec les notes de l'équipe et la liste de ce qui avait échoué, est resté visible de tous [1][3]. Et la reprise a été diffusée sur YouTube. Elle a atteint environ 5 000 spectateurs simultanés et a été, pendant plusieurs heures, la deuxième diffusion en direct la plus regardée de la plateforme [1].

Le 1er février, vers 17 h 00 UTC, la base était restaurée, encore sans les webhooks (les notifications automatiques que GitLab envoie à d'autres systèmes quand quelque chose change). Vers dix-huit heures, le service était de retour, les dernières étapes terminées [1][2]. Au total, GitLab.com a été hors service environ 18 heures [1].

L'équipe a soigné des détails que seul remarque quelqu'un qui est déjà passé par là. Elle a récupéré les webhooks en montant une base à part à partir du même instantané, sans l'étape qui les supprime lors de la copie des données vers le test, puis les a transférés de là vers la base principale. Elle a avancé de 100 000 tous les compteurs d'identifiants de la base, pour qu'aucun numéro utilisé pendant les heures perdues ne soit réattribué à autre chose. Et comme le code des dépôts ne vit pas dans la base de données mais à part, sur des serveurs de fichiers qui n'avaient pas été effacés, elle a refait à partir de là, sous leur forme de base, les projets créés après 17 h 20, mais sans leurs tâches ni leurs revues [1].

Ce qui a été perdu

Les modifications faites dans la base pendant environ six heures ont été perdues : entre 17 h 20 UTC et minuit le 31 janvier, selon le postmortem, qui situe ailleurs la fin vers 23 h 30 [1][2]. Sa meilleure estimation : près de 5 000 projets, 5 000 commentaires et 700 nouveaux comptes utilisateur touchés [1].

Ce qui n'a pas été perdu compte aussi. Le code et les wikis stockés sur GitLab.com ont été indisponibles pendant la panne, mais n'ont pas été perdus. Les entreprises qui avaient GitLab installé sur leurs propres serveurs n'ont pas été touchées [1][2][4].

Dix jours plus tard, le 10 février, GitLab a publié un postmortem complet : la chronologie heure par heure, chaque mécanisme qui a échoué et pourquoi, et une liste publique de tâches pour le corriger, chacune avec son numéro de suivi [1]. Il commençait par des excuses directes : « Aux utilisateurs de GitLab.com dont nous avons perdu les données et aux personnes touchées par la panne : nous sommes désolés » (traduction propre) [1].

Ce que ce cas enseigne

Il est facile de lire cette histoire comme celle d'un ingénieur qui s'est trompé de fenêtre. Ce serait la mauvaise lecture. Le postmortem de GitLab lui-même ne s'arrête pas là : il demande pourquoi une seule erreur a pu coûter autant, et la réponse a peu à voir avec cette personne.

1. Une sauvegarde que personne n'a restaurée est une supposition

GitLab avait des tâches de sauvegarde, du stockage dans le cloud, des instantanés et une réplique. Sur un schéma d'architecture, cela paraît solide. Ce qui lui manquait, c'était la preuve que l'un de ces mécanismes rendait une base en état de marche.

Le postmortem le dit en une seule ligne, sans fioritures : « Comme il n'y avait pas de responsable, personne n'était chargé de tester cette procédure » (traduction propre) [1].

Remarquez ce que cela signifie pour une direction. Personne n'a éteint les sauvegardes. Personne n'a décidé de prendre des risques. La sauvegarde quotidienne a échoué en silence à cause d'une différence de version que personne ne voyait, et elle prévenait par un canal que personne ne recevait. La seule façon de le découvrir plus tôt était d'essayer de restaurer. Et comme cette tâche n'appartenait à personne, personne ne l'a faite.

2. Une réplique protège contre la panne, pas contre l'erreur

Ce point déroute même des équipes expérimentées. Une réplique est conçue pour que le service continue si un serveur tombe. Selon sa configuration, elle peut accuser un retard, comme celle de GitLab cette nuit-là. Et si quelqu'un efface des données, ou si une application écrit des déchets, la réplique copie l'effacement et les déchets avec la même diligence. Pour revenir à un moment antérieur, il faut autre chose : une sauvegarde qui conserve l'historique, ou un journal des modifications qui permette de reconstruire la base jusqu'à une minute donnée.

Le postmortem fait clairement la distinction : la réplique servait à relayer le serveur, pas à la reprise après sinistre [1].

3. Ce qui se fait à la main, à des heures indues, n'a pas de filet de sécurité

La reconstruction de la réplique n'était ni automatisée ni bien documentée. GitLab le reconnaît : la procédure était manuelle, reposait sur des scripts improvisés et la documentation était rare [1][2]. Un ingénieur en pleine nuit, après des heures d'incident, devait se souvenir de chaque étape, distinguer deux serveurs aux noms presque identiques (db1 et db2) et deviner si un outil silencieux était bloqué ou en train de travailler.

Dans ces conditions, le risque de se tromper augmente beaucoup. La première tâche de la liste de GitLab a d'ailleurs été de rendre plus évident, au moment de taper une commande, sur quel serveur et dans quel environnement se trouve chacun [1].

4. Les décisions d'économie se paient le jour du sinistre

Les instantanés d'Azure n'étaient pas actifs pour les bases parce qu'on avait pensé que les autres sauvegardes suffisaient. L'environnement de test avait des disques lents parce que cela coûtait moins cher [1]. Chaque décision était raisonnable prise isolément. Ensemble, et ajoutées à la réplique perdue, à la sauvegarde quotidienne qui échouait et aux alertes rejetées, elles ont contribué à ce qu'une erreur de deux secondes se termine en une reprise d'environ 18 heures.

Il n'y a rien de mal à économiser. Ce qui manque, presque toujours, c'est que quelqu'un écrive la conséquence à côté de la décision : « avec ces disques, restaurer prend tant d'heures ; l'acceptons-nous ? ». Si cette question se pose avant, on décide. Si on la découvre le jour du sinistre, on ne fait que la subir.

5. Ce que GitLab a bien fait fait aussi partie de la leçon

Il serait injuste de raconter cette histoire sans le dire en toutes lettres : GitLab a géré la crise avec une transparence que peu d'entreprises osent avoir. L'entreprise a informé publiquement pendant la reprise, a ouvert ses notes de travail, a diffusé la reprise, s'est excusée sans détour et a publié une analyse qui nomme chacune de ses propres défaillances [1].

Et GitLab a tiré des leçons de sa propre transparence. Le document public a fini par afficher le nom de l'ingénieur impliqué ; dans le postmortem, GitLab a annoncé qu'à l'avenir elle omettrait les noms, car d'autres ingénieurs pourraient ne pas être à l'aise à l'idée de les voir publiés [1]. L'analyse vise les processus, pas la personne.

Cette attitude n'est pas qu'une question d'image. Une entreprise capable de dire publiquement « ceci a échoué, et voici pourquoi » est une entreprise capable de le corriger. La transparence n'élimine pas le risque, mais elle permet d'examiner les défaillances et d'attribuer des améliorations concrètes.

Ce que GitLab a prévu et ce qui avait déjà changé

Le postmortem a publié une liste de tâches ouvertes, chacune avec son numéro public. Parmi elles [1] :

• Rendre évident, en ligne de commande, sur quel serveur et dans quel environnement on travaille.
• Surveiller les sauvegardes, pour qu'une sauvegarde qui échoue ne passe pas inaperçue.
• Prendre des instantanés de la base toutes les heures au lieu de tous les jours, et activer les instantanés de disque pour les bases.
• Étudier la restauration à un point dans le temps et l'archivage continu des modifications de la base.
• Tester de manière automatisée que les sauvegardes peuvent être restaurées.
• Améliorer la documentation et les procédures de la réplication.
• Nommer un responsable de la durabilité des données (quelqu'un qui répond de leur intégrité et de leur restauration).
• Préparer la reprise après sinistre aussi pour tout ce qui n'est pas la base de données.
• Faire en sorte que supprimer un utilisateur pour spam ne l'élimine pas définitivement.

Au moment de publier le postmortem, GitLab prenait déjà les instantanés LVM toutes les heures et avait commencé à construire un tableau de bord public de l'état des sauvegardes ; les instantanés de disque d'Azure pour les bases étaient encore à l'étude [1]. Selon InfoQ, dans les deux semaines qui ont suivi l'incident, GitLab a commencé à archiver en temps réel les modifications de la base dans un stockage d'Amazon, et une restauration de test à un point dans le temps a pris un peu moins de deux heures [5]. Des mois plus tard, l'équipe organisait des journées consacrées à restaurer ses sauvegardes — la base principale, d'autres bases et un instantané de disque — pour vérifier qu'elles sauvegardaient vraiment [6][7]. En juin 2017, ces restaurations étaient encore manuelles et l'automatisation figurait sur la liste des tâches en attente [6]. Changer une habitude prend du temps, même après une telle frayeur.

Le postmortem résume l'esprit du changement en une phrase qui vaut pour toute exploitation : « Un environnement idéal est un environnement dans lequel on peut commettre des erreurs, mais s'en remettre facilement et rapidement, avec un impact minime ou nul » (traduction propre) [1]. Il ne s'agit pas d'interdire des commandes. Il s'agit que se tromper ne coûte pas 18 heures.

Ce que cela signifie pour votre entreprise

Vous n'exploitez probablement pas une plateforme mondiale comme GitLab.com. Mais le schéma de cette histoire apparaît dans des entreprises de toute taille, et presque toujours avec les mêmes ingrédients :

• Une infrastructure montée à la main. Des serveurs, des réseaux et des tâches planifiées que quelqu'un a configurés un jour, qui fonctionnent et que personne n'ose toucher. Personne ne sait avec certitude ce qu'ils contiennent, parce que ce n'est écrit nulle part.
• Des sauvegardes planifiées, mais jamais restaurées. Il y a une tâche qui « fait la sauvegarde » et un rapport qui dit qu'elle s'est exécutée. Personne n'a essayé de remonter une base complète à partir de ce fichier.
• Des alertes qui n'arrivent à personne. Des courriels vers des boîtes que personne ne lit, ou qui sont rejetés, comme chez GitLab.
• Des procédures qui vivent dans la mémoire d'une seule personne. Elles fonctionnent tant que cette personne est là, reposée et disponible.
• Des économies sans conséquence écrite. Des disques plus lents, des copies moins fréquentes, moins d'environnements, tout cela sans que personne ait calculé combien de temps prendrait la reprise avec ces décisions.

La différence entre une nuit comme celle de GitLab et une frayeur d'une heure ne tient pas à avoir plus d'outils. Elle tient à trois pratiques que l'on peut vérifier :

L'infrastructure écrite sous forme de code. Lorsque chaque serveur, réseau, permission et tâche planifiée est décrit dans des fichiers que l'on conserve et que l'on revoit comme n'importe quel changement logiciel, les configurations restent visibles et vérifiables. Si une tâche de sauvegarde s'exécute sur le mauvais serveur, comme celle de GitLab, l'erreur peut apparaître lors d'une revue, au lieu de rester cachée dans une machine. Et si elle s'accompagne de revues et de tests, cette description facilite la reconstruction cohérente de ce qui serait perdu.

La trace de chaque changement. Qui a changé quoi, quand et pourquoi, enregistré sans dépendre de la mémoire de quiconque. Quand quelque chose casse, cet historique est la première chose que l'on consulte.

Les restaurations testées. Une sauvegarde vaut ce que vaut sa dernière restauration réussie. On la teste selon un calendrier, on mesure combien de temps elle prend et on compare ce temps à ce que l'entreprise a accepté de perdre et d'attendre. Si personne n'a restauré depuis des mois, ce que vous avez n'est pas une sauvegarde vérifiée : c'est une supposition.

Cinq questions pour votre prochain comité

1. Quand avons-nous restauré pour la dernière fois une base complète à partir d'une sauvegarde, dans un environnement séparé, et cela a-t-il fonctionné ? Si la réponse est « jamais » ou « je ne sais pas », votre premier risque est là.
2. Combien de temps prendrait cette restauration, mesuré et non estimé, et combien d'heures de données perdrions-nous ?
3. Qui est responsable du bon fonctionnement des sauvegardes ? Un nom, pas un service.
4. Si demain la tâche de sauvegarde échoue, qui l'apprend et comment ? Cette alerte a-t-elle déjà été testée ?
5. Pourrions-nous remonter notre infrastructure à l'identique si nous perdions le serveur, ou cela dépend-il de ce dont se souvient une personne ?

Si deux réponses ou plus sont « je ne sais pas », vos sauvegardes ne sont pas vérifiées.

Par où commencer cette semaine

Il n'est pas nécessaire de lancer un projet pour faire le premier pas. Choisissez votre base de données la plus importante et demandez une seule chose à votre équipe : restaurer la sauvegarde la plus récente dans un environnement séparé, mesurer combien de temps cela prend et vérifier que l'application fonctionne par-dessus. Notez le résultat, la date et qui l'a fait. Si cela fonctionne, vous avez votre première preuve. Si cela ne fonctionne pas, vous venez de découvrir, un mardi tranquille, ce que GitLab a découvert à minuit.

Questions fréquentes

Une réplique de la base de données compte-t-elle comme sauvegarde ?

Pas nécessairement. Une réplique peut aider à maintenir le service si un serveur tombe, mais elle copie aussi les suppressions et les erreurs. Pour revenir à un moment antérieur, il faut une sauvegarde qui conserve l'historique ou un mécanisme de restauration à un point dans le temps.

À quelle fréquence convient-il de tester une restauration ?

Cela dépend de la vitesse à laquelle vos données changent et de ce que votre activité peut tolérer. L'important est qu'elle ait une date au calendrier et un responsable, et qu'elle soit répétée aussi après de grands changements, comme une mise à jour de version de la base. Chez GitLab, c'est justement une différence de version qui a cassé la sauvegarde quotidienne [1].

Qu'est-ce que « l'infrastructure sous forme de code » et en quoi aide-t-elle pour les sauvegardes ?

C'est décrire serveurs, réseaux, permissions et tâches planifiées dans des fichiers que l'on conserve et que l'on revoit comme n'importe quel logiciel, au lieu de les configurer à la main. Elle aide parce que ce qui est écrit peut être revu, comparé et remonté à l'identique. Les données ne voyagent pas dans ce code : elles voyagent avec vos sauvegardes, que l'on teste à part.

Davantage de copies de sauvegarde nous auraient-elles protégés ?

Pas nécessairement. GitLab avait plusieurs couches et aucune ne fonctionnait de manière fiable cette nuit-là ; la base a été sauvée par une copie faite à la main pour autre chose [1][2]. Des tests de restauration réguliers auraient aidé à détecter plus tôt que certaines couches n'étaient pas récupérables et que les alertes n'arrivaient à personne.

Qu'est-il arrivé à l'ingénieur ?

Le postmortem ne le blâme pas. Il analyse pourquoi une erreur humaine, qui allait se produire à un moment ou à un autre, a pu avoir un tel coût, et annonce que lors des incidents futurs les noms des personnes impliquées seront omis [1].

Combien d'heures de données GitLab a-t-il perdues ?

Environ six heures de modifications dans la base de données, selon le postmortem lui-même. Le code et les wikis n'ont pas été perdus [1].

Ce que fait Hábil

Hábil est une société mexicaine de conseil en ingénierie, fondée en 2006. Avec Provisionnement d'infrastructure, nous concevons avec vous la base sur laquelle tournent vos systèmes, nous la montons et nous vous la livrons en état de marche, documentée et écrite sous forme de code, dans votre cloud, dans votre centre de données ou dans les deux. Cela comprend, lorsque votre cas l'exige, des sauvegardes qui se restaurent et un plan de reprise avec des délais convenus et testés. Votre équipe reçoit le code et la documentation pour l'exploiter, et pour la remonter à l'identique, sans dépendre de nous. Voyez la page Provisionnement d'infrastructure.

La première conversation est sans frais : elle part de ce que vous avez en place aujourd'hui, de la manière dont c'est sauvegardé et de la dernière fois que quelqu'un l'a restauré. Écrivez-nous sur WhatsApp.

Les faits, heures et chiffres sont ceux publiés par GitLab et par la presse citée ; ce ne sont pas des mesures propres. Les citations sont traduites de l'anglais (traduction propre). Heures en UTC, telles que GitLab les publie. Sources consultées le 20 octobre 2026.