# Un enginyer va eliminar la base de dades de producció de GitLab. 300 gigabytes.

Published: 2026-09-10

31 de gener de 2017, 23:27 UTC: un enginyer de GitLab, lluitant contra una rèplica trencada al final d'una llarga nit, elimina el directori de dades de PostgreSQL a db1 en lloc de db2. db1 és el primari. Uns 300 GB de la base de dades de GitLab.com desapareixen en un segon o dos, i dels cinc mecanismes de còpia de seguretat i replicació, cap funciona. Postmortem: la cronologia des del pic d'spam fins al nom d'amfitrió incorrecte, per què pg\_basebackup semblava encallat, per què pg\_dump havia fallat silenciosament (binaris 9.2 en una base de dades 9.6, els correus electrònics de fallada rebotats per DMARC), la restauració de 18 hores d'una instantània d'staging de 6 hores d'antiguitat transmesa en directe a YouTube, i qui realment té la culpa. Veredicte sobre la resposta: SHIP IT.

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

## Què cobreix aquest vídeo

- 31 de gener de 2017: rm -Rvf al directori de dades del primari; ~300 GB eliminats, 4,5 GB restants
- 5 de 5 còpies de seguretat fallen: cub S3 buit (discrepància de versió de pg\_dump), sense instantànies d'Azure a la base de dades, rèplica esborrada, còpia LVM diària sense webhooks
- 1 de febrer, 18:00 UTC: GitLab.com torna d'una instantània manual de 6 hores; document en viu, transmissió en directe, postmortem sense culpa amb una llista de correccions

## Transcripció traduïda

Traduït de la narració original en anglès. L'àudio i els subtítols disponibles estan controlats per YouTube.

0:00 Un enginyer de GitLab executa rm -rf al servidor de base de dades equivocat, i tres-cents gigabytes de GitLab dot com desapareixen en un segon o dos, aproximadament el temps que es triga a llegir un nom d'amfitrió. 31 de gener de 2017, 23:27 h. UTC. GitLab tuiteja que ha eliminat accidentalment dades de producció, obre les seves notes d'incidència a internet i transmet la recuperació a YouTube, la segona transmissió en directe més vista a la plataforma. L'endemà, per escrit: de cinc tècniques de còpia de seguretat,

0:25 cap funciona de manera fiable. Com passa, per què és possible i qui realment en té la culpa. Això és The Daily Diff, postmortem. 17:20 h.: un enginyer fa una instantània de producció per provar un balancejador de càrrega en staging. 19:00 h.: l'spam ataca la base de dades, a més d'una tasca que elimina definitivament un empleat de GitLab que un troll va denunciar per abús. 23:00 h.: la rèplica es queda tan endarrerida que el primari ja ha descartat

0:48 el registre que necessita; l'única solució és esborrar la rèplica i copiar el primari de nou. pg\_basebackup es penja sense sortida. En realitat està esperant, en silenci, el primari; ningú ho sap, i el llibre de procediments no ho diu. L'enginyer, que volia acabar a les onze, decideix que el directori de dades buit és el problema i el suprimeix. A db1. El primari. Ho nota un segon o dos després; d'aproximadament tres-cents gigabytes,

1:11 en queden 4,5. Les còpies de seguretat. Una: pg\_dump a S3, diàriament. El cub està buit. La tasca cron s'executa en un servidor d'aplicacions sense base de dades, de manera que el paquet tria binaris de PostgreSQL 9.2 per a una base de dades 9.6, falla i envia correus electrònics la fallada, que rebota per falta de DMARC. Dos: instantànies de disc d'Azure, habilitades per als servidors de fitxers, no les bases de dades.

1:32 Tres: la rèplica, esborrada a propòsit fa una hora. Quatre: la instantània diària, de 24 hores, cada webhook eliminat per la sincronització d'staging. Cinc: la instantània manual de les 17:20, per a una prova no relacionada. Aquesta guanya. Restaurar significa copiar el disc d'staging de nou a producció a través de l'emmagatzematge barat d'Azure a seixanta megabits per segon: divuit hores. GitLab dot com torna l'1 de febrer a les divuit hores UTC, sis hores de dades més antigues.

1:58 git blame: dos noms d'amfitrió separats per un caràcter, i cinc sistemes de còpia de seguretat dels quals ningú ha restaurat mai. No l'enginyer. El postmortem, signat pel CEO, el manté anònim, coloreja de vermell l'indicador de producció i dóna un propietari a la durabilitat de les dades, perquè fins ara no en tenia cap. Radi de blast: divuit hores caigut, sis hores de dades perdudes, aproximadament cinc mil projectes, cinc mil comentaris,

2:18 set-cents usuaris nous i cinc mil persones observant una barra de progrés. Hacker News dóna al document en viu 1.162 punts i cita una línia de tornada: de cinc còpies de seguretat, cap. Veredicte, postmortem: ship it, sobre la resposta. Gestionen l'incident en públic, culpen el procés i publiquen la llista de correccions amb números d'incidència. Acció de dilluns: restaurar una còpia de seguretat. Si mai l'heu restaurat, no en teniu cap.

2:42 Envieu-me l'incident del qual encara no se us permet parlar, als comentaris, o a the daily diff dot dev. I aquesta és la diferència d'avui. Sóc en Niko d'Axrisi. Fusioneu amb responsabilitat.

## Fonts

- [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