# Un ingénieur a supprimé la base de données de production de GitLab. 300 gigaoctets.

Published: 2026-09-10

31 janvier 2017, 23:27 UTC : un ingénieur de GitLab, luttant contre un réplica défectueux à la fin d'une longue nuit, supprime le répertoire de données PostgreSQL sur db1 au lieu de db2. db1 est le primaire. Environ 300 Go de la base de données de GitLab.com disparaissent en une seconde ou deux, et des cinq mécanismes de sauvegarde et de réplication, aucun ne fonctionne. Autopsie : la chronologie, du pic de spam au mauvais nom d'hôte, pourquoi pg\_basebackup semblait bloqué, pourquoi pg\_dump échouait silencieusement (binaires 9.2 sur une base de données 9.6, e-mails d'échec rejetés par DMARC), la restauration de 18 heures à partir d'un instantané de staging de 6 heures diffusée en direct sur YouTube, et qui est vraiment à blâmer. Verdict sur la réponse : SHIP IT.

Canonical: https://thedailydiff.dev/fr-CA/video/2026-09-10-gitlab-rm-rf/

## Ce que cette vidéo couvre

- 31 janv. 2017 : rm -Rvf sur le répertoire de données du primaire ; ~300 Go supprimés, 4,5 Go restants
- 5 sauvegardes sur 5 échouent : bucket S3 vide (incompatibilité de version pg\_dump), pas d'instantanés Azure sur la base de données, réplica effacé, copie LVM quotidienne sans webhooks
- 1er févr., 18:00 UTC : GitLab.com de retour à partir d'un instantané manuel de 6 heures ; document en direct, diffusion en direct, postmortem "blameless" avec une liste de corrections

## Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont contrôlés par YouTube.

0:00 Un ingénieur de GitLab exécute rm -rf sur le mauvais serveur de base de données, et trois cents gigaoctets de GitLab.com disparaissent en une seconde ou deux, environ le temps qu'il faut pour lire un nom d'hôte. 31 janvier 2017, 23h27 UTC. GitLab tweete qu'il a accidentellement supprimé des données de production, ouvre ses notes d'incident à internet, et diffuse la récupération sur YouTube, la deuxième diffusion en direct la plus regardée sur la plateforme. Le lendemain, par écrit : sur cinq techniques de sauvegarde,

0:25 aucune ne fonctionne de manière fiable. Comment cela se produit, pourquoi c'est possible, et qui est réellement à blâmer. Ceci est The Daily Diff, postmortem. 17h20 : un ingénieur prend un instantané de la production pour tester un équilibreur de charge en staging. 19h : le spam submerge la base de données, plus une tâche supprimant définitivement un employé de GitLab qu'un troll a signalé pour abus. 23h : le réplica prend tellement de retard que le primaire a déjà supprimé

0:48 le journal dont il a besoin ; la seule solution est d'effacer le réplica et de copier le primaire à nouveau. pg\_basebackup se bloque sans sortie. Il attend en fait, silencieusement, le primaire ; personne ne le sait, et le "runbook" ne le dit pas. L'ingénieur, qui devait terminer à onze heures, décide que le répertoire de données vide est le problème et le supprime. Sur db1. Le primaire. Il le remarque une seconde ou deux plus tard ; sur environ trois cents gigaoctets,

1:11 4,5 restent. Les sauvegardes. Un : pg\_dump vers S3, quotidien. Le "bucket" est vide. La tâche cron s'exécute sur un serveur d'application sans base de données, de sorte que le paquet choisit des binaires PostgreSQL 9.2 pour une base de données 9.6, échoue, et envoie par e-mail l'échec, qui est rejeté pour DMARC manquant. Deux : instantanés de disque Azure, activés pour les serveurs de fichiers, pas les bases de données.

1:32 Trois : le réplica, effacé exprès il y a une heure. Quatre : l'instantané quotidien, vieux de 24 heures, chaque webhook supprimé par la synchronisation de staging. Cinq : l'instantané manuel de 17h20, pour un test sans rapport. Celui-là gagne. La restauration signifie copier le disque de staging vers la production via le stockage bon marché d'Azure à soixante mégabits par seconde : dix-huit heures. GitLab.com est de retour le 1er février à dix-huit heures UTC, avec six heures de données plus anciennes.

1:58 git blame : deux noms d'hôte à un caractère d'écart, et cinq systèmes de sauvegarde dont personne n'a jamais fait de restauration. Pas l'ingénieur. Le postmortem, signé par le PDG, le garde anonyme, colore l'invite de production en rouge, et donne un propriétaire à la durabilité des données, parce que jusqu'à présent elle n'en avait pas. Rayon d'action : dix-huit heures d'interruption, six heures de données perdues, environ cinq mille projets, cinq mille commentaires,

2:18 sept cents nouveaux utilisateurs, et cinq mille personnes regardant une barre de progression. Hacker News donne 1 162 points au document en direct et cite une ligne en retour : sur cinq sauvegardes, aucune. Verdict, postmortem : SHIP IT, sur la réponse. Ils gèrent l'incident en public, blâment le processus et publient la liste des correctifs avec les numéros de "ticket". Action du lundi : restaurer une sauvegarde. Si vous ne l'avez jamais restaurée, vous n'en avez pas.

2:42 Envoyez-moi l'incident dont vous n'êtes toujours pas autorisé à parler, dans les commentaires, ou à thedailydiff.dev. Et c'est le "diff" pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.

## Sources

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com