Yang Berubah Saat Pindah dari Legacy Backup ke Backup Configuration WHM

Keluhannya biasanya mirip. Dulu backup di server cPanel rapi di folder daily, weekly, dan monthly. Sekarang foldernya berupa tanggal, jumlah salinannya beda, disk tiba-tiba penuh, atau folder di remote FTP malah kosong. Penyebabnya hampir selalu sama: Backup Configuration di WHM bukan versi baru dari Legacy Backup. Ini sistem yang berbeda, dengan logika retensi dan pengiriman yang berbeda juga. Artikel ini mengikuti urutan pengecekan yang biasanya kita lakukan di meja support saat ada laporan seperti itu. Dari situ kelihatan apa yang berubah dan apa yang perlu disetel ulang.

Cek pertama: sistem backup mana yang sebenarnya jalan

Sebelum membahas retensi, pastikan dulu konfigurasi mana yang aktif. Di server yang sudah lama hidup dan sudah berkali-kali di-upgrade, sisa konfigurasi lama sering masih tertinggal. Admin pun sering membaca file yang salah. Legacy Backup menyimpan konfigurasinya di /etc/cpbackup.conf. Hasilnya biasanya ditaruh di /backup/cpbackup/. Sistem baru memakai /var/cpanel/backups/config dan menulis hasil backup ke folder bertanggal di bawah direktori backup yang kamu tentukan, defaultnya /backup. Pengecekan read-only yang cukup aman dijalankan:

BASH

ls -la /etc/cpbackup.conf /var/cpanel/backups/config
whmapi1 backup_config_get
ls -la /backup

Cara membaca hasilnya:

Jika /backup/cpbackup/ masih ada tapi isinya tidak pernah diperbarui, itu sisa Legacy. Isinya tidak lagi dirotasi oleh siapa pun dan diam-diam memakan disk.
Jika backup_config_get menunjukkan backup aktif dan folder bertanggal terus bertambah, sistem baru yang bekerja.
Jika keduanya kosong atau tidak jelas, cek apakah ada cron kustom atau skrip pihak ketiga yang selama ini dianggap backup bawaan.

Kasus yang sering membingungkan: di versi WHM yang lebih baru, Legacy Backup sudah tidak tersedia lagi. Jadwal lama tidak otomatis dipindahkan apa adanya. Admin mengira jadwal lama masih jalan, padahal yang aktif sekarang adalah setelan default sistem baru, atau malah tidak ada sama sekali.

Cek kedua: retensi tidak lagi berbentuk satu slot per periode

Di Legacy Backup, model retensinya sederhana. Ada slot daily, weekly, dan monthly, dan setiap slot pada dasarnya menimpa isinya sendiri saat periode berikutnya tiba. Hasilnya, kamu selalu punya kira-kira tiga titik waktu. Sistem baru bekerja berdasarkan jumlah salinan. Kamu menentukan berapa backup harian yang disimpan, lalu weekly dan monthly diatur terpisah dengan retensinya sendiri. Setiap backup harian menjadi folder baru bertanggal, bukan menimpa folder yang sama. Dari perubahan ini biasanya muncul dua gejala:

Disk penuh setelah migrasi. Retensi daily diset cukup banyak, dan setiap salinan berupa backup penuh (compressed atau uncompressed). Pemakaian disk naik kira-kira sebanding dengan jumlah salinan dikali ukuran akun. Di Legacy, efek ini tidak terasa karena slotnya ditimpa.
Titik restore lebih sedikit dari dugaan. Daily diset rendah dan weekly atau monthly belum diaktifkan. Admin mengira masih punya cadangan bulanan seperti dulu, padahal tidak ada.

Ada dua opsi lain yang perlu dibaca pelan-pelan. Opsi pertama mengatur apakah retensi tetap ditegakkan walaupun backup gagal. Kalau dipaksa, backup lama bisa terhapus padahal backup baru tidak berhasil. Opsi kedua menentukan apakah salinan lokal tetap disimpan di direktori default setelah dikirim ke remote. Kalau opsi ini dimatikan, salinan lokal dibuang setelah transfer, dan satu-satunya salinan ada di remote. Nama persis dan perilaku detail kedua opsi ini bisa berbeda antar versi, jadi baca deskripsinya langsung di halaman Backup Configuration di WHM.

Cek ketiga: incremental tidak berarti hemat di semua tempat

Di sistem baru ada tiga tipe backup: compressed, uncompressed, dan incremental. Incremental artinya hanya file yang berubah sejak backup sebelumnya yang benar-benar disalin. File yang sama dibagikan antar salinan, sehingga ruang disk jauh lebih hemat untuk akun besar yang jarang berubah. Yang sering tidak disadari, incremental tidak didukung oleh semua jenis remote destination. Tergantung versi WHM, sebagian destination hanya menerima backup compressed atau uncompressed. Akibatnya, kombinasi incremental dengan destination yang tidak cocok bisa membuat transfer dilewati atau gagal. Admin baru tahu saat membuka storage remote dan isinya kosong. Cek daftar destination yang didukung untuk incremental di dokumentasi versi yang kamu pakai, jangan hanya mengandalkan asumsi. Incremental juga punya biaya lain. Karena berbasis salinan file per file, jumlah inode yang dipakai bisa jauh lebih besar daripada satu file arsip .tar.gz per akun. Di filesystem yang inode-nya terbatas, ini bisa jadi masalah sebelum kapasitas disk habis. Proses restore satu akun utuh juga terasa berbeda karena datanya bukan satu arsip tunggal. Aturan praktis yang aku pakai: incremental cocok untuk salinan lokal atau rsync ke server lain yang kamu kontrol. Untuk object storage, compressed biasanya lebih sederhana dikelola, walaupun lebih boros ruang.

Cek keempat: log transfer ke remote destination

Setelah konfigurasi dan retensi jelas, cari tahu apakah backup benar-benar sampai ke tujuan. Di Legacy, opsi remote pada dasarnya FTP. Sistem baru punya banyak jenis destination, misalnya SFTP, rsync, FTP, dan S3-compatible. Setiap destination punya kredensial dan bisa gagal dengan caranya sendiri. Status backup lokal dan status transfer dicatat terpisah. Backup lokal bisa berhasil sementara transfer gagal, dan di permukaan semuanya terlihat baik-baik saja. Dua lokasi log yang perlu dibuka:

BASH

ls -lt /usr/local/cpanel/logs/cpbackup/ | head
tail -n 50 /usr/local/cpanel/logs/cpbackup_transporter.log

Cara membaca hasilnya:

Log di folder cpbackup/ menunjukkan proses pembuatan backup per akun.
Log transporter menunjukkan upload ke destination dan proses pemangkasan (prune) salinan lama di sana.

Error autentikasi, timeout, atau penolakan izin hampir selalu muncul di log transporter. Di halaman destination di WHM juga ada tombol untuk menguji koneksi. Gunakan itu setiap kali kredensial diganti. Perlu diingat juga bahwa transfer yang sukses belum menjamin data bisa dipulihkan. Pembahasan soal itu ada di artikel Why a Successful Backup Job Does Not Guarantee a Working Database Restore.

Cek kelima: apakah backup offsite bisa dihapus dari server itu sendiri

Bagian ini paling jarang dicek, padahal paling penting saat menghadapi ransomware. Insiden ransomware Brain Cipher yang melumpuhkan PDNS 2 di Surabaya pada Juni 2024 jadi pengingat bahwa serangan seperti ini bukan skenario teoretis untuk infrastruktur di Indonesia. Masalahnya ada di cara kerja push backup. Untuk mengirim backup, WHM menyimpan kredensial destination di server itu sendiri. Kalau penyerang mendapat akses root, dia juga mendapat kredensial itu. Kalau kredensial tersebut punya izin hapus, penyerang bisa menghapus atau menimpa semua salinan offsite sebelum mengenkripsi server. Backup yang secara teknis offsite jadi tidak berguna karena aksesnya masih bisa dikendalikan dari server yang diserang. Tiga pertanyaan yang perlu dijawab untuk setiap destination:

Apakah kredensial yang tersimpan di WHM bisa menghapus atau menimpa objek di storage tujuan? Kalau bisa, salinan offsite tidak terlindungi dari root yang dibobol.
Apakah storage tujuan punya versioning atau object lock (immutability) yang mencegah penghapusan selama periode tertentu? Dukungannya berbeda antar penyedia, jadi cek di dokumentasi penyedia masing-masing.
Adakah salinan yang ditarik (pull) dari sistem lain, bukan dikirim dari server produksi? Dengan pull, server produksi tidak pernah memegang kredensial ke tempat backup disimpan.

Ada trade-off yang perlu dipahami. Pemangkasan retensi di remote dilakukan oleh WHM, dan itu butuh izin hapus. Kalau kamu memberi kredensial tanpa izin hapus, pemangkasan dari sisi WHM akan gagal dan storage terus membengkak. Solusi yang umum adalah menyerahkan urusan hapus ke lifecycle rule di sisi penyedia storage, lalu memakai object lock untuk periode minimum. Dengan begitu, penghapusan dikendalikan oleh storage, bukan oleh server yang mungkin sudah dibobol. Pastikan semuanya diuji di bucket percobaan dulu sebelum dipakai untuk backup produksi. Kalau server cPanel jalan di atas virtualisasi, pikirkan juga lapisan di bawahnya. Pembahasan soal itu ada di Hardening Virtualized Clusters Against Ransomware.

Yang perlu dibawa pulang

Perlakukan perpindahan dari Legacy Backup sebagai setup baru, bukan migrasi otomatis. Urutannya:

Pastikan konfigurasi mana yang aktif.
Bersihkan sisa /backup/cpbackup/ setelah yakin tidak dibutuhkan lagi.
Hitung ulang retensi berdasarkan kapasitas disk.
Cocokkan tipe backup dengan destination yang mendukungnya.
Baca log transporter, bukan hanya status backup lokal.

Pertanyaan terakhir yang paling menentukan saat terjadi serangan: kalau root server ini jatuh malam ini, apakah masih ada satu salinan backup yang tidak bisa disentuh dari server itu? Kalau jawabannya belum pasti, itu yang perlu dibereskan duluan.