5 Cara Memulihkan Website dari Backup

Backup yang tidak pernah diuji bukan pengaman, melainkan asumsi yang menunggu waktu

Hampir semua pemilik website tahu bahwa backup itu penting. Jauh lebih sedikit yang pernah benar-benar mencoba memulihkan situsnya dari backup. Selama belum pernah dicoba, backup hanya satu baris di menu hosting yang statusnya hijau, dan tidak ada yang tahu apakah berkas di dalamnya benar-benar bisa dipakai.

Masalahnya, kegagalan datang dari arah yang tidak selalu diperkirakan. Bukan hanya serangan siber, tetapi juga kegagalan perangkat, data yang rusak, dan kesalahan manusia, misalnya menghapus berkas yang salah atau menjalankan pembaruan yang membuat situs tidak bisa dibuka. Lembaga keamanan siber Selandia Baru menyebut keempat penyebab itu sebagai alasan utama mengapa pemulihan dari backup tetap dibutuhkan meski kontrol keamanan lain sudah berjalan.

Ketika situs Anda mati, yang Anda butuhkan bukan penjelasan, melainkan langkah yang sudah pernah dilakukan sebelumnya. Artikel ini membahas lima cara memulihkan website dari backup, dengan urutan yang membuat Anda tidak menambah masalah baru saat sedang panik.

1. Tentukan RPO dan RTO sebelum menyentuh berkas apa pun

Dua istilah ini terdengar teknis, tetapi artinya sederhana. RPO, atau recovery point objective, adalah seberapa banyak data yang boleh hilang, diukur dalam waktu. Kalau backup dibuat setiap malam, RPO Anda 24 jam, artinya pesanan yang masuk hari ini bisa hilang kalau pemulihan dilakukan dari backup semalam.

RTO, atau recovery time objective, adalah seberapa lama situs boleh mati. Untuk toko online yang transaksinya berjalan setiap jam, RTO satu hari terlalu lama. Untuk situs profil perusahaan yang jarang diakses, RTO satu hari masih bisa diterima.

Angka-angka ini menentukan strategi, bukan sebaliknya. Kalau RPO Anda harus satu jam, backup harian tidak cukup, dan Anda perlu cara lain seperti replikasi basis data atau pencatatan transaksi di luar situs. Kalau RTO Anda harus satu jam, Anda perlu tahu persis langkah pemulihan dan siapa yang menjalankannya, karena mencari panduan saat situs mati akan memakan waktu lebih lama daripada pemulihannya sendiri.

Tulis kedua angka itu di satu tempat, lalu bandingkan dengan kemampuan backup Anda sekarang. Kalau ada jarak yang jauh, jarak itulah risiko yang Anda bawa setiap hari.

Contoh sederhana untuk toko online kecil. Kalau rata-rata ada sepuluh pesanan per hari dengan nilai Rp150.000, RPO 24 jam berarti Anda mempertaruhkan Rp1.500.000 setiap kali pemulihan dilakukan. Angka itu jarang disadari, padahal cukup untuk menentukan apakah biaya backup per jam layak dibandingkan dengan kerugian yang mungkin terjadi.

2. Pastikan backup memuat berkas, basis data, dan konfigurasi sekaligus

Banyak backup website hanya berisi berkas situs, sementara basis datanya diambil dengan jadwal berbeda. Saat dipulihkan, hasilnya situs yang tampil normal tetapi isinya kosong, atau sebaliknya, basis data lengkap tetapi tema dan plugin hilang. Dua bagian ini harus dipulihkan dari titik waktu yang sama.

Selain berkas dan basis data, ada lapisan ketiga yang sering terlupakan: konfigurasi server. Berkas konfigurasi web server, aturan pengalihan, sertifikat, dan pengaturan email biasanya tidak berada di dalam folder situs. Kalau lapisan ini hilang, situs bisa hidup kembali tetapi email mati atau alamat lama berhenti mengarah ke halaman yang benar.

