# Seorang insinyur menghapus database produksi GitLab. 300 gigabyte.

Published: 2026-09-10

31 Januari 2017, 23:27 UTC: seorang insinyur GitLab, yang berjuang dengan replika yang rusak di penghujung malam yang panjang, menghapus direktori data PostgreSQL di db1 alih-alih db2. db1 adalah primary. Sekitar 300 GB dari database GitLab.com hilang dalam satu atau dua detik, dan dari lima mekanisme pencadangan dan replikasi, tidak ada yang berfungsi. Postmortem: timeline dari lonjakan spam ke nama host yang salah, mengapa pg\_basebackup tampak macet, mengapa pg\_dump telah gagal secara diam-diam (biner 9.2 pada database 9.6, email kegagalan terpental oleh DMARC), pemulihan 18 jam dari snapshot staging berusia 6 jam yang disiarkan langsung di YouTube, dan siapa yang sebenarnya disalahkan. Putusan atas respons: SHIP IT.

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

## Isi video ini

- 31 Jan 2017: rm -Rvf pada direktori data primary; ~300 GB terhapus, 4.5 GB tersisa
- 5 dari 5 cadangan gagal: bucket S3 kosong (ketidakcocokan versi pg\_dump), tidak ada snapshot Azure di DB, replika terhapus, salinan LVM harian tanpa webhook
- 1 Feb, 18:00 UTC: GitLab.com kembali dari snapshot manual berusia 6 jam; dokumen langsung, siaran langsung, postmortem tanpa menyalahkan dengan daftar perbaikan

## Transkrip terjemahan

Diterjemahkan dari narasi asli bahasa Inggris. Audio dan teks tersedia yang dikontrol oleh YouTube.

0:00 Seorang insinyur di GitLab menjalankan rm -rf di server database yang salah, dan tiga ratus gigabyte GitLab dot com lenyap dalam satu atau dua detik, kira-kira selama waktu yang dibutuhkan untuk membaca nama host. 31 Januari 2017, 11:27 malam. UTC. GitLab tweet bahwa mereka secara tidak sengaja menghapus data produksi, membuka catatan insidennya ke internet, dan menyiarkan pemulihan di YouTube, siaran langsung nomor dua di platform tersebut. Hari berikutnya, secara tertulis: dari lima teknik pencadangan,

0:25 tidak ada yang berfungsi dengan andal. Bagaimana itu terjadi, mengapa itu mungkin, dan siapa yang sebenarnya disalahkan. Ini adalah The Daily Diff, postmortem. 17:20: seorang insinyur mengambil snapshot produksi untuk menguji penyeimbang beban di staging. 19:00: spam membanjiri database, ditambah pekerjaan menghapus secara permanen karyawan GitLab yang dilaporkan troll karena penyalahgunaan. 23:00: replika tertinggal begitu jauh sehingga primary sudah membuang

0:48 log yang dibutuhkan; satu-satunya perbaikan adalah menghapus replika dan menyalin primary lagi. pg\_basebackup macet tanpa keluaran. Ini sebenarnya menunggu, secara diam-diam, untuk primary; tidak ada yang tahu itu, dan runbook tidak mengatakannya. Insinyur, yang bermaksud untuk keluar pada pukul sebelas, memutuskan bahwa direktori data kosong adalah masalahnya dan menghapusnya. Di db1. Primary. Dia menyadarinya satu atau dua detik kemudian; dari kira-kira tiga ratus gigabyte,

1:11 4.5 tersisa. Cadangannya. Satu: pg\_dump ke S3, harian. Bucketnya kosong. Pekerjaan cron berjalan di server aplikasi tanpa database, jadi paketnya memilih biner PostgreSQL 9.2 untuk database 9.6, gagal, dan mengirim email kegagalan, yang terpental karena DMARC hilang. Dua: snapshot disk Azure, diaktifkan untuk server file, bukan database.

1:32 Tiga: replika, sengaja dihapus satu jam yang lalu. Empat: snapshot harian, berusia 24 jam, setiap webhook dihapus oleh sinkronisasi staging. Lima: snapshot manual dari 5:20, untuk tes yang tidak terkait. Yang itu menang. Memulihkan berarti menyalin disk staging kembali ke produksi melalui penyimpanan murah Azure dengan enam puluh megabit per detik: delapan belas jam. GitLab dot com kembali 1 Februari pukul enam sore. UTC, data enam jam lebih tua.

1:58 git blame: dua nama host berjarak satu karakter, dan lima sistem pencadangan yang tidak ada yang pernah dipulihkan darinya. Bukan insinyur itu. Postmortem, ditandatangani oleh CEO, menjaga dia tetap anonim, mewarnai prompt produksi merah, dan memberikan kepemilikan ketahanan data, karena sampai sekarang tidak ada. Radius ledakan: delapan belas jam down, data enam jam hilang, sekitar lima ribu proyek, lima ribu komentar,

2:18 tujuh ratus pengguna baru, dan lima ribu orang menonton bilah kemajuan. Hacker News memberikan 1,162 poin pada dokumen langsung dan mengutip satu baris kembali kepada mereka: dari lima cadangan, tidak ada. Putusan, postmortem: SHIP IT, atas responsnya. Mereka menjalankan insiden di depan umum, menyalahkan prosesnya, dan menerbitkan daftar perbaikan dengan nomor masalah. Tindakan Senin: pulihkan cadangan. Jika Anda belum pernah memulihkannya, Anda tidak memilikinya.

2:42 Kirimkan saya insiden yang masih tidak diizinkan untuk Anda bicarakan, di komentar, atau di daily diff dot dev. Dan itulah perbedaannya untuk hari ini. Saya Niko dari Axrisi. Gabungkan dengan bertanggung jawab.

## Sumber

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