Latest News

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 kesannya 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, alasannya ialah hasil kerja puluhan ahad atau bulan atau bahkan tahun lenyap begitu saja. Tentu selalu ada solusi, restore files, yang jika gagal tetap ada solusi terakhir: menulis ulang. Bagus!


Apa yang Terjadi di Gitlab​

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

Sang Sysadmin gres sadar ia 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 ialah 6 jam yang lalu ketika insiden terjadi. Berarti paling tidak, ada 6 jam data gres yang mampu dipastikan tidak dapat diselamatkan. Saat insiden tersebut terjadi, website Gitlab down, dan pihak Gitlab eksklusif 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 gres muncul. Dari 5 opsi backup yang mereka sediakan, tidak ada satupun dari kelimanya (berdasarkan dokumen live docs wacana 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 mengagumkan dan patut dicontoh dari Gitlab. Pada dasarnya alasannya ialah layanan Git yang diberikan gratis, Gitlab mampu 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 jika Kamu belum pernah mengalami bagaimana merananya kehilangan data penting yang tidak dapat diselamatkan. Terlebih lagi jika urusannya dengan bisnis yang mana data tersebut harus kita pertanggungjawabkan kepada klien kita. Setelah insiden serupa yang juga sempat kami alami di Coding-Arena, 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 ialah hal yang wajib jika Kamu punya data penting. Dan upayakan untuk selalu sediakan salinan lebih dari dua opsi. Misalnya jika 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 menyerupai S3 atau layanan Git menyerupai 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 mampu cepat memperbaiki persoalan tersebut.

Delete ialah 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 bergotong-royong tidak perlu. Hindari sebisa mungkin proses deleting apapun di server production. Pada dasarnya server production harus clean semenjak pertama dibangun. Kalaupun Kamu harus membersihkan beberapa hal, PASTIKAN Kamu menghapus hal yang memang Kamu sadari itu harus dihapus. Upayakan sesadar mungkin ketika hendak menghapus sesuatu. Pokoknya jangan mudah menghapus.

Sumber: Coding-Arena