Prinsip yang paling sering dipakai untuk memastikan cakupan ini adalah aturan 3-2-1: tiga salinan data, pada dua jenis media berbeda, dengan satu salinan di lokasi terpisah. Salinan produksi di server, satu salinan di penyimpanan lokal, dan satu salinan di penyimpanan awan sudah memenuhi pola itu.

Satu hal yang perlu diuji secara terpisah: apakah backup menyertakan folder unggahan. Banyak skrip backup hanya mengambil folder inti situs, sementara gambar produk dan dokumen pelanggan tersimpan di folder lain. Saat dipulihkan, situs hidup kembali dengan gambar yang hilang semua.

Periksa juga apakah backup Anda terenkripsi dan siapa yang bisa mengaksesnya. Backup yang tersimpan di folder publik atau memakai tautan unduhan tanpa kata sandi sama berbahayanya dengan tidak punya backup, karena seluruh isi situs dan basis data bisa diambil orang lain. Panduan kesalahan mengelola VPS membahas pengaturan dasar yang sering terlewat pada server yang dikelola sendiri.

3. Pulihkan di lingkungan uji, jangan langsung menimpa situs produksi

Reaksi pertama saat situs rusak biasanya langsung mengunggah backup ke server produksi. Ini berisiko, karena kalau backup ternyata rusak atau tidak cocok, Anda kehilangan satu-satunya salinan yang tersisa di tempat yang sama.

Cara yang lebih aman adalah menyiapkan lingkungan uji lebih dulu. Buat subdomain sementara atau jalankan salinan situs di server lokal, lalu pulihkan backup di sana. Dengan begitu, kerusakan pada proses pemulihan tidak menyentuh situs yang sedang dipakai.

Lingkungan uji juga memberi Anda ruang untuk memeriksa isi backup sebelum dipakai. Buka berkas arsipnya, pastikan jumlah berkasnya wajar, dan cek tanggal di dalamnya. Backup yang ukurannya jauh lebih kecil dari biasanya biasanya menandakan proses backup gagal di tengah jalan, meskipun statusnya tercatat berhasil.

Kalau hosting Anda menyediakan fitur staging, manfaatkan itu. Kalau tidak, subdomain sementara dengan salinan basis data terpisah sudah cukup. Yang penting, jangan pernah memulihkan langsung ke produksi sebelum Anda yakin backup itu bisa dibuka dan isinya lengkap.

Satu hal yang perlu disiapkan sebelum hari pemulihan tiba: catatan langkah demi langkah yang ditulis oleh orang yang menjalankannya. Panduan resmi sering terlalu umum, sementara lingkungan server Anda punya kekhususan sendiri. Catatan yang dibuat saat uji pemulihan pertama akan jauh lebih berguna daripada dokumentasi mana pun.

Untuk situs yang sedang menangani transaksi, hentikan dulu penerimaan pesanan selama proses pemulihan. Menjalankan pemulihan sambil pesanan baru masuk akan menciptakan data yang tidak konsisten, dan itu jauh lebih sulit dibereskan daripada situs yang sempat tutup beberapa jam.

Baca Juga

5 Cara Pakai Harga Psikologis 99 Ribu

4. Pulihkan berlapis: berkas dulu, basis data kemudian, konfigurasi terakhir

Urutan pemulihan menentukan berapa lama Anda butuh untuk kembali normal. Urutan yang paling aman adalah dari lapisan yang paling jarang berubah ke lapisan yang paling sering berubah.

Mulai dari berkas situs, karena isinya relatif statis. Ekstrak arsip, lalu bandingkan jumlah berkas dan strukturnya dengan catatan Anda. Setelah itu pulihkan basis data, dan di sinilah Anda perlu berhati-hati: impor basis data lama akan menimpa seluruh data yang ada, termasuk pesanan yang masuk setelah backup dibuat.

Karena itu, sebelum mengimpor, ekspor dulu basis data yang sedang berjalan, meskipun situsnya rusak. Data yang rusak sebagian masih lebih baik daripada data yang hilang total. Simpan ekspor itu dengan nama yang jelas, lalu baru impor backup.

