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 risikonya 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 jelek yang tidak ingin dialami siapapun, alasannya yaitu hasil kerja puluhan minggu atau bulan atau bahkan tahun lenyap begitu saja. Tentu selalu ada solusi, restore files, yang jikalau gagal tetap ada solusi terakhir: menulis ulang. Bagus!
Apa yang Terjadi di Gitlab
Beberapa hari kemudian ada isu yang tidak mengecewakan rame di kalangan programmer, yakni terhapusnya data production di server Gitlab. Bila Kamu memakai layanan Gitlab, Kamu niscaya 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 baru 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 sanggup di-restore yaitu 6 jam yang kemudian saat insiden terjadi. Berarti paling tidak, ada 6 jam data baru yang bisa dipastikan tidak sanggup 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 kondusif (karena mungkin disimpan di direktori yang berbeda). Itu pun setidaknya ada backup database yang sanggup 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 perihal progress restoring db Gitlab) yang sanggup 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 mempunyai 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 niscaya tidak sanggup diselamatkan.
Tapi ada satu hal yang mengagumkan dan patut dicontoh dari Gitlab. Pada dasarnya alasannya yaitu 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 sanggup kita pantau sepanjang progres perbaikan sistem mereka, dan juga Youtube Live Stream selama para kru menuntaskan perbaikan.
Pelajaran Penting
Proses backup data bukan task yang sepele, terutama jikalau Kamu belum pernah mengalami bagaimana merananya kehilangan data penting yang tidak sanggup diselamatkan. Terlebih lagi jikalau 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 menciptakan 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 yaitu hal yang wajib jikalau Kamu punya data penting. Dan upayakan untuk selalu sediakan salinan lebih dari dua opsi. Misalnya jikalau 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 prosedur duplikasi database atau dumping database serta upload ke media penyimpanan lain ibarat S3 atau layanan Git ibarat Github, Gitorious, Gitlab dan lain sebagainya.
Pastikan Backup Dapat Di-restore
Meskipun Kamu sudah menyediakan beberapa opsi, Kamu harus tetap mengecek apakah hasil backup sanggup direstore. Bila bentuknya database dumping, pastikan sanggup direstore dengan lancar dengan mengetesnya di komputer lokal. Bila Kamu memakai layanan hosting VPS, pastikan ke provider hosting yang Kamu gunakan bahwa mereka mempunyai storage atau VM backup. Belajar dari perkara Gitlab, ada baiknya Kamu menciptakan alert system yang sanggup memberitahumu bilamana proses backup gagal sehingga Kamu bisa cepat memperbaiki dilema tersebut.
Delete yaitu Hal Tabu di Server Production
Jangan gampang menghapus file atau data di server production! Meskipun Kamu sudah menyediakan opsi backup, menghapus hal yang krusial akan menghabiskan waktumu untuk hal yang sebetulnya 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 gampang menghapus.
Sumber: Coding-Arena
Sumber: Coding-Arena
Tidak ada komentar:
Posting Komentar