# En ingeniør slettede GitLabs produktionsdatabase. 300 gigabyte.

Published: 2026-09-10

31. januar 2017, kl. 23:27 UTC: en GitLab-ingeniør, der kæmpede med en ødelagt replika efter en lang nat, fjerner PostgreSQL-datamappen på db1 i stedet for db2. db1 er primær. Omkring 300 GB af GitLab.com's database er væk på et sekund eller to, og af de fem backup- og replikeringsmekanismer virker ingen. Postmortem: tidslinjen fra spam-spidsen til det forkerte værtsnavn, hvorfor pg\_basebackup så ud til at være frosset, hvorfor pg\_dump havde fejlet lydløst (9.2-binære filer på en 9.6-database, fejl-e-mails afvist af DMARC), den 18-timers gendannelse fra et 6-timer gammelt staging-snapshot streamet live på YouTube, og hvem der egentlig får skylden. Dom over responsen: SHIP IT.

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

## Hvad denne video dækker

- 31. jan. 2017: rm -Rvf på primærserverens datamappe; ~300 GB fjernet, 4,5 GB tilbage
- 5 af 5 sikkerhedskopier fejler: tom S3-bucket (pg\_dump versionsmismatch), ingen Azure-snapshots på DB'en, slettet replika, daglig LVM-kopi uden webhooks
- 1. feb., kl. 18:00 UTC: GitLab.com tilbage fra et 6-timer gammelt manuelt snapshot; live dokument, live stream, blameless postmortem med en fejlrettelsesliste

## Oversat udskrift

Oversat fra den originale engelske fortælling. Tilgængelig lyd og undertekster styres af YouTube.

0:00 En ingeniør hos GitLab kører rm -rf på den forkerte databaseserver, og tre hundrede gigabyte af GitLab dot com forsvinder på et sekund eller to, omtrent hvor lang tid det tager at læse et værtsnavn. 31. januar 2017, kl. 23:27 UTC. GitLab tweeter, at de ved et uheld slettede produktionsdata, åbner deres incidentnoter for internettet og streamer gendannelsen på YouTube, den næstmest sete livestream på platformen. Næste dag, skriftligt: ud af fem backup-teknikker,

0:25 er ingen pålidelige. Hvordan det sker, hvorfor det er muligt, og hvem der faktisk får skylden. Dette er The Daily Diff, postmortem. 17:20: en ingeniør tager et snapshot af produktionen for at teste en load balancer i staging. 19:00: spam hamrer databasen, plus et job, der sletter en GitLab-medarbejder, en trold rapporterede for misbrug. 23:00: replikaen er så langt bagud, at primærserveren allerede har forkastet

0:48 den log, den har brug for; den eneste løsning er at slette replikaen og kopiere primærserveren igen. pg\_basebackup hænger uden output. Den venter faktisk, lydløst, på primærserveren; ingen ved det, og runbooken siger det ikke. Ingeniøren, som havde til hensigt at logge af kl. 23, beslutter, at den tomme datamappe er problemet og fjerner den. På db1. Primærserveren. Han bemærker et sekund eller to senere; af cirka tre hundrede gigabyte,

1:11 er 4,5 tilbage. Backupperne. Én: pg\_dump til S3, dagligt. Bucket'en er tom. Cron-jobbet kører på en app-server uden database, så pakken vælger PostgreSQL 9.2 binære filer til en 9.6 database, fejler og sender e-mails om fejlen, som afvises på grund af manglende DMARC. To: Azure disk snapshots, aktiveret for filserverne, ikke databaserne.

1:32 Tre: replikaen, slettet med vilje for en time siden. Fire: det daglige snapshot, 24 timer gammelt, alle webhooks fjernet af staging-synkroniseringen. Fem: det manuelle snapshot fra 17:20, til en urelateret test. Den vinder. Gendannelse betyder at kopiere staging-disken tilbage til produktionen over Azures billige lagring med tres megabit per sekund: atten timer. GitLab dot com er tilbage 1. februar kl. 18:00 UTC, seks timers data ældre.

1:58 git blame: to værtsnavne med én tegns forskel, og fem backupsystemer, som ingen nogensinde har gendannet fra. Ikke ingeniøren. Postmortem'en, underskrevet af CEO'en, holder ham anonym, farver produktionsprompten rød og giver dataholdbarhed en ejer, fordi den indtil nu ikke havde nogen. Blast radius: atten timer nede, seks timers data væk, cirka fem tusind projekter, fem tusind kommentarer,

2:18 syv hundrede nye brugere og fem tusind mennesker, der ser en statuslinje. Hacker News giver live-dokumentet 1.162 point og citerer én linje tilbage til dem: ud af fem backups, ingen. Dom, postmortem: SHIP IT, på responsen. De kører incidenten offentligt, skyder skylden på processen og udgiver fix-listen med issue-numre. Mandagsaktion: gendan en backup. Hvis du aldrig har gendannet den, har du ingen.

2:42 Send mig den incident, du stadig ikke må tale om, i kommentarerne eller på daily diff dot dev. Og det er diff'en for i dag. Jeg er Niko fra Axrisi. Flet ansvarligt.

## Kilder

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