# Інженер видалив виробничу базу даних GitLab. 300 гігабайт.

Published: 2026-09-10

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

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

## Що охоплює це відео

- 31 січня 2017 року: rm -Rvf у каталозі даних основного сервера; видалено ~300 ГБ, залишилося 4,5 ГБ
- 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. І це The Daily Diff за сьогодні. Я Ніко з 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