# Inżynier usunął produkcyjną bazę danych GitLab. 300 gigabajtów.

Published: 2026-09-10

31 stycznia 2017, 23:27 UTC: inżynier GitLab, walczący z uszkodzoną repliką po długiej nocy, usuwa katalog danych PostgreSQL na db1 zamiast db2. db1 jest głównym. Około 300 GB bazy danych GitLab.com znika w sekundę lub dwie, a z pięciu mechanizmów tworzenia kopii zapasowych i replikacji, żaden nie działa. Postmortem: oś czasu od skoku spamu do błędnej nazwy hosta, dlaczego pg\_basebackup wydawał się zablokowany, dlaczego pg\_dump cicho zawodził (binaria 9.2 na bazie danych 9.6, e-maile o błędach odrzucone przez DMARC), 18-godzinne przywracanie z 6-godzinnej migawki staging transmitowane na żywo na YouTube, i kto naprawdę ponosi winę. Werdykt w sprawie reakcji: SHIP IT.

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

## Co obejmuje ten film

- 31 stycznia 2017: rm -Rvf w katalogu danych głównego serwera; usunięto ~300 GB, pozostało 4,5 GB
- 5 z 5 kopii zapasowych zawodzi: pusty kubeł S3 (niezgodność wersji pg\_dump), brak migawek Azure na bazie danych, wyczyszczona replika, codzienna kopia LVM bez webhooków
- 1 lutego, 18:00 UTC: GitLab.com wraca z 6-godzinnej ręcznej migawki; dokument na żywo, stream na żywo, bezstronny postmortem z listą poprawek

## Przetłumaczona transkrypcja

Przetłumaczono z oryginalnej narracji angielskiej. Dostępne audio i napisy są kontrolowane przez YouTube.

0:00 Inżynier w GitLab uruchamia rm -rf na złym serwerze bazy danych, i trzysta gigabajtów GitLab dot com znika w sekundę lub dwie, mniej więcej tyle, ile zajmuje odczytanie nazwy hosta. 31 stycznia 2017, 23:27 UTC. GitLab tweetuje, że przypadkowo usunął dane produkcyjne, udostępnia swoje notatki z incydentu internetowi i transmituje odzyskiwanie na YouTube, drugi na liście najpopularniejszych transmisji na żywo na platformie. Następnego dnia, na piśmie: z pięciu technik tworzenia kopii zapasowych,

0:25 żadna nie działa niezawodnie. Jak to się dzieje, dlaczego jest to możliwe i kto faktycznie ponosi winę. To jest The Daily Diff, postmortem. 17:20: inżynier tworzy migawkę produkcji w celu przetestowania load balancera na środowisku staging. 19:00: spam uderza w bazę danych, plus zadanie twardo usuwające pracownika GitLab, którego troll zgłosił za nadużycie. 23:00: replika tak bardzo się opóźnia, że główny serwer już odrzucił

0:48 potrzebny log; jedynym rozwiązaniem jest wyczyszczenie repliki i ponowne skopiowanie głównego serwera znowu. pg\_basebackup zawiesza się bez danych wyjściowych. W rzeczywistości czeka, cicho, na główny serwer; nikt o tym nie wie, a runbook o tym nie mówi. Inżynier, który miał wylogować się o jedenastej, decyduje, że pusty katalog danych jest problemem i usuwa go. Na db1. Głównym serwerze. Zauważa sekundę lub dwie później; z około trzystu gigabajtów,

1:11 pozostało 4,5. Kopie zapasowe. Pierwsza: pg\_dump do S3, codziennie. Kubeł jest pusty. Zadanie cron uruchamia się na serwerze aplikacji bez bazy danych, więc pakiet wybiera binaria PostgreSQL 9.2 dla bazy danych 9.6, zawodzi i wysyła e-maile o awarii, które odbijają się z powodu braku DMARC. Druga: migawki dysków Azure, włączone dla serwerów plików, nie dla baz danych.

1:32 Trzecia: replika, celowo wyczyszczona godzinę temu. Czwarta: dzienna migawka, 24-godzinna, każdy webhook usunięty przez synchronizację staging. Piąta: ręczna migawka z 17:20, dla niezwiązanego testu. Ta wygrywa. Przywracanie oznacza skopiowanie dysku staging z powrotem na produkcję za pośrednictwem taniej pamięci masowej Azure z prędkością sześćdziesięciu megabitów na sekundę: osiemnaście godzin. GitLab dot com wraca 1 lutego o 18:00. UTC, z danymi starszymi o sześć godzin.

1:58 git blame: dwie nazwy hostów różniące się o jeden znak i pięć systemów kopii zapasowych, z których nikt nigdy nie przywracał. Nie inżynier. Postmortem, podpisany przez CEO, utrzymuje go anonimowym, koloruje monit produkcyjny na czerwono i nadaje trwałości danych właściciela, ponieważ do tej pory nie miała żadnego. Promień eksplozji: osiemnaście godzin przestoju, sześć godzin danych utraconych, około pięć tysięcy projektów, pięć tysięcy komentarzy,

2:18 siedemset nowych użytkowników i pięć tysięcy osób obserwujących pasek postępu. Hacker News daje dokumentowi na żywo 1162 punkty i cytuje jedną linię z powrotem do nich: z pięciu kopii zapasowych, żadna. Werdykt, postmortem: ship it, w sprawie reakcji. Prowadzą incydent publicznie, obwiniają proces i publikują listę poprawek z numerami problemów. Akcja poniedziałkowa: przywróć kopię zapasową. Jeśli nigdy jej nie przywróciłeś, to jej nie masz.

2:42 Wyślij mi incydent, o którym nadal nie wolno ci rozmawiać, w komentarzach lub na daily diff dot dev. I to jest dzisiejszy diff. Jestem Niko z Axrisi. Łącz odpowiedzialnie.

## Źródła

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