# Inženýr smazal produkční databázi GitLabu. 300 gigabajtů.

Published: 2026-09-10

31. ledna 2017, 23:27 UTC: Inženýr GitLabu, bojující s poškozenou replikou na konci dlouhé noci, odstraní datový adresář PostgreSQL na db1 namísto db2. db1 je primární. Asi 300 GB databáze GitLab.com je pryč během vteřiny nebo dvou a z pěti zálohovacích a replikačních mechanismů nefunguje žádný. Postmortem: časová osa od špičky spamu po chybný hostname, proč pg\_basebackup vypadal zaseknutý, proč pg\_dump selhával tiše (binární soubory 9.2 na databázi 9.6, e-maily o selhání odražené DMARC), 18hodinové obnovení ze 6hodinového snímku stagingu streamovaného živě na YouTube a kdo skutečně nese vinu. Verdikt k reakci: SHIP IT.

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

## Co toto video pokrývá

- 31. ledna 2017: rm -Rvf v datovém adresáři primárního serveru; odstraněno ~300 GB, zbývá 4.5 GB
- 5 z 5 záloh selhalo: prázdný S3 bucket (nesoulad verzí pg\_dump), žádné snímky Azure na DB, smazaná replika, denní LVM kopie bez webhooků
- 1. února, 18:00 UTC: GitLab.com je zpět z 6hodinového manuálního snímku; živý dokument, živý přenos, bezchybný postmortem se seznamem oprav

## Přeložený přepis

Přeloženo z původního anglického vyprávění. Dostupné audio a titulky jsou řízeny YouTube.

0:00 Inženýr v GitLabu spustí rm -rf na nesprávném databázovém serveru, a tři sta gigabajtů GitLab dot com zmizí během vteřiny nebo dvou, přibližně tak dlouho, jako trvá přečtení názvu hostitele. 31. ledna 2017, 23:27 UTC. GitLab tweetuje, že omylem smazal produkční data, zpřístupní své poznámky k incidentu internetu a streamuje obnovu na YouTube, druhý největší živý přenos na platformě. Následující den, písemně: z pěti zálohovacích technik,

0:25 žádná nefunguje spolehlivě. Jak se to stane, proč je to možné a kdo za to skutečně nese vinu. Toto je The Daily Diff, postmortem. 17:20: inženýr pořídí snímek produkce k testování vyvažovače zátěže ve stagingu. 19:00: spam zatíží databázi, plus úloha tvrdě smaže zaměstnance GitLabu, kterého nahlásil troll za zneužívání. 23:00: replika se tak daleko opozdí, že primární server již zahodil

0:48 potřebný log; jediná oprava je smazat repliku a znovu zkopírovat primární server. pg\_basebackup se zasekne bez výstupu. Ve skutečnosti tiše čeká na primární server; nikdo to neví, a příručka to neuvádí. Inženýr, který se měl odhlásit v jedenáct, se rozhodne, že prázdný datový adresář je problém a odstraní ho. Na db1. Primární server. Všimne si o vteřinu nebo dvě později; zhruba ze tří set gigabajtů,

1:11 zbývá 4.5. Zálohy. Jedna: pg\_dump na S3, denně. Bucket je prázdný. Cron job běží na aplikačním serveru bez databáze, takže balíček vybere binární soubory PostgreSQL 9.2 pro databázi 9.6, selže a odešle e-mail o selhání, který se odrazí kvůli chybějícímu DMARC. Dva: snímky disků Azure, povolené pro souborové servery, nikoli databáze.

1:32 Tři: replika, úmyslně smazaná před hodinou. Čtyři: denní snímek, starý 24 hodin, všechny webhooky odstraněné synchronizací stagingu. Pět: manuální snímek z 17:20, pro nesouvisející test. Ten vyhraje. Obnovení znamená zkopírovat disk stagingu zpět do produkce přes levné úložiště Azure rychlostí šedesát megabitů za sekundu: osmnáct hodin. GitLab dot com je zpět 1. února v 18:00 UTC, o šest hodin starší data.

1:58 git blame: dva názvy hostitelů vzdálené o jeden znak a pět zálohovacích systémů, ze kterých nikdo nikdy neobnovoval. Ne inženýr. Postmortem, podepsaný generálním ředitelem, ho udržuje v anonymitě, obarví produkční výzvu červeně a přidělí vlastníka pro trvanlivost dat, protože dosud žádného neměla. Dosah výbuchu: osmnáct hodin mimo provoz, šest hodin dat pryč, přibližně pět tisíc projektů, pět tisíc komentářů,

2:18 sedm set nových uživatelů a pět tisíc lidí sledujících ukazatel průběhu. Hacker News dává živému dokumentu 1 162 bodů a cituje jeden řádek zpět na ně: z pěti záloh, žádná. Verdikt, postmortem: ship it, k reakci. Veřejně řeší incident, obviňují proces a zveřejňují seznam oprav s čísly problémů. Pondělní akce: obnovit zálohu. Pokud jste ji nikdy neobnovili, žádnou nemáte.

2:42 Pošlete mi incident, o kterém stále nesmíte mluvit, v komentářích, nebo na daily diff dot dev. A to je dnešní diff. Jsem Niko z Axrisi. Spojte se zodpovědně.

## Zdroje

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