Cara Memastikan Backup WHM Benar-Benar Bisa Di-restore Sebelum Dibutuhkan

Keluhan seperti ini cukup sering muncul: ada akun yang perlu dipulihkan, admin membuka WHM, backup-nya ada, lalu restore dijalankan. Hasilnya website kosong, database hilang sebagian, atau arsipnya gagal diekstrak. Padahal selama ini notifikasi backup selalu bilang sukses. Masalahnya, status sukses hanya berarti proses backup selesai berjalan. Itu belum membuktikan bahwa isinya lengkap dan bisa dipakai. Artikel ini membahas urutan pengecekan yang bisa kamu lakukan sekarang, sebelum ada akun yang benar-benar butuh dipulihkan. Mulai dari log, lalu isi arsip, lalu restore uji yang aman.

Kenapa backup yang sukses belum tentu bisa di-restore

Backup akun di WHM pada dasarnya mengumpulkan beberapa komponen: isi home directory, dump database MySQL, konfigurasi akun, zona DNS, data email, lalu membungkusnya jadi satu arsip per akun. Tiap komponen bisa gagal sendiri-sendiri tanpa menghentikan seluruh proses. Contohnya, kalau ada tabel MySQL yang rusak, dump database untuk akun itu bisa terhenti di tengah. File home directory tetap masuk ke arsip, jadi ukurannya terlihat wajar. Atau disk tujuan backup penuh di tengah jalan, sehingga beberapa akun terakhir terpotong. Kasus lain yang sering terlewat adalah file atau folder yang sengaja di-exclude, entah lewat file exclude global atau milik user, lalu dilupakan bertahun-tahun. Ada juga masalah di tingkat konfigurasi. Akun baru belum tentu otomatis aktif di daftar backup, tergantung pengaturan di Backup User Selection. Kalau backup dikirim ke remote destination, transfernya bisa gagal sementara salinan lokal dihapus karena opsi retensi lokal dimatikan. Semua ini tidak terlihat dari sekadar melihat folder backup ada isinya. Karena itu kita perlu tiga lapis bukti: log yang bersih, arsip yang utuh dan lengkap, dan restore yang benar-benar berhasil.

Cek pertama: baca log backup, jangan cuma notifikasi

WHM menyimpan log setiap proses backup. Di banyak instalasi lokasinya ada di /usr/local/cpanel/logs/cpbackup/, satu file per sesi backup. Notifikasi email biasanya hanya ringkasan. Log inilah yang mencatat akun mana yang bermasalah dan di tahap apa.

BASH

# lihat beberapa log backup terbaru (read-only)
ls -lt /usr/local/cpanel/logs/cpbackup/ | head -5

# cari baris bermasalah di salah satu log (ganti NAMA_LOG)
grep -iE 'error|warn|fail' /usr/local/cpanel/logs/cpbackup/NAMA_LOG.log

Cara membaca hasilnya kurang lebih begini. Kalau grep kosong, itu tanda yang bagus, tapi belum cukup. Kalau muncul pesan terkait mysqldump atau tabel tertentu, kemungkinan besar database akun itu tidak lengkap di arsip, dan masalahnya ada di database produksi, bukan di backup. Kalau muncul pesan soal ruang disk atau write error, cek kapasitas partisi tujuan backup. Kalau error muncul saat upload ke remote destination, berarti salinan di luar server belum tentu ada. Perhatikan juga apakah semua akun yang kamu harapkan memang muncul di log. Akun yang tidak tercatat sama sekali biasanya bukan gagal, tapi memang tidak pernah masuk daftar backup. Hal ini sering baru ketahuan saat restore. Dari sisi support, pengecekan log ini biasanya langkah pertama sebelum menjawab pertanyaan apakah backup tanggal sekian bisa dipakai. Jawabannya jauh lebih bisa dipertanggungjawabkan kalau kita sudah membaca lognya.

Cek kedua: pastikan arsipnya utuh dan isinya masuk akal

Log yang bersih masih bisa menipu kalau file arsipnya rusak setelah ditulis, misalnya karena disk bermasalah atau transfer yang terpotong. Langkah berikutnya adalah memeriksa arsipnya langsung. Untuk backup tipe compressed, tiap akun biasanya berupa file .tar.gz di dalam folder tanggal, misalnya di bawah /backup/TANGGAL/accounts/. Path persisnya tergantung direktori tujuan dan tipe backup yang kamu pilih. Backup incremental dan uncompressed berbentuk folder, bukan satu file. Untuk tipe itu, periksa isi foldernya langsung.

BASH

# tanggal dan nama user di bawah ini hanya contoh
ARSIP='/backup/2026-10-19/accounts/namauser.tar.gz'

# uji integritas kompresi
gzip -t "$ARSIP" && echo 'gzip OK'

# lihat apakah komponen utama ada di dalam arsip
tar -tzf "$ARSIP" | grep -E '/(homedir|mysql|dnszones)/' | head -20

# bandingkan dengan ukuran data asli di server
du -sh /home/namauser /var/lib/mysql/namauser_*

