Backup Data Bisnis: Kenapa Uji Pemulihan Sama Pentingnya

Hampir semua pemilik usaha setuju bahwa data harus di-backup. Data pelanggan, pesanan, pembayaran, dan riwayat transaksi adalah bagian dari nilai bisnis Anda. Masalahnya, banyak bisnis baru sadar backup-nya rusak, tidak lengkap, atau tidak bisa dibuka justru saat data sudah hilang.

Artikel ini membahas kenapa hal itu terjadi, seperti apa backup yang layak, dan kenapa uji pemulihan sama pentingnya dengan backup itu sendiri. Contohnya diambil dari Numekara, bisnis pendidikan milik pemilik Lumekara, yang menjalankan backup harian dan latihan pemulihan untuk database produksinya.

Kenapa backup sering gagal saat dibutuhkan

Backup jarang gagal karena satu kesalahan besar. Biasanya penyebabnya hal kecil yang tidak pernah dicek:

• Tidak pernah dicoba dipulihkan. File backup ada, tetapi tidak ada yang tahu apakah file itu benar-benar bisa dipakai.
• Disimpan di tempat yang sama. Backup berada di server yang sama dengan data aslinya. Saat server bermasalah, keduanya hilang bersamaan.
• Tidak lengkap. Hanya sebagian tabel atau sebagian file yang ikut, dan kekurangannya baru ketahuan saat dibutuhkan.
• Kunci atau kata sandinya hilang. Backup terenkripsi tidak berguna kalau tidak ada yang menyimpan kunci pembukanya dengan aman.
• Berhenti diam-diam. Jadwal backup gagal berjalan berminggu-minggu, tetapi tidak ada yang diberi tahu.
• Prosedurnya hanya ada di kepala satu orang. Saat orang itu tidak ada, tidak ada yang tahu langkah pemulihannya.

Ciri backup yang layak

Backup yang baik tidak harus mahal, tetapi perlu memenuhi beberapa syarat dasar:

• Otomatis dan terjadwal. Backup berjalan sendiri, misalnya setiap hari, tanpa bergantung pada ingatan seseorang.
• Terenkripsi. Isi backup tidak bisa dibaca oleh orang yang tidak berhak, bahkan jika filenya bocor.
• Disimpan di luar server utama. Gunakan penyimpanan terpisah, sehingga masalah di server utama tidak ikut menghapus backup.
• Punya checksum. Checksum adalah sidik digital file. Dengan membandingkannya, Anda tahu apakah file backup masih utuh atau sudah rusak.
• Statusnya terpantau. Ada tempat untuk melihat kapan backup terakhir berhasil, dan peringatan jika gagal.

Di Numekara, sebuah workflow harian membuat salinan database, mengenkripsinya, membuat checksum, lalu mengirimnya ke penyimpanan terpisah di Cloudflare R2. Status backup juga tampil di halaman admin bersama pemantauan galat, sehingga pemilik tidak perlu menebak apakah backup semalam berjalan.

Seberapa sering, dan berapa lama disimpan?

Cara termudah menentukan jadwal backup adalah bertanya: berapa banyak data yang rela Anda kehilangan? Kalau kehilangan pesanan satu hari masih bisa ditelusuri ulang dari email dan mutasi rekening, backup harian sudah memadai. Kalau transaksi masuk setiap menit, Anda mungkin perlu jadwal yang lebih rapat atau fitur pemulihan bawaan dari penyedia database.

Simpan juga beberapa versi lama, bukan hanya yang terbaru. Kesalahan data, misalnya pesanan terhapus tanpa sengaja, sering baru ketahuan beberapa hari kemudian. Saat itu, backup semalam sudah ikut memuat kesalahannya.

Uji pemulihan: satu-satunya bukti backup berfungsi

Uji pemulihan, atau restore drill, adalah latihan memulihkan backup ke tempat terpisah untuk membuktikan datanya benar-benar bisa kembali. Ini mirip latihan evakuasi kebakaran: tujuannya menemukan masalah saat situasi masih tenang, bukan saat panik.

1. Ambil file backup terbaru dari penyimpanan di luar server, sama seperti saat keadaan darurat.
2. Cocokkan checksum sebelum membuka apa pun, untuk memastikan file tidak rusak dalam perjalanan.
3. Buka enkripsinya dengan kunci yang disimpan sesuai prosedur.
4. Pulihkan ke database kosong yang terpisah dari produksi.
5. Periksa hasilnya: apakah tabel penting ada, apakah jumlah datanya masuk akal, dan apakah akun pengguna ikut kembali.
6. Catat hasilnya, termasuk masalah yang ditemukan dan perbaikannya.

Ada satu pengaman yang wajib: latihan tidak boleh menyentuh database produksi. Skrip latihan pemulihan di Numekara dibuat untuk menolak berjalan jika diarahkan ke database produksi.

Cerita nyata: latihan yang sempat gagal

Pada latihan pemulihan kedua Numekara tanggal 15 Oktober 2026, backup produksi diambil langsung dari penyimpanan off-site. Pengunduhan, pengecekan checksum, dan pembukaan enkripsi semuanya lancar. Tetapi percobaan pertama gagal di tahap pemulihan, karena salinan database memuat objek bawaan dari platform database yang dipakai, dan objek itu tidak tersedia di database biasa tempat latihan dijalankan.

Skrip kemudian diperbaiki agar melewati objek milik platform saja, sementara data aplikasi dan akun pengguna tetap dipulihkan penuh. Percobaan berikutnya dengan file backup yang sama dinyatakan lulus, dan hasilnya dicatat sebagai bukti tertulis.

Pelajarannya sederhana. Backup itu sendiri sebenarnya baik, tetapi tanpa latihan, masalah di prosedur pemulihan baru akan ketahuan saat keadaan darurat sungguhan. Latihan memberi waktu untuk memperbaikinya dengan tenang.

Langkah berikutnya

Ajukan tiga pertanyaan kepada tim atau pengembang Anda: di mana backup disimpan, kapan terakhir berhasil, dan kapan terakhir kali dicoba dipulihkan. Kalau pertanyaan terakhir belum bisa dijawab, jadwalkan latihan pemulihan pertama. Setelah itu, ulangi secara berkala dan setiap kali ada perubahan besar pada sistem.