# Инженер изтри производствената база данни на GitLab. 300 гигабайта.

Published: 2026-09-10

31 януари 2017 г., 23:27 UTC: инженер на GitLab, борейки се с повредена реплика в края на дълга нощ, премахва директорията с данни на PostgreSQL на db1 вместо на db2. db1 е основната. Около 300 GB от базата данни на GitLab.com изчезват за секунда или две, а от петте механизма за архивиране и репликация нито един не работи. Посмъртен анализ: времевата линия от скока на спам до грешното име на хост, защо pg\_basebackup изглеждаше заседнал, защо pg\_dump мълчаливо се проваляше (9.2 бинарни файлове на база данни 9.6, имейли за отказ от DMARC), 18-часовото възстановяване от 6-часова моментна снимка на стейджинг, предавана на живо в YouTube, и кой всъщност е виновен. Присъда за отговора: SHIP IT.

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

## Какво обхваща този видеоклип

- 31 януари 2017 г.: rm -Rvf върху директорията с данни на основната; ~300 GB премахнати, останали 4,5 GB
- 5 от 5 архива не работят: празен S3 кош (несъответствие във версията на pg\_dump), без Azure моментни снимки на базата данни, изтрита реплика, ежедневно LVM копие без уебхукове
- 1 февруари, 18:00 UTC: GitLab.com се възстановява от 6-часова ръчна моментна снимка; документ на живо, предаване на живо, безпристрастен посмъртен анализ със списък с корекции

## Преведен препис

Преведено от оригиналния английски разказ. Наличните аудио и субтитри се контролират от YouTube.

0:00 Инженер от GitLab изпълнява rm -rf на грешния сървър на базата данни, и триста гигабайта от GitLab.com изчезват за секунда или две, приблизително толкова време, колкото е необходимо за прочитане на име на хост. 31 януари 2017 г., 23:27 ч. UTC. GitLab туитва, че по погрешка е изтрил производствени данни, отваря своите бележки за инциденти за интернет и предава възстановяването на живо в YouTube, вторият най-гледан поток на живо в платформата. На следващия ден, писмено: от пет техники за архивиране,

0:25 нито една не работи надеждно. Как се случва, защо е възможно и кой всъщност е виновен. Това е The Daily Diff, посмъртен анализ. 17:20 ч.: инженер прави моментна снимка на производството за тестване на балансьор на натоварването в стейджинг. 19:00 ч.: спам атакува базата данни, плюс задача за твърдо изтриване на служител на GitLab, съобщен от трол за злоупотреба. 23:00 ч.: репликата изостава толкова много, че основната вече е изхвърлила

0:48 лога, от който се нуждае; единственото решение е да се изтрие репликата и да се копира основната отново. pg\_basebackup виси без изход. Всъщност чака мълчаливо основната; никой не знае това, и наръчникът не го казва. Инженерът, който е трябвало да приключи в единадесет, решава, че празната директория с данни е проблемът и я премахва. На db1. Основната. Забелязва секунда или две по-късно; от приблизително триста гигабайта,

1:11 остават 4,5. Архивите. Едно: pg\_dump към S3, ежедневно. Кошът е празен. Задачата cron се изпълнява на приложен сървър без база данни, така че пакетът избира PostgreSQL 9.2 бинарни файлове за база данни 9.6, не успява и изпраща имейли за неуспеха, които отскачат поради липсващ DMARC. Две: моментни снимки на Azure диск, активирани за файловите сървъри, не за базите данни.

1:32 Три: репликата, изтрита нарочно преди час. Четири: ежедневната моментна снимка, на 24 часа, всеки уебхук премахнат от синхронизацията на стейджинг. Пет: ръчната моментна снимка от 17:20, за несвързан тест. Тази печели. Възстановяването означава копиране на стейджинг диска обратно в производството през евтиното хранилище на Azure при шейсет мегабита в секунда: осемнадесет часа. GitLab.com се връща на 1 февруари в шест вечерта UTC, данни на шест часа.

1:58 git blame: две имена на хостове с един символ разлика и пет системи за архивиране, от които никой никога не е възстановявал. Не инженерът. Посмъртният анализ, подписан от изпълнителния директор, го запазва анонимен, оцветява червено производствения промпт и дава на устойчивостта на данните собственик, защото досега нямаше такъв. Радиус на взрива: осемнадесет часа прекъсване, шест часа данни изчезнали, приблизително пет хиляди проекта, пет хиляди коментара,

2:18 седемстотин нови потребители и пет хиляди души, гледащи лента за напредък. Hacker News дава на документа на живо 1162 точки и цитира един ред обратно към тях: от пет архива, нито един. Присъда, посмъртен анализ: SHIP IT, относно отговора. Те управляват инцидента публично, обвиняват процеса и публикуват списъка с корекции с номера на проблемите. Действие за понеделник: възстановяване на архив. Ако никога не сте го възстановявали, нямате такъв.

2:42 Изпратете ми инцидента, за който все още не ви е позволено да говорите, в коментарите или на daily diff dot dev. И това е разликата за днес. Аз съм Нико от Axrisi. Обединявайте отговорно.

## Източници

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