Pelajaran Singkat dari Kasus Terhapusnya Production Data Gitlab

Toni Haryanto 3 Februari 2017

Pelajaran Singkat dari Kasus Terhapusnya Production Data Gitlab

Pernahkah Kamu menghapus sebuah data di servermu, atau di komputermu sendiri, atau di flashdisk, yang data itu sangat penting (dokumen bisnis, skripsi/thesis, project source, dsb) dan -sengaja atau tidak- dokumen tersebut terhapus dan akhirnya sadar bahwa dokumen tersebut hanya itu salinan satu-satunya?

Mungkin sebagian besar, atau hampir semua generasi X, Y dan Z yang sudah hidup dengan berkas digital pernah mengalaminya, minimal satu kali seumur hidup. Bisa terbayangkan bukan bagaimana paniknya situasi tersebut. Dan itu situasi yang paling buruk yang tidak ingin dialami siapapun, karena hasil kerja puluhan minggu atau bulan atau bahkan tahun lenyap begitu saja. Tentu selalu ada solusi, restore files, yang bila gagal tetap ada solusi terakhir: menulis ulang. Bagus!

Apa yang Terjadi di Gitlab

Beberapa hari lalu ada berita yang lumayan rame di kalangan programmer, yakni terhapusnya data production di server Gitlab. Bila Kamu menggunakan layanan Gitlab, Kamu pasti tau berita ini. Ceritanya salah seorang Sysadmin Gitlab yang bekerja tengah malam, secara tidak sengaja menghapus direktori selama proses replikasi database yang cukup membuatnya frustasi. Celakanya, dia menghapus di server yang salah. Dia menghapus direktori database berisi 300GB data production yang seharusnya direplikasi.

Bisa Kamu bayangkan bagaimana paniknya data production, data yang sedang live digunakan banyak orang di seluruh dunia, terhapus begitu saja? Saya pernah merasakan bagaimana paniknya, saat secara tidak sengaja pernah menghapus database production CodePolitan beberapa waktu lalu XD. Saat itu saya hendak menghapus satu database yang sudah tidak diperlukan, yang ternyata yang saya klik adalah database production. Mungkin itu juga yang dialami Sysadmin Gitlab pada saat itu, terlebih lagi di tengah malam yang sudah larut dalam kondisi yang sangat lelah.

Sang Sysadmin baru sadar dia telah menghapus direktori yang salah, dan meng-cancel perintah rm -rf tersebut. Data yang tersisa hanya tinggal 4,5GB, dan backup terakhir dari data tersebut yang dapat di-restore adalah 6 jam yang lalu saat insiden terjadi. Berarti paling tidak, ada 6 jam data baru yang bisa dipastikan tidak dapat diselamatkan. Saat insiden tersebut terjadi, website Gitlab down, dan pihak Gitlab langsung mengumumkan situasi yang terjadi melalui akun twitternya di https://twitter.com/gitlabstatus.

Untungnya, meskipun 300GB data terhapus, yang hilang hanyalah data issue dan merge request. Sedangkan data repository project user tetap aman (karena mungkin disimpan di direktori yang berbeda). Itu pun setidaknya ada backup database yang dapat di-restore.

Masalah Lain pada Proses Restore DB

Masalah baru muncul. Dari 5 opsi backup yang mereka sediakan, tidak ada satupun dari kelimanya (berdasarkan dokumen live docs tentang progress restoring db Gitlab) yang dapat digunakan. Mulai dari backup LVM Snapshot dan regular backup yang hanya dilakukan sekali setiap 24 jam, disk snapshot Azure yang hanya membackup server NFS dan tidak membackup server DB, proses dumping dari Postgre yang gagal, hingga backup di S3 yang ternyata kosong. Mereka juga menyadari tidak memiliki sistem pemberitahuan bilamana proses backup gagal.

Untungnya salah satu kru sempat menjalankan LVM snapshot secara manual sekitar 6 jam sebelum insiden terjadi. Dan opsi backup ini yang paling memungkinkan dan paling lengkap untuk di-restore. Paling tidak, hanya data 6 jam terakhir yang sudah pasti tidak dapat diselamatkan.

Tapi ada satu hal yang bagus dan patut dicontoh dari Gitlab. Pada dasarnya karena layanan Git yang diberikan gratis, Gitlab bisa saja tidak terlalu mempermasalahkan insiden ini. Tapi dengan begitu tentu akan mencederai kepercayaan dan profesionalitas di mata pengguna. Tapi Gitlab justru tidak hanya sekedar meminta maaf dan memperbaiki masalah, tapi juga menghadirkan informasi yang transparan terkait permasalahan yang terjadi dan solusi yang dilakukan. Mereka bahkan menyediakan live doc dan live tweet yang dapat kita pantau sepanjang progres perbaikan sistem mereka, dan juga Youtube Live Stream selama para kru menyelesaikan perbaikan.

Pelajaran Penting

Proses backup data bukan task yang sepele, terutama bila Kamu belum pernah mengalami bagaimana merananya kehilangan data penting yang tidak dapat diselamatkan. Terlebih lagi bila urusannya dengan bisnis yang mana data tersebut harus kita pertanggungjawabkan kepada klien kita. Setelah insiden serupa yang juga sempat kami alami di CodePolitan, kami mulai merapikan proses backup data dan membuat opsi lebih dari satu, tidak hanya bergantung pada proses backup reguler yang disediakan provider.

Setidaknya ada 4 hal yang ingin saya sampaikan terkait isu yang kita bahas pada artikel ini:

Selalu Pasang Opsi Backup

Backup adalah hal yang wajib bila Kamu punya data penting. Dan upayakan untuk selalu sediakan salinan lebih dari dua opsi. Misalnya bila Kamu punya dokumen office yang harus disarsipkan, simpanlah di beberapa tempat: lokal komputer, harddisk eksternal, layanan Git online, Dropbox, Google Drive atau OneDrive.

Bila Kamu punya project online di servermu, siapkan mekanisme duplikasi database atau dumping database serta upload ke media penyimpanan lain seperti S3 atau layanan Git seperti Github, Gitorious, Gitlab dan lain sebagainya.

Pastikan Backup Dapat Di-restore

Meskipun Kamu sudah menyediakan beberapa opsi, Kamu harus tetap mengecek apakah hasil backup dapat direstore. Bila bentuknya database dumping, pastikan dapat direstore dengan lancar dengan mengetesnya di komputer lokal. Bila Kamu menggunakan layanan hosting VPS, pastikan ke provider hosting yang Kamu gunakan bahwa mereka memiliki storage atau VM backup. Belajar dari kasus Gitlab, ada baiknya Kamu membuat alert system yang dapat memberitahumu bilamana proses backup gagal sehingga Kamu bisa cepat memperbaiki masalah tersebut.

Delete adalah Hal Tabu di Server Production

Jangan mudah menghapus file atau data di server production! Meskipun Kamu sudah menyediakan opsi backup, menghapus hal yang krusial akan menghabiskan waktumu untuk hal yang sebenarnya tidak perlu. Hindari sebisa mungkin proses deleting apapun di server production. Pada dasarnya server production harus clean sejak pertama dibangun. Kalaupun Kamu harus membersihkan beberapa hal, PASTIKAN Kamu menghapus hal yang memang Kamu sadari itu harus dihapus. Upayakan sesadar mungkin saat hendak menghapus sesuatu. Pokoknya jangan mudah menghapus.

Referensi:

Cover: http://cybercorsolutions.com/web/sites/all/themes/socialstyle/images/is-u.jpg

Tags
Opinigitlabbackuprestoregitlab-down
Share to
FacebookTwitterLinkedIn