# 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 une réplique défectueuse au terme d'une longue nuit, supprime le répertoire de données PostgreSQL sur db1 au lieu de db2. db1 est la base de données primaire. Environ 300 Go de la base de données de GitLab.com disparaissent en une ou deux secondes, et des cinq mécanismes de sauvegarde et de réplication, aucun ne fonctionne. Autopsie : la chronologie, de la pointe 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 vieux 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/video/2026-09-10-gitlab-rm-rf/

## Ce que couvre cette vidéo

- 31 janvier 2017 : rm -Rvf sur le répertoire de données 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éplique effacée, copie LVM quotidienne sans webhooks
- 1er février, 18:00 UTC : GitLab.com de retour à partir d'un instantané manuel vieux de 6 heures ; document en direct, diffusion en direct, postmortem sans blâme avec une liste de corrections

## Transcription traduite

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

0:00 Un ingénieur chez GitLab exécute rm -rf sur le mauvais serveur de base de données, et trois cents gigaoctets de GitLab point com disparaissent en une ou deux secondes, 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, le deuxième flux en direct sur la plateforme. Le lendemain, par écrit : sur cinq techniques de sauvegarde,

0:25 aucune ne fonctionne de manière fiable. Comment cela arrive, 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 martèle la base de données, plus une tâche supprimant en dur un employé de GitLab qu'un troll a signalé pour abus. 23h : la réplique prend tellement de retard que le primaire a déjà supprimé

0:48 le journal dont elle a besoin ; la seule solution est d'effacer la réplique et de copier le primaire à nouveau. pg\_basebackup reste bloqué 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 débaucher à vingt-trois 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 ou deux secondes plus tard ; sur environ trois cents gigaoctets,

1:11 4,5 restent. Les sauvegardes. Un : pg\_dump vers S3, quotidiennement. Le bucket est vide. Le cron job s'exécute sur un serveur d'application sans base de données, donc le paquet utilise les binaires PostgreSQL 9.2 pour une base de données 9.6, échoue, et envoie par e-mail l'échec, qui rebondit 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 : la réplique, effacée délibérément il y a une heure. Quatre : l'instantané quotidien, vieux de 24 heures, tous les webhooks supprimés 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 point com est de retour le 1er février à dix-huit heures UTC, six heures de données plus anciennes.

1:58 git blame : deux noms d'hôte à un caractère d'intervalle, et cinq systèmes de sauvegarde dont personne n'a jamais restauré. Pas l'ingénieur. Le postmortem, signé par le PDG, le garde anonyme, colore l'invite de production en rouge, et attribue la durabilité des données à un propriétaire, car jusqu'à présent, il n'en avait pas. Rayon d'explosion : dix-huit heures d'indisponibilité, 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 corrections avec les numéros de problèmes. Action du lundi : restaurer une sauvegarde. Si vous ne l'avez jamais restauré, vous n'en avez pas.

2:42 Envoyez-moi l'incident dont vous n'êtes toujours pas autorisé à parler, dans les commentaires, ou à the daily diff point 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