Setiap pemilik bisnis selalu bilang mereka punya backup. Hampir tidak ada yang pernah menguji proses restore-nya. Disaster recovery untuk bisnis kecil bukan soal membeli tooling enterprise yang mahal, melainkan menutup jarak antara "kami punya backup" dan "kami sudah membuktikan bisnis ini bisa jalan lagi setelah sesuatu rusak." Jarak itulah tempat sebagian besar bencana nyata terjadi, dan menutupnya tidak butuh biaya apa pun selain waktu satu sore.

Saya pernah melihat perusahaan multifinance yang baru sadar, saat server mereka benar-benar gagal, bahwa script backup malam harinya sudah diam-diam gagal selama tiga bulan. Tidak ada yang memeriksa karena tidak ada yang pernah butuh melakukan restore. Backup-nya ada. Tapi tidak berguna. Itulah mode kegagalan paling umum dalam disaster recovery untuk bisnis kecil, dan sepenuhnya bisa dicegah.

Backup yang belum diuji hanyalah rasa aman semu

Backup yang belum pernah di-restore adalah hipotesis, bukan jaring pengaman. Proses backup bisa gagal secara diam-diam kapan saja: kredensial kedaluwarsa, disk penuh, perubahan skema merusak script export, atau izin akses di cloud storage berubah tanpa disadari. Semua ini tidak akan ketahuan kecuali seseorang benar-benar mencoba memakai backup tersebut.

Solusinya bukan menambah jumlah backup. Solusinya adalah uji restore triwulanan: setiap tiga bulan sekali, ambil satu backup terbaru dan benar-benar lakukan restore, idealnya ke lingkungan terpisah, lalu pastikan datanya lengkap dan bisa dipakai. Ini hanya butuh setengah hari untuk kebanyakan bisnis kecil, dan ini adalah aktivitas disaster recovery dengan leverage tertinggi yang bisa Anda lakukan, jauh lebih berharga daripada menambah frekuensi backup atau redundansi penyimpanan.

Apa arti "di luar lokasi" yang sesungguhnya

Backup yang disimpan di lokasi fisik yang sama dengan sistem utama Anda hanya melindungi dari kegagalan hardware. Backup semacam itu tidak melindungi Anda dari kebakaran, banjir, pencurian, atau ransomware yang mengenkripsi semua yang bisa dijangkaunya di jaringan, termasuk drive backup yang terpasang. Inilah skenario ancaman realistis untuk bisnis kecil: bukan hantaman meteor yang hipotetis, melainkan pipa bocor di ruang server yang berbarengan dengan email phishing yang membuat laptop staf terenkripsi di bulan yang sama.

Standar minimum praktis untuk disaster recovery di luar lokasi:

  • Otomatis, bukan manual. Jika proses backup bergantung pada seseorang yang ingat mencolokkan drive, cepat atau lambat itu tidak akan terjadi. Gunakan backup terjadwal otomatis ke cloud storage.
  • Terpisah secara geografis. Cloud storage di wilayah fisik yang berbeda, atau minimal di gedung yang berbeda, dari server utama Anda.
  • Akses terisolasi. Kredensial penyimpanan backup tidak boleh sama dengan kredensial yang punya akses tulis ke sistem produksi. Jika ransomware membobol jaringan utama Anda, ia seharusnya tidak bisa menjangkau dan mengenkripsi backup Anda juga.
  • Bervarian, bukan ditimpa. Simpan setidaknya 30 hari snapshot point-in-time, bukan sekadar "backup terbaru", supaya korupsi data yang berjalan pelan atau infeksi ransomware tidak ikut ter-backup menimpa satu-satunya salinan bersih yang Anda punya.

Rencana satu halaman mengalahkan kebijakan 40 halaman

Sebagian besar dokumentasi disaster recovery yang tidak pernah dibaca siapa pun tersimpan dalam folder sebagai dokumen kebijakan 40 halaman yang dibuat untuk audit kepatuhan. Saat sesuatu benar-benar rusak jam 11 malam, tidak ada yang membukanya. Yang benar-benar dipakai dalam insiden nyata adalah satu halaman yang secara konseptual "ditempel" di kepala semua orang: siapa melakukan apa, dalam urutan seperti apa.

Rencana satu halaman yang bisa dipakai harus menjawab:

  1. Siapa yang menyatakan ini insiden, dan siapa yang pertama kali mereka hubungi?
  2. Di mana kredensial backup disimpan, dan siapa yang punya akses saat ini, bukan siapa yang dulu punya?
  3. Apa urutan sistem yang harus dipulihkan (biasanya: sistem transaksi inti lebih dulu, laporan dan analitik belakangan)?
  4. Berapa lama downtime yang masih bisa ditoleransi sebelum harus eskalasi ke penyedia hosting atau spesialis?
  5. Siapa yang berkomunikasi dengan pelanggan atau mitra selama gangguan berlangsung, dan dengan pesan seperti apa?

Cetak. Taruh di tempat fisik, jangan hanya di sistem yang mungkin justru sedang down.

Sesuaikan kecepatan recovery dengan kemampuan bisnis menanggungnya

Tidak semua sistem butuh kecepatan recovery yang sama. Sistem point-of-sale sebuah jaringan ritel yang down selama dua jam di jam operasional adalah keadaan darurat pendapatan. Portal HR internal jaringan yang sama, jika down dua jam, hanyalah ketidaknyamanan. Disaster recovery untuk bisnis kecil berarti jujur soal hierarki ini dan mengarahkan anggaran serta perhatian yang terbatas ke sistem-sistem yang downtime-nya benar-benar merugikan secara finansial, alih-alih memperlakukan semua sistem sama pentingnya. Ini disiplin prioritas yang sama seperti yang muncul di Technical Debt Dijelaskan untuk Pemilik Bisnis, di mana tidak semua sistem lawas juga layak mendapat urgensi yang sama.

Ransomware mengubah perhitungannya

Ransomware secara spesifik menyasar backup, karena pelaku tahu backup adalah hal yang bisa membuat Anda menolak membayar tebusan. Jika strategi backup Anda hanya mengasumsikan kegagalan hardware, Anda sedang merencanakan bencana dekade lalu. Poin isolasi akses di atas (kredensial backup terpisah dari kredensial produksi) adalah pertahanan paling penting di sini. Jika penyerang yang membobol sistem utama Anda juga bisa menghapus atau mengenkripsi backup Anda, Anda sebenarnya tidak punya strategi backup, Anda punya single point of failure yang tertunda.

Intinya

Disaster recovery untuk bisnis kecil bermuara pada tiga kebiasaan yang tidak glamor: otomatisasi backup di luar lokasi dengan isolasi akses yang nyata, benar-benar melakukan restore dari backup sekali per triwulan untuk membuktikan itu berfungsi, dan menulis rencana satu halaman yang bisa diikuti karyawan yang sedang panik di tengah malam. Semua ini tidak butuh anggaran enterprise. Yang dibutuhkan hanyalah memperlakukan "kami punya backup" sebagai klaim yang perlu diuji, bukan fakta yang bisa begitu saja diasumsikan.