Semua perintah di atas hanya membaca. Tapi untuk arsip besar, gzip -t dan tar -tzf membaca seluruh file, jadi sebaiknya jalankan di luar jam sibuk supaya tidak menambah beban I/O. Yang perlu kamu cari dari hasilnya: gzip -t harus selesai tanpa error, karena arsip yang terpotong biasanya gagal di sini. Daftar isi arsip harus memuat folder untuk home directory, database, dan zona DNS. Nama foldernya bisa sedikit berbeda antar versi. Di folder database, pastikan ada file dump untuk setiap database milik akun itu, bukan cuma sebagian. Perbandingan ukuran dengan du memang kasar, karena arsip terkompresi dan dump SQL ukurannya tidak sama dengan file data MySQL. Tapi perbandingan ini cukup untuk menangkap kejanggalan besar. Misalnya, data asli belasan GB tapi arsipnya cuma beberapa MB, atau database yang jelas berisi data dump-nya hampir kosong. Lokasi data MySQL juga bisa berbeda kalau datadir server pernah diubah. Kalau ada yang terlihat kurang, cek file exclude, baik yang global maupun yang ada di home user. Folder seperti cache, log, atau backup buatan plugin memang wajar di-exclude. Tapi kadang yang ikut ter-exclude adalah folder upload atau data aplikasi.

Cek ketiga: restore uji di server terpisah

Log dan isi arsip baru membuktikan bahwa bahan restore-nya ada. Bukti terakhir adalah restore itu sendiri. Di sini kita perlu hati-hati. Jangan menguji restore di server produksi dengan username yang sama. Restore akun yang sudah ada akan menimpa data yang sedang berjalan, dan itu sulit dibalikkan. Opsi yang paling aman adalah server uji terpisah, misalnya VPS kecil dengan WHM yang tidak melayani trafik apa pun. Alurnya kurang lebih seperti ini:

Salin satu arsip akun ke server uji, misalnya dengan rsync atau scp. Pilih akun yang mewakili, misalnya website dengan database aktif dan beberapa akun email.
Sebelum restore, pastikan server uji tidak tergabung di DNS cluster yang sama dengan produksi. Kalau tergabung, zona hasil restore bisa ikut tersinkron ke cluster dan mengganggu DNS akun yang sedang live.
Pertimbangkan untuk membatasi email keluar dan cron di server uji. Cron hasil restore akan ikut aktif, dan skrip yang mengirim email atau memanggil API eksternal bisa jalan seolah-olah itu server asli.
Jalankan restore lewat menu restore di WHM, misalnya Transfer or Restore a cPanel Account atau Backup Restoration. Nama menunya bisa sedikit berbeda tergantung versi.
Perhatikan output proses restore sampai selesai, terutama bagian database dan email.

Kalau restore gagal di server uji, itu justru hasil yang berguna. Lebih baik ketahuan sekarang daripada saat akun produksi benar-benar rusak.

Apa yang diperiksa setelah restore uji berhasil

Restore yang selesai tanpa error belum otomatis berarti websitenya pulih. Ada beberapa hal yang perlu kamu cek di server uji. Pertama, buka website-nya dengan mengarahkan domain ke IP server uji lewat file hosts di komputer kamu sendiri, bukan dengan mengubah DNS. Dengan cara ini hanya kamu yang melihat versi uji. Kalau yang muncul halaman default dan bukan website, masalahnya biasanya ada di pemetaan IP atau konfigurasi virtual host, bukan di isi backup. Kedua, cek database. Pastikan semua database dan user database ada, lalu login ke aplikasinya. Untuk WordPress misalnya, cukup buka dashboard dan lihat apakah konten terbaru ada sesuai tanggal backup. Konten yang terhenti jauh sebelum tanggal backup adalah tanda dump database bermasalah. Ketiga, cek bagian yang sering terlupakan: akun email dan isi mailbox, zona DNS, cron job, dan SSL. Sertifikat yang ikut ter-restore bisa saja sudah kedaluwarsa. Itu wajar untuk backup lama, tapi perlu dicatat supaya tidak kaget saat restore sungguhan. Terakhir, catat berapa lama proses restore satu akun berjalan. Angka ini membantu memperkirakan waktu pemulihan kalau suatu saat perlu restore banyak akun sekaligus, dan membantu memberi estimasi yang realistis ke pemilik website. Setelah selesai, hapus akun uji dari server uji supaya tidak ada salinan data pelanggan yang tertinggal di tempat yang tidak dipantau.

Menjadikannya kebiasaan

Kalau mau dibuat praktis: baca log backup setiap hari atau minimal setiap kali notifikasi masuk, cek integritas dan isi beberapa arsip secara acak tiap minggu, dan lakukan restore uji penuh untuk satu atau dua akun secara berkala, misalnya bulanan. Seberapa sering tepatnya tergantung seberapa kritis data di server itu. Polanya yang penting: backup baru boleh dianggap ada kalau sudah pernah terbukti bisa di-restore. Sebelum itu, statusnya baru sekadar file yang kita harap bisa dipakai.