Backup sering dianggap selesai ketika sudah ada file arsip di server. Yang menentukan sebenarnya adalah apakah data bisa dipulihkan dalam waktu yang dapat diterima. Backup yang tidak pernah diuji sama saja dengan dugaan.
Mengapa backup sering gagal saat dibutuhkan
- Backup hanya disimpan di server yang sama dengan website. Jika server rusak atau diretas, backup ikut hilang.
- Database tidak ikut dibackup, atau dibackup dalam kondisi rusak.
- Restore tidak pernah dicoba, sehingga masalah baru ketahuan saat keadaan darurat.
- Backup berjalan setiap hari, tetapi tidak ada yang memeriksa apakah prosesnya berhasil.
Aturan 3-2-1
Aturan ini adalah pedoman umum yang banyak dipakai:
- 3 salinan data: satu data asli dan dua salinan backup.
- 2 media penyimpanan yang berbeda.
- 1 salinan disimpan di lokasi terpisah (off-site).
Untuk website berskala kecil, “media berbeda” bisa berarti penyimpanan di server lain atau layanan object storage. Yang penting, kegagalan satu tempat tidak otomatis menghapus semua salinan.
Data apa saja yang perlu dibackup?
- File website: folder aplikasi dan unggahan media.
- Database: dump terjadwal yang bisa dibuka dan dipulihkan.
- Konfigurasi: file environment, konfigurasi web server, dan daftar cron job.
- Sertifikat dan kunci: disimpan di tempat yang aman dengan akses terbatas.
- Catatan akses dan DNS: disimpan dalam dokumen terpisah, bukan hanya di kepala satu orang.
Langkah praktis menyusun backup
- Tentukan target pemulihan. Tentukan berapa lama data boleh hilang (misalnya 24 jam) dan berapa lama website boleh tidak aktif. Angka ini menentukan frekuensi backup.
- Jadwalkan backup database dan file sesuai target tersebut.
- Simpan beberapa versi. Jika hanya ada satu salinan terbaru, malware atau data yang rusak bisa ikut tersalin. Simpan riwayat beberapa hari atau minggu.
- Simpan salinan off-site dengan kredensial yang terpisah dari server utama.
- Uji restore secara berkala, misalnya tiga bulan sekali atau setiap ada perubahan besar. Pulihkan ke lingkungan terpisah, lalu periksa halaman utama, proses login, dan fitur transaksi jika ada.
- Pantau hasil backup. Notifikasi kegagalan harus sampai ke orang yang bertanggung jawab.
Jika website terkena malware
Jangan langsung memulihkan backup paling baru tanpa pemeriksaan. Backup terbaru bisa sudah memuat file yang terinfeksi. Pilih versi yang dibuat sebelum tanggal infeksi, bersihkan website, lalu ubah semua kata sandi dan kunci akses yang mungkin terekspos.
Ringkasnya
Backup yang baik memiliki tiga ciri: tersimpan di lebih dari satu tempat, mencakup database dan konfigurasi, serta pernah diuji untuk dipulihkan. Mulailah dengan memeriksa satu hal: sudahkah Anda memulihkan website dari backup ke lingkungan lain dalam setahun terakhir?
Jika website Anda berjalan di layanan CakraCloud, periksa detail backup pada paket dan cakupan layanan Anda, lalu tanyakan kepada tim kami melalui halaman Kontak jika ada yang belum jelas.
Contoh skema backup untuk toko online kecil
Misalkan sebuah toko online menerima pesanan setiap hari dan tidak boleh kehilangan lebih dari satu hari data. Skema yang masuk akal bisa seperti ini:
- Database: dump setiap malam, disimpan selama 14 hari, dengan salinan mingguan yang disimpan selama tiga bulan.
- File unggahan: sinkronisasi harian ke penyimpanan terpisah, karena foto produk biasanya berubah lebih jarang daripada pesanan.
- Konfigurasi: salinan setiap kali ada perubahan pada file environment atau konfigurasi web server.
- Salinan off-site: satu salinan lengkap setiap minggu di lokasi yang berbeda dari server utama.
Angka retensi di atas hanyalah contoh. Sesuaikan dengan seberapa cepat masalah biasanya ketahuan dan kebutuhan pencatatan transaksi Anda.
Kesalahan umum saat membuat backup
Beberapa kesalahan ini sering ditemukan saat pemilik website mencoba memulihkan data:
- Backup hanya berisi file, bukan database. Website tampak utuh, tetapi pesanan, akun, dan pengaturan hilang.
- Dump database dibuat saat data sedang berubah. Gunakan opsi yang menjaga konsistensi, atau jadwalkan backup di jam yang paling sepi.
- Backup menyimpan kata sandi di tempat yang sama. Jika akun penyimpanan diretas, semua salinan ikut hilang. Gunakan kredensial terpisah dan aktifkan autentikasi dua faktor.
- Tidak ada yang tahu kalau backup gagal. Pastikan notifikasi kegagalan dikirim ke orang yang bertanggung jawab, bukan hanya ke folder log.
- Retensi terlalu pendek. Jika malware baru terdeteksi setelah dua minggu, salinan terbaru bisa sudah terinfeksi dan semua versi aman sudah dihapus.
Langkah uji pemulihan yang sederhana
Uji restore tidak harus rumit. Lakukan langkah berikut di lingkungan terpisah, misalnya subdomain sementara atau server uji:
- Ambil salinan database dan file dari backup terbaru.
- Pulihkan ke lingkungan uji dan catat berapa lama proses ini berlangsung.
- Buka halaman utama, halaman produk, proses login, dan satu transaksi uji jika memungkinkan.
- Bandingkan jumlah data utama, misalnya jumlah pesanan atau jumlah pengguna, dengan kondisi sebelum backup.
- Tulis hasilnya, termasuk masalah yang ditemukan, dan perbarui prosedur jika perlu.
Waktu yang tercatat dari langkah pertama sampai ketiga adalah perkiraan waktu pemulihan Anda. Jika waktu itu tidak bisa diterima oleh bisnis, berarti strategi backup perlu diubah.
Catat setiap perubahan besar
Simpan catatan singkat setiap kali ada perubahan besar, seperti pembaruan plugin utama, pindah tema, atau perubahan versi PHP. Catatan ini membantu Anda memilih titik pemulihan yang tepat. Jika website bermasalah sehari setelah perubahan, Anda tahu salinan mana yang sebaiknya dipakai, dan tidak perlu menebak dari daftar file yang tidak jelas.
Pertanyaan yang sering diajukan
Seberapa sering backup website sebaiknya dilakukan?
Tergantung seberapa banyak data yang boleh hilang. Website company profile yang jarang berubah cukup dibackup mingguan. Toko online yang menerima transaksi setiap hari sebaiknya dibackup lebih sering, bahkan harian.
Apakah backup dari panel hosting sudah cukup?
Belum tentu. Pastikan lokasi penyimpanannya, berapa lama versi disimpan, dan bagaimana proses restore-nya. Jika salinan hanya berada di server yang sama dengan website, aturan 3-2-1 belum terpenuhi.
Apakah saya perlu backup sendiri jika penyedia sudah membuat backup?
Sebaiknya tetap ada salinan yang Anda pegang sendiri untuk data penting. Tanyakan kepada penyedia tentang frekuensi, masa retensi, lokasi penyimpanan, dan apakah Anda bisa melakukan restore sendiri atau harus membuat permintaan terlebih dahulu.
Berapa lama sebaiknya backup disimpan?
Simpan cukup lama untuk mendeteksi masalah yang baru ketahuan beberapa waktu kemudian. Banyak tim menyimpan beberapa versi harian dan beberapa versi bulanan. Sesuaikan dengan kebutuhan hukum dan kebijakan internal Anda.
Apakah backup database saja sudah cukup?
Tidak. Database menyimpan data transaksi, tetapi file unggahan dan konfigurasi juga diperlukan agar website dapat berjalan kembali seperti semula.