# Инженер GitLab-тың өндірістік дерекқорын жойды. 300 гигабайт.

Published: 2026-09-10

2017 жылғы 31 қаңтар, UTC 23:27: GitLab инженері ұзақ түннің соңында сынған репликамен күресіп, db2 орнына db1-дегі PostgreSQL деректер каталогын жояды. db1 — негізгі. GitLab.com дерекқорының шамамен 300 ГБ бір-екі секундта жоғалып кетеді, ал бес сақтық көшіру және репликация механизмдерінің ешқайсысы жұмыс істемейді. Постмортем: спамның өсуінен қате хост атауына дейінгі уақыт кестесі, pg\_basebackup неге тұрып қалғандай көрінді, pg\_dump неге үнсіз сәтсіздікке ұшырады (9.6 дерекқорындағы 9.2 екілік файлдары, сәтсіздік туралы электрондық пошталар DMARC арқылы кері қайтарылды), YouTube-те тікелей трансляцияланған 6 сағаттық ескі сынақ сәтінен 18 сағаттық қалпына келтіру және кінәні кім алады. Жауапқа қатысты үкім: SHIP IT.

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

## Бұл бейне не туралы

- 2017 ж. 31 қаңтар: негізгі деректер каталогында 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 dot com-ның үш жүз гигабайты бір-екі секундта жоғалады, хост атауын оқуға кететін уақытқа жуық. 2017 жылғы 31 қаңтар, 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-і қалады. Сақтық көшірулер. Бірінші: S3-ке pg\_dump, күнделікті. Шелек бос. Крон жұмысы дерекқорсыз қолданба серверінде іске қосылады, сондықтан пакет 9.6 дерекқоры үшін PostgreSQL 9.2 екілік файлдарын таңдайды, сәтсіз аяқталады және сәтсіздік туралы хабарлама жібереді, ол DMARC жетіспеуіне байланысты кері қайтарылады. Екінші: Azure дискілік суреттері, файл серверлері үшін қосылған, дерекқорлар үшін емес.

1:32 Үшінші: реплика, бір сағат бұрын әдейі тазартылған. Төртінші: күнделікті сурет, 24 сағаттық, әрбір вебхук сынақ синхрондауы арқылы жойылған. Бесінші: 17:20-дағы қолмен жасалған сурет, байланыссыз сынақ үшін. Сол жеңеді. Қалпына келтіру дегеніміз - Azure-дің арзан сақтау орны арқылы сынақ дискісін өндіріске секундына алпыс мегабит жылдамдықпен көшіру: он сегіз сағат. GitLab dot com 1 ақпан сағат 18:00-де қайта оралады. UTC, алты сағаттық деректер ескірген.

1:58 git blame: бір таңбаға айырмашылығы бар екі хост атауы және ешкім бұрын қалпына келтірмеген бес сақтық көшіру жүйесі. Инженер емес. Бас директор қол қойған постмортем оны анонимді ұстайды, өндірістік сұраныс терезесін қызыл түспен бояп, деректер тұрақтылығына иесін береді, өйткені бұған дейін оның иесі болмаған. Жойылған аумақ: он сегіз сағат жұмыс істемеді, алты сағаттық деректер жоғалды, шамамен бес мың жоба, бес мың түсініктеме,

2:18 жеті жүз жаңа пайдаланушы және үлгерім жолағын қарап отырған бес мың адам. Hacker News тікелей құжатқа 1,162 ұпай беріп, олардан бір жолды келтіреді: бес сақтық көшірудің ешқайсысы да жұмыс істемейді. Үкім, постмортем: жауап бойынша 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