Lapisan terakhir adalah konfigurasi. Periksa pengaturan domain, sertifikat, dan email setelah pemulihan. Sertifikat yang kedaluwarsa akan membuat situs ditandai tidak aman oleh browser, dan itu bisa lebih merugikan daripada situs yang mati, karena pengunjung tetap datang tetapi langsung pergi.

Setelah ketiga lapisan terpasang, uji fungsi utama satu per satu: halaman beranda, halaman produk, formulir kontak, proses checkout, dan pengiriman email. Jangan berhenti pada tampilan yang terlihat normal. Situs yang tampil rapi tetapi tidak bisa menerima pesanan tetap dihitung sebagai situs yang mati.

5. Uji pemulihan setiap kuartal dan catat waktunya

Backup yang berhasil dibuat belum tentu bisa dipulihkan. Satu-satunya cara mengetahui adalah mencobanya, dan cara paling murah adalah mencobanya sebelum ada masalah.

Jadwalkan satu uji pemulihan setiap tiga bulan. Ambil backup terbaru, pulihkan di lingkungan uji, lalu catat berapa lama prosesnya berjalan dan bagian mana yang tersendat. Catatan ini menjadi rujukan saat pemulihan sungguhan, karena Anda sudah tahu langkah mana yang memakan waktu paling banyak.

Uji juga skenario yang paling mungkin terjadi di usaha Anda. Kalau kesalahan terbesar Anda selama ini adalah menghapus berkas, uji pemulihan satu berkas saja, bukan seluruh situs. Kalau risikonya adalah basis data rusak, uji impor basis data ke server bersih. Skenario yang diuji menentukan keberhasilan, bukan jumlah backup yang tersimpan.

Satu hal yang sering ditemukan saat uji: backup ternyata berisi data yang salah, misalnya basis data dari situs lain karena salah konfigurasi. Kesalahan seperti ini hanya terlihat kalau isi backup diperiksa, bukan hanya statusnya.

Simpan catatan uji beserta tanggal dan hasilnya di dokumen yang bisa diakses lebih dari satu orang. Kalau hanya Anda yang tahu cara memulihkan, maka backup Anda bergantung pada satu orang, dan itu risiko tersendiri. Panduan waktu terbaik pindah hosting membahas momen ketika pemindahan justru lebih aman dilakukan daripada menunda, dan prinsipnya mirip dengan pemulihan: lakukan saat masih tenang, bukan saat sudah terpaksa.

Setelah uji berhasil, perbarui juga daftar akun dan kata sandi yang dibutuhkan untuk pemulihan. Akses ke panel hosting, penyimpanan awan, dan pendaftar domain semuanya harus tersedia di tempat yang tidak bergantung pada satu perangkat.

Kesimpulan: nilai backup diukur saat dipulihkan, bukan saat dibuat

Lima cara memulihkan website dari backup sudah jelas: tentukan RPO dan RTO, pastikan cakupan backup lengkap, pulihkan di lingkungan uji, lakukan berlapis dari berkas ke basis data lalu konfigurasi, dan uji pemulihan setiap kuartal.

Semua langkah ini terasa berlebihan sampai situs Anda benar-benar mati. Setelah itu, satu-satunya hal yang Anda ingat adalah apakah pemulihannya pernah dicoba atau tidak. Backup yang belum pernah diuji hanyalah asumsi, dan asumsi adalah hal pertama yang runtuh saat ada masalah.

Mulailah dari yang paling murah minggu ini: buka panel hosting Anda, unduh satu backup terbaru, dan coba buka isinya. Kalau berkasnya bisa dibuka dan ukurannya wajar, Anda sudah selangkah lebih aman. Kalau tidak, Anda baru saja menemukan masalah sebelum masalah itu menemukan Anda.

Kalau Anda lebih memilih situs yang dipantau dan dicadangkan tanpa harus mengurus sendiri, layanan maintenance website kami mencakup pencadangan berkala dan uji pemulihan, sehingga saat ada gangguan, yang tersisa hanyalah memilih titik waktu pemulihan.

Rujukan untuk artikel ini: panduan implementasi dan pengujian backup dari NCSC Selandia Baru.