# En ingenjör raderade GitLabs produktionsdatabas. 300 gigabyte.

Published: 2026-09-10

31 januari 2017, 23:27 UTC: en GitLab-ingenjör, som kämpade med en trasig replik i slutet av en lång natt, tar bort PostgreSQL-datakatalogen på db1 istället för db2. db1 är primär. Cirka 300 GB av GitLab.coms databas är borta på en sekund eller två, och av de fem backup- och replikeringsmekanismerna fungerar ingen. Postmortem: tidslinjen från spam-spiken till fel värdnamn, varför pg\_basebackup verkade ha fastnat, varför pg\_dump tyst hade misslyckats (9.2-binärer på en 9.6-databas, felmeddelanden studsade av DMARC), den 18-timmars återställningen från en 6-timmars gammal staging-snapshot streamad live på YouTube, och vem som verkligen får skulden. Dom över svaret: SHIP IT.

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

## Vad den här videon täcker

- 31 jan 2017: rm -Rvf på den primära datakatalogen; ~300 GB borttaget, 4.5 GB kvar
- 5 av 5 säkerhetskopior misslyckas: tom S3-bucket (pg\_dump versionsmatchningsfel), inga Azure-snapshots på databasen, raderad replik, daglig LVM-kopia utan webhooks
- 1 feb, 18:00 UTC: GitLab.com tillbaka från en 6 timmar gammal manuell snapshot; livedokumentation, livestream, blameless postmortem med en fixlista

## Översatt transkription

Översatt från den ursprungliga engelska berättelsen. Tillgängligt ljud och undertexter styrs av YouTube.

0:00 En ingenjör på GitLab kör rm -rf på fel databasserver, och trehundra gigabyte av GitLab dot com försvinner på en sekund eller två, ungefär så lång tid det tar att läsa ett värdnamn. Den trettioförsta januari 2017, klockan 23:27 UTC. GitLab twittrar att de av misstag raderat produktionsdata, öppnar sina incidentanteckningar för internet, och streamar återställningen på YouTube, den näst mest sedda livestreamen på plattformen. Nästa dag, skriftligt: av fem backup-tekniker,

0:25 fungerar ingen tillförlitligt. Hur det händer, varför det är möjligt, och vem som faktiskt får skulden. Detta är The Daily Diff, postmortem. 17:20: en ingenjör tar en ögonblicksbild av produktionen för att testa en lastbalanserare i staging. 19:00: spam bombarderar databasen, plus ett jobb som hård-raderar en GitLab-anställd som en troll anmält för missbruk. 23:00: repliken hamnar så långt efter att primären redan har kastat

0:48 loggen den behöver; den enda lösningen är att radera repliken och kopiera primären igen. pg\_basebackup hänger sig utan utdata. Den väntar faktiskt, tyst, på primären; ingen vet det, och handboken säger inget. Ingenjören, som tänkte logga ut klockan elva, bestämmer att den tomma datakatalogen är problemet och tar bort den. På db1. Primären. Han märker det en sekund eller två senare; av ungefär trehundra gigabyte,

1:11 återstår 4,5. Backuparna. Ett: pg\_dump till S3, dagligen. Containern är tom. Cron-jobbet körs på en app-server utan databas, så paketet väljer PostgreSQL 9.2-binärer för en 9.6-databas, misslyckas, och skickar e-post om felet, som studsar på grund av saknad DMARC. Två: Azure disknapshots, aktiverade för filservrarna, inte databaserna.

1:32 Tre: repliken, avsiktligt raderad för en timme sedan. Fyra: den dagliga snapshoten, 24 timmar gammal, varje webhook borttagen av staging-synkroniseringen. Fem: den manuella snapshoten från 17:20, för ett orelaterat test. Den vinner. Att återställa innebär att kopiera staging-disken tillbaka till produktionen över Azures billiga lagring med sextio megabit per sekund: arton timmar. GitLab dot com är tillbaka den 1 februari klockan arton UTC, sex timmar äldre data.

1:58 git blame: två värdnamn en karaktär ifrån varandra, och fem backupsystem som ingen har någonsin återställt från. Inte ingenjören. Postmortemen, undertecknad av VD:n, håller honom anonym, färgar produktionsprompten röd, och ger datahållbarhet en ägare, förrän nu hade den ingen. Explosionsradie: arton timmar nere, sex timmar data borta, ungefär fem tusen projekt, fem tusen kommentarer,

2:18 sjuhundra nya användare, och fem tusen människor som tittar på en förloppsindikator. Hacker News ger livedokumentet 1 162 poäng och citerar en rad tillbaka till dem: av fem backups, ingen. Dom, postmortem: SHIP IT, om svaret. De hanterar incidenten offentligt, skyller på processen, och publicerar fixlistan med ärendenummer. Måndagens åtgärd: återställ en backup. Om du aldrig har återställt den, har du ingen.

2:42 Skicka mig incidenten du fortfarande inte får prata om, i kommentarerna, eller på the daily diff dot dev. Och det var dagens diff. Jag är Niko från Axrisi. Merge responsibly.

## Källor

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