Banyak pemilik website merasa aman karena melihat ada menu “Backup” di cPanel atau menerima notifikasi bahwa pencadangan berhasil. Masalahnya, file backup yang tersimpan belum tentu cukup, belum tentu berada di lokasi yang aman, dan belum tentu bisa dipulihkan tanpa kejutan.
Backup hosting sebaiknya diperlakukan seperti ban serep: keberadaannya penting, tetapi nilainya baru terlihat ketika kendaraan benar-benar mengalami masalah. Karena itu, ukuran keberhasilan backup bukan hanya “file sudah dibuat”, melainkan “website dapat kembali berjalan dengan kerusakan dan waktu pemulihan yang masih bisa diterima”.
Backup website bukan sekadar menyalin folder
Website biasanya terdiri dari beberapa bagian yang saling bergantung. Ada file aplikasi seperti WordPress, tema, plugin, dan gambar. Ada database yang menyimpan artikel, akun pengguna, pesanan, atau konfigurasi. Ada juga email, sertifikat, pengaturan cron job, dan konfigurasi domain yang mungkin berada di tempat berbeda.
Jika hanya mengunduh folder public_html, Anda mungkin mendapatkan file website, tetapi kehilangan isi database. Hasilnya, halaman bisa menampilkan error koneksi database atau kembali ke kondisi instalasi kosong. Sebaliknya, database tanpa file aplikasi juga tidak cukup untuk menjalankan situs.
Inilah alasan backup perlu memiliki cakupan yang jelas. Untuk website berbasis CMS, setidaknya periksa apakah pencadangan mencakup file, database, serta konfigurasi penting yang memang diperlukan untuk menjalankan aplikasi.
Kenali dua istilah penting: RPO dan RTO
Dalam perencanaan pemulihan, ada dua ukuran yang membantu Anda menentukan backup secara realistis: Recovery Point Objective atau RPO, dan Recovery Time Objective atau RTO.
- RPO adalah seberapa banyak data yang masih bisa diterima untuk hilang. Jika backup dilakukan setiap 24 jam, secara teori perubahan dalam satu hari terakhir berisiko tidak ikut tersimpan.
- RTO adalah berapa lama website boleh tidak tersedia sampai layanan kembali berjalan.
Definisi tersebut digunakan dalam praktik pemulihan bencana: RPO berhubungan dengan usia salinan data terakhir, sedangkan RTO berhubungan dengan batas waktu pemulihan layanan. ([docs.aws.amazon.com](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/appendix-a-glossary.html?utm_source=openai))
Untuk blog pribadi, RPO satu hari mungkin masih masuk akal. Untuk toko online, sistem reservasi, atau website yang menerima formulir setiap jam, kehilangan data selama 24 jam bisa terlalu mahal. Begitu juga dengan RTO: website portofolio mungkin masih bisa menunggu beberapa jam, sementara halaman checkout sebaiknya dipulihkan jauh lebih cepat.
Periksa lokasi backup, bukan hanya jadwalnya
Kesalahan yang sering terjadi adalah menyimpan backup di server yang sama dengan website. Jika server mengalami kerusakan disk, salah konfigurasi, atau akun terkena serangan ransomware, salinan tersebut bisa ikut terdampak.
Backup lokal tetap berguna untuk pemulihan cepat, tetapi sebaiknya ada salinan kedua di lokasi berbeda. Pada cPanel dan WHM, administrator dapat mengatur tujuan tambahan seperti SFTP, Amazon S3, penyimpanan yang kompatibel dengan S3, Google Drive, FTP, atau direktori lain, bergantung pada konfigurasi provider. ([docs.cpanel.net](https://docs.cpanel.net/knowledge-base/backup/remote-restoration/?utm_source=openai))
Bagi pengguna shared hosting, pilihan lokasi mungkin dibatasi oleh provider. Tanyakan hal-hal berikut sebelum mengandalkan fitur backup otomatis:
- Backup disimpan di server yang sama atau lokasi terpisah?
- Berapa lama retensi backup, yaitu berapa banyak versi lama yang dipertahankan?
- Apakah backup otomatis termasuk database dan email?
- Apakah pengguna bisa mengunduh backup sendiri?
- Apakah ada biaya pemulihan atau biaya tambahan untuk penyimpanan eksternal?
Jangan menganggap full backup pasti bisa dipulihkan dengan satu klik
Istilah “full backup” terdengar meyakinkan, tetapi cara pemulihannya bergantung pada akses dan jenis panel yang digunakan. Dokumentasi cPanel menjelaskan bahwa full backup tidak dapat dipulihkan otomatis dari antarmuka cPanel biasa; proses pemulihan penuh tersedia melalui WHM. ([docs.cpanel.net](https://docs.cpanel.net/cpanel/files/backup-wizard/?utm_source=openai))
Ini penting bagi pemilik website yang menggunakan shared hosting tanpa akses WHM. Anda mungkin bisa membuat atau mengunduh full backup, tetapi tetap membutuhkan bantuan provider untuk mengembalikan seluruh akun. Karena itu, sebelum membeli paket hosting, cari tahu siapa yang bertanggung jawab ketika pemulihan diperlukan.
Di sisi administrator, WHM menyediakan fitur pemulihan akun berdasarkan pengguna atau tanggal backup. Fitur tersebut tetap bergantung pada backup akun yang sudah diaktifkan dan sumber backup yang tersedia. ([docs.cpanel.net](https://docs.cpanel.net/whm/backup/backup-restoration/?utm_source=openai))
Uji restore dalam skala kecil
Backup yang tidak pernah diuji adalah asumsi, bukan jaminan. Anda tidak harus langsung memulihkan seluruh website produksi. Mulailah dengan pengujian sederhana dan aman:
- Unduh satu backup terbaru ke komputer atau penyimpanan terpisah.
- Catat ukuran file dan waktu pembuatan backup.
- Pastikan arsip dapat dibuka dan tidak rusak.
- Pulihkan satu database ke database sementara.
- Salin beberapa file penting ke lingkungan staging atau subdomain uji.
- Periksa apakah gambar, login, formulir, dan fungsi utama dapat berjalan.
Untuk pemulihan sebagian, cPanel memiliki fitur yang dapat mengembalikan file atau direktori dari backup lokal. Namun, kemampuan yang tersedia tetap bergantung pada konfigurasi provider dan jenis backup yang disimpan. ([docs.cpanel.net](https://docs.cpanel.net/tags/restore/?utm_source=openai))
Pengujian kecil seperti ini sering menemukan masalah yang tidak terlihat dari notifikasi “backup completed”, misalnya kredensial database tidak ikut dicatat, versi PHP berbeda, file terlalu besar, atau backup ternyata hanya berisi sebagian data.
Buat catatan pemulihan yang bisa diikuti orang lain
Saat website mengalami masalah, Anda mungkin sedang panik atau tidak bisa dihubungi. Buat dokumen singkat berisi nama provider, akses panel, lokasi backup, nama database, versi PHP, daftar domain, serta urutan pemulihan.
Simpan informasi sensitif di pengelola kata sandi, bukan di dokumen publik. Catatan tersebut tidak perlu panjang. Yang penting, orang yang berwenang dapat memahami langkah pertama tanpa menebak-nebak.
Contohnya: arahkan DNS ke server pemulihan, buat database kosong, unggah file, impor database, sesuaikan konfigurasi aplikasi, lalu uji halaman utama dan fungsi transaksi. Untuk website penting, simpan juga kontak dukungan provider dan prosedur eskalasinya.
Yang bisa dilakukan sekarang
Luangkan waktu sekitar 30 menit untuk melakukan pemeriksaan berikut:
- Buka panel hosting dan cari tanggal backup terakhir.
- Pastikan backup mencakup file dan database.
- Cek apakah tersedia versi backup lebih dari satu hari.
- Unduh satu salinan ke lokasi di luar server.
- Tanyakan kepada provider bagaimana proses restore penuh dilakukan.
- Lakukan uji pemulihan pada staging atau subdomain.
- Tentukan RPO dan RTO yang sesuai dengan dampak bisnis website Anda.
Jika semua langkah itu belum bisa dilakukan, jangan langsung menyimpulkan bahwa hosting Anda buruk. Bisa jadi pengaturannya memang belum lengkap, atau paket yang dipilih tidak menyediakan kontrol yang Anda perlukan. Namun, itu adalah informasi penting untuk keputusan berikutnya.
Backup terbaik bukan yang paling sering menghasilkan file, melainkan yang salinannya tersedia, terpisah dari server utama, dapat dibaca, dan memiliki prosedur pemulihan yang sudah pernah dicoba. Dengan cara pandang ini, backup berubah dari fitur checklist menjadi bagian nyata dari keandalan website.
Sumber & bacaan lebih lanjut
- cPanel & WHM Documentation — Backup Restoration
- cPanel & WHM Documentation — Backup Wizard
- cPanel & WHM Documentation — Remote Restoration
- AWS Well-Architected Framework — Disaster Recovery Objectives
- AWS Glossary — Recovery Point Objective and Recovery Time Objective
– Rio Yotto @rioyotto