📑 Daftar Isi
- Kenapa Backup Retention Policy Itu Penting Banget?
- Step 1: Cek Disk Space & Backup Folder Saat Ini
- Step 2: Configure Retention Policy via WHM
- Step 3: Set Backup Schedule yang Efisien
- Step 4: Optimasi Kompresi & Incremental Backup
- Step 5: Cleanup Backup Lama & Script Otomatis
- Step 6: Verifikasi Retention Policy Sudah Berjalan
- Troubleshooting: Masalah Umum & Solusi
- FAQ: Pertanyaan yang Sering Muncul
Tolong ya, berhenti lakuin ini kalau kalian pakai cPanel di production server. Aku udah lihat kasus ini berkali-kali dan tiap kali tetep bikin gemas. Server down tengah malem, disk space 100%, dan guess what? Ternyata backup retention policy-nya gak pernah disetting. Folder backup numpuk kayak gunung, dari bulan lalu sampai setahun yang lalu, semua masih di situ. Masalahnya selalu sama, dan sebenarnya gampang banget dicegah.
Aku cerita sithik ya. Dulu waktu masih jadi NOC junior, pernah dikasih ticket: “Server gak bisa diakses, mysql error, cPanel panel juga lambat.” Aku cek, disk usage 99.8%. Ternyata backup default cPanel itu nyimpen semua file backup tanpa batas. Free tier VPS 50GB, backup udah makan 30GB sendirian. Gak ada retention policy, gak ada cleanup script, gak ada yang handle. Dan ya, itu bikin pusing banget. Jangan sampai kalian ngalamin hal yang sama.
Kenapa Backup Retention Policy Itu Penting Banget?
Masalahe dudu mung server disk full wae. Dampak-e iso nggawe downtime yang lum panjang, revenue loss, trust user mudhun, lan nek iki production environment, iso-iso sampeyan entuk surat cinta seko management. Common causes-e biasane: backup files yang gak pernah di-cleanup, retention policy yang terlalu panjang, dan hard disk space yang gak dipantau. Ketiga hal ini kalau digabung, resep sempurna buat bencana.
Kebanyakan NOC engineer atau server admin itu setting backup sekali, terus lupa. Mereka pikir “udah aman, backup jalan, done.” Tapi mereka lupa satu hal: backup itu BARANG. Dan barang yang gak pernah di-cleanup bakal numpuk. Tiap malam cPanel bikin backup, tiap malam file bertambah, dan kalau gak ada retention policy, file-file lama tetap di situ selamanya. Bayangkan 365 backup × 2GB per backup = 730GB per tahun. Di VPS yang cuma punya 80GB disk? Ya, RIP.
Ini bukan cerita lebay. Ini realita yang aku lihat hampir tiap minggu di berbagai server. Ada yang pakai shared hosting, ada yang pakai VPS dedicated, ada yang pakai managed server — semuanya punya risiko yang sama kalau retention policy gak di-configure. Dan parahnya, banyak yang gak sadar sampai server-nya mati total karena disk space habis.
Step 1: Cek Disk Space & Backup Folder Saat Ini
Sebelum kita optimasi retention policy, kita perlu tahu dulu kondisi saat ini. Skip basa-basi, ini langkah-langkahnya:
Login ke server via SSH, lalu jalankan perintah berikut:
df -h /backup
du -sh /backup/*
ls -lhS /backup/ | head -20
Perintah pertama (df -h) ngecek disk usage keseluruhan. Perintah kedua (du -sh) ngecek ukuran masing-masing folder di dalam /backup. Perintah ketiga (ls -lhS) nge-list file terbesar di folder backup — dari yang paling gede sampai yang paling kecil.

Nah, kalau hasilnya menunjukkan folder backup makan lebih dari 30-40% total disk space, itu warning sign yang serius. Kamu harus segera set retention policy. Kalau masih di bawah 20%, bagus, tapi tetep harus di-configure biar gak jadi masalah di masa depan.
Satu lagi yang perlu kamu cek: apakah ada backup file yang duplikat atau corrupt. Kadang cPanel bikin partial backup yang gagal tapi file-nya tetap ada di disk. Cek dengan:
find /backup -name "*.tar.gz" -size 0 -ls
find /backup -name "*.tar.gz" -mtime +30 -ls
Perintah pertama nyari file backup yang kosong (size 0 byte) — ini biasanya partial backup yang gagal. Perintah kedua nyari file backup yang udah lebih dari 30 hari tapi masih ada di situ. Kalau hasilnya banyak, berarti kamu punya banyak sampah yang harus di-cleanup.
Step 2: Configure Retention Policy via WHM
Oke, sekarang kita ke intinya. Cara paling gampang buat optimize cPanel backup retention policy adalah lewat WHM (Web Host Manager). Ini langkah-langkahnya:
- Login ke WHM (
https://server-kamu:2087) - Masuk ke Home > Backup > Backup Configuration
- Di bagian Retention, atur jumlah backup yang ingin disimpan
- Untuk daily backup: set “Keep Daily backups for” ke 7 (minggu)
- Untuk weekly backup: set “Keep Weekly backups for” ke 4 (bulan)
- Untuk monthly backup: set “Keep Monthly backups for” ke 6 (bulan)
- Klik Save Configuration

Nah, itu pengaturan basic-nya. Tapi tunggu dulu, jangan langsung keluar. Ada beberapa hal yang perlu kamu pertimbangkan sebelum finalisasi setting ini.
Pertama, pertimbangkan kebutuhan recovery time kamu. Kalau kamu biasanya butuh restore dari backup yang udah lebih dari seminggu, jangan set daily retention terlalu rendah. Kedua, pertimbangkan disk space yang tersedia. Kalau disk space terbatas, kamu harus lebih agresif dalam cleanup. Ketiga, pertimbangkan jenis data yang di-backup. Database biasanya lebih krusial daripada file website statis, jadi pertimbangkan untuk set retention lebih panjang untuk database backup.
Selain itu, pastikan juga kamu sudah mengaktifkan kompresi untuk backup. Di bagian Transport di Backup Configuration, pilih opsi kompresi. Ini bisa mengurangi ukuran backup sampai 60-80%, tergantung jenis data. File HTML, CSS, dan JavaScript terkompresi dengan sangat baik, sementara file gambar yang udah terkompresi (JPEG, PNG) biasanya gak banyak berubah ukurannya.
Step 3: Set Backup Schedule yang Efisien
Backup schedule yang bagus itu bukan “backup setiap hari semua data.” Itu waste of resources. Yang efisien adalah:
| Tipe Backup | Jadwal | Retention | Catatan |
|---|---|---|---|
| Daily Backup | Setiap jam 2:00 AM | 7 hari terakhir | Hanya backup data yang berubah (incremental) |
| Weekly Backup | Minggu jam 3:00 AM | 4 minggu terakhir | Full backup untuk recovery jangka panjang |
| Monthly Backup | Tanggal 1 jam 4:00 AM | 6 bulan terakhir | Full backup komprehensif |
Jadwal di atas itu sweet spot yang udah aku pake di banyak server. Daily untuk quick recovery, weekly untuk situasi yang lebih serius, dan monthly untuk archival.Retention 7-4-6 ini cukup buat most scenarios. Tapi kalau kamu butuh retention lebih panjang karena compliance atau regulasi, silakan disesuaikan.
Penting juga buat memastikan backup job-nya gak conflict sama service lain. Misalnya, kalau kamu ada cron job heavy I/O lain di jam yang sama, bisa bikin server load naik drastis. Sebisa mungkin, jadwalkan backup di jam yang server-nya lagi sepi traffic. Jam 2-4 pagi itu biasanya waktu paling ideal.
Step 4: Optimasi Kompresi & Incremental Backup
Salah satu cara paling efektif buat optimize cPanel backup retention policy tanpa mengorbankan data adalah dengan mengaktifkan kompresi dan incremental backup.
Kompresi bisa kamu aktifkan di WHM > Backup > Backup Configuration > section Backup Type. Pilih “Compressed” daripada “Uncompressed.” Perbedaannya signifikan:
# Contoh ukuran backup uncompressed vs compressed
# Untuk website typical 2GB (file + database)
# Uncompressed: ~2.1GB
# Compressed (gzip): ~400MB-600MB
# Compressed (bzip2): ~350MB-500MB (lebih lambat tapi lebih kecil)
Selain itu, aktifkan juga opsi Incremental Backup kalau tersedia di versi cPanel kamu. Incremental backup cuma nyimpen file yang berubah sejak backup terakhir, bukan full copy ulang. Ini bisa menghemat disk space sampai 70% untuk daily backup.
Untuk versi cPanel yang lebih baru (118+), kamu juga bisa pakai Transport Backup ke remote storage seperti Amazon S3 atau Google Cloud Storage. Ini solusi paling clean karena backup langsung disimpan di cloud, gak makan disk space server lokal sama sekali. Kalau budget memungkinkan, ini highly recommended.
# Contoh konfigurasi remote backup di WHM
# Home > Backup > Backup Configuration > Transport
# Pilih: Amazon S3 / Google Cloud Storage / FTP / SCP
# Isi credential & bucket name
# Aktifkan "Use Transport" di bagian Backup Type
Kalau kamu pakai S3, estimasi biaya storage sekitar $0.023 per GB per bulan (us-east-1). Untuk 100GB backup, itu cuma sekitar $2.30 per bulan — jauh lebih murah daripada upgrade disk VPS. Dan yang paling penting, kamu gak perlu khawatir disk server penuh lagi.
Step 5: Cleanup Backup Lama & Script Otomatis
Ini step yang paling sering dilupakan. Kamu udah set retention policy, tapi backup lama yang udah ada belum di-cleanup. Harus dibersihkan manual dulu, terus set script otomatis buat maintain.
Bersihkan backup lama secara manual:
# Hapus backup yang lebih dari 7 hari
find /backup/daily* -name "*.tar.gz" -mtime +7 -delete
# Hapus backup yang lebih dari 4 minggu
find /backup/weekly* -name "*.tar.gz" -mtime +28 -delete
# Hapus backup yang lebih dari 6 bulan
find /backup/monthly* -name "*.tar.gz" -mtime +180 -delete
# Hapus file backup yang kosong/ corrupt
find /backup -name "*.tar.gz" -size 0 -delete
find /backup -name "*.tar.gz" -mtime +30 -size -1k -delete
Setelah cleanup manual, buat cron job otomatis buat maintain retention policy:
# Edit crontab
crontab -e
# Tambahkan baris berikut untuk auto-cleanup backup lama
# Cleanup daily backup lebih dari 7 hari (jam 5:00 AM)
0 5 * * * find /backup/daily* -name "*.tar.gz" -mtime +7 -delete 2>/dev/null
# Cleanup weekly backup lebih dari 28 hari (Minggu jam 6:00 AM)
0 6 * * 0 find /backup/weekly* -name "*.tar.gz" -mtime +28 -delete 2>/dev/null
# Cleanup monthly backup lebih dari 180 hari (tanggal 2 jam 7:00 AM)
0 7 2 * * find /backup/monthly* -name "*.tar.gz" -mtime +180 -delete 2>/dev/null
# Report disk usage (Minggu jam 8:00 AM)
0 8 * * 0 df -h /backup | mail -s "Weekly Backup Disk Report" admin@domain.com
Cron job di atas bakal jalan otomatis setiap hari sesuai jadwal yang ditentukan. Disk usage report dikirim via email tiap minggu biar kamu bisa monitor tanpa harus login ke server terus.
Step 6: Verifikasi Retention Policy Sudah Berjalan
Oke, kita udah set semua. Sekarang verifikasi. Jangan skip step ini — ini penting.
# Cek isi folder backup setelah cleanup
ls -lh /backup/daily*/ | tail -20
# Cek ukuran total backup
du -sh /backup/*/
# Cek free disk space
df -h /
# Pastikan cron job sudah terdaftar
crontab -l | grep backup
# Test jalankan script cleanup manual (dry run)
find /backup/daily* -name "*.tar.gz" -mtime +7 -ls
Kalau hasilnya menunjukkan ukuran folder backup udah jauh lebih kecil dari sebelumnya, dan free disk space udah naik signifikan, selamat! Retention policy kamu udah berjalan dengan benar.
Tapi tunggu, ada satu hal lagi yang perlu kamu cek. Pastikan WHM backup configuration-nya juga sudah benar. Kadang kita set retention policy tapi lupa mengaktifkan backup schedule-nya. Cek dengan:
# Cek apakah backup cron sudah aktif
ls -la /etc/cron.d/*backup* 2>/dev/null
cat /var/cpanel/backups/config 2>/dev/null | grep -i retention
Kalau hasilnya kosong atau error, berarti backup schedule belum aktif. Kembali ke WHM > Backup > Backup Configuration dan pastikan “Enable Weekly/Nightly backups” sudah dicentang.
Troubleshooting: Masalah Umum & Solusi
| Masalah | Penyebab | Solusi |
|---|---|---|
| Backup folder masih besar setelah set retention | File backup lama belum di-cleanup manual | Jalankan perintah find -delete manual, lalu pastikan cron auto-cleanup aktif |
| WHM backup gak jalan | Backup schedule belum diaktifkan atau cron error | Cek WHM Backup Configuration, pastikan schedule aktif. Cek cron logs di /var/log/cron |
| Backup corrupt/ partial | Disk space habis saat backup process, atau I/O error | Cek disk space sebelum backup. Jalankan fsck jika ada I/O error. Set backup ke jam sepi |
| Server load naik saat backup | Backup jalan di jam ramai, atau I/O heavy | Jadwalkan backup di jam 2-4 pagi. Aktifkan ionice untuk limit I/O priority |
| Remote backup gagal connect | Firewall block atau credential salah | Cek firewall rules, pastikan port FTP/SFTP/443 terbuka. Verifikasi credential di WHM |
| Database backup gak lengkap | MySQL lock timeout atau concurrent write | Set backup time saat low traffic. Pertimbangkan mysqldump –single-transaction untuk InnoDB |
FAQ: Pertanyaan yang Sering Muncul
Q: Berapa lama sebaiknya saya menyimpan backup di cPanel?
Untuk kebanyakan server, retention 7 hari untuk daily backup, 4 minggu untuk weekly, dan 6 bulan untuk monthly sudah cukup. Ini kompromi antara kebutuhan recovery dan disk space usage. Kalau kamu butuh compliance lebih ketat (misal untuk industri keuangan atau healthcare), pertimbangkan retention lebih panjang tapi gunakan remote storage seperti S3 supaya gak makan disk server.
Q: Apakah aman menghapus backup lama secara otomatis?
Ya, aman selama kamu sudah set retention policy yang sesuai kebutuhan dan sudah verifikasi bahwa backup yang lebih baru tersedia dan bisa di-recover. Yang penting: jangan pernah menghapus SEMUA backup. Selalu sisakan minimal 1 full backup terbaru. Dan pastikan kamu sudah test recovery prosedur sebelum menghapus backup lama.
Q: Bagaimana cara memindahkan backup ke cloud storage?
Buka WHM > Backup > Backup Configuration > Transport. Pilih Amazon S3, Google Cloud Storage, atau opsi FTP/SCP. Isi credential dan bucket name, lalu aktifkan “Use Transport” di section Backup Type. Semua backup selanjutnya akan otomatis dikirim ke cloud storage. Untuk setup detail, baca juga panduan di artikel kami tentang WHM Backup Remote Storage.
Q: Apakah incremental backup mengurangi kualitas restore?
Tidak. Incremental backup tetap menghasilkan full restore yang identik dengan backup biasa. Perbedaannya hanya pada proses backup — incremental cuma menyalin file yang berubah. Saat restore, cPanel otomatis menggabungkan incremental changes ke full backup base. Kualitas data yang di-restore sama persis.
Udah paham kan sekarang kenapa retention policy itu penting banget? Jangan cuma dibaca, langsung praktekin step di atas. Login WHM, cek disk space, set retention, cleanup backup lama. Kalau masih stuck, cek log error-nya dan bandingin sama troubleshooting table di atas. Take it seriously — disk full gak ada yang lucu. Semoga kalian gak ngalamin hal yang sama kayak aku dulu.