Managing cPanel WHM backup retention configuration is one of the most overlooked tasks on a shared hosting server — until the disk fills up at 2 AM and backups start failing. The default WHM backup settings keep more copies than most disks can handle, and the interaction between compression ratio, retention count, and available disk space is rarely explained in a single place. This guide walks you through every setting that matters, with the math to back it up.
Why Default WHM Backup Settings Fill Your Disk (and How to Spot It Early)
Out of the box, WHM's Backup Configuration ships with settings that are generous on retention but silent on disk consumption:
- Daily backups: 5 copies retained
- Weekly backups: 4 copies retained
- Monthly backups: 1 copy retained
- Compression: Enabled (gzip, default level)
- Disk space check: Enabled at 5% free
The problem is straightforward arithmetic. Suppose your server hosts 50 cPanel accounts averaging 2 GB each — that is 100 GB of account data. A compressed backup typically reduces this to 50–60% of the original size (compression ratio roughly 1.7:1 on mixed web content). So each daily backup occupies approximately 55–60 GB. Multiply by 5 daily copies: 275–300 GB of daily backup alone. Add 4 weekly copies and 1 monthly copy and you are looking at well over 600 GB reserved for backups on a server that may only have a 500 GB disk.
Real Error Messages That Signal the Problem
When WHM's backup job starts and cannot complete, it writes to /usr/local/cpanel/logs/cpbackup/. Common error lines include:
Disk is too full to run the backup system.
Available disk space is X%, which is less than the configured minimum of 5%.
Backup of account [user] failed: No space left on device
Error: Could not create archive file: No space left on deviceYou can also catch the warning early using WHM > Server Status > Disk Usage or by running:
df -h /backup
du -sh /backup/cpbackup/daily/*If the /backup partition (or root partition, if backups go to /home) shows above 80% used, the disk space check threshold of 5% will not trigger until you hit 95% — by which time a partially written backup may have already exhausted the remaining space.
The Hidden Trigger: Backup Does Not Remove Old Copies First
This is the most misunderstood behaviour in WHM backups: cPanel does not purge the oldest backup copy before writing the new one. It writes the new backup fully, then removes the expired copy. This means at peak you need two full backup sets worth of free space — not one. If you retain 5 daily backups and each is 55 GB, you need at least 330 GB free at the moment the 6th run starts, not 275 GB.
Compressed vs. Incremental Backups: Which Should You Use?
WHM offers two fundamentally different backup strategies, and choosing the wrong one for your disk situation is a common source of space issues.
Compressed Backups
Each backup run creates a full per-account .tar.gz archive. The compression ratio on typical web account content (PHP files, MySQL dumps, email) is roughly 1.5:1 to 2:1 — meaning a 2 GB account compresses to 1–1.3 GB. However:
- Each retained copy is a complete archive — no deduplication between runs
- During the backup run itself, the temp file and final archive coexist briefly, briefly doubling the per-account disk requirement
- CPU usage is higher; on a busy shared server, gzip compression during peak hours causes load spikes
Compressed backups are best when you have a remote destination configured and only keep 1–2 local copies, or when you need per-account restores that your support team can perform without command-line access (WHM's restore GUI works with compressed archives directly).
Incremental Backups
The first incremental run is a full backup. Subsequent runs only copy files that have changed since the last run. WHM stores each incremental set in a directory tree under /backup/cpbackup/incremental/ rather than a monolithic archive. Benefits:
- Day 2+ backup runs are dramatically smaller — a low-change account may add only a few MB per run
- No double-disk-usage during the run (files are copied, not archived into a temp file)
- Faster to complete on subsequent runs
Drawbacks: incremental backups are incompatible with most remote destinations that WHM supports (FTP, SFTP, S3). They also cannot be selectively restored through the WHM GUI for all scenarios — partial restores may require command-line work. Incremental mode is best for local or NFS-mounted backup storage where disk efficiency matters most.
The Compression Level Factor
WHM uses gzip by default. You can influence the compression level via the cpanel.config or by switching to zstd (available in cPanel 106+) which offers better speed at comparable ratios. Higher compression levels save disk but extend backup duration — on a 100-account server, moving from gzip level 6 (default) to level 9 might save 8–12% disk but add 30–40% CPU time per run. Unless disk is critically scarce, the default level is a good balance.
💡 None of these worked? Skip the guesswork.
Get Expert Help →How to Configure Daily, Weekly, and Monthly Retention in WHM
Navigate to WHM > Backup > Backup Configuration. Here is the recommended approach for each retention tier, with the disk math behind each setting.
At the top of the Backup Configuration page, set Backup Status to Enabled. Choose Compressed or Incremental based on the guidance above. Do not leave it on "Disabled" thinking you will enable it later — verify now that it is active.
Enable daily backups and set the retention count using this formula:
Max daily copies = (Backup partition free space × 0.8) ÷ (average account size × compression ratio × account count)For most shared servers, 2 daily copies strikes the right balance — you can recover from a bad push or corrupted file from the previous day without consuming five times the disk. If your server has a dedicated backup partition of 500 GB and total account data of 80 GB compressed, 3 daily copies is safe. Avoid the default of 5 unless you have verified the math.
Weekly backups are useful for recovering from issues discovered late (e.g., a plugin that corrupted data 10 days ago). Set the day of the week to Sunday (low-traffic window) and keep 2 weekly copies rather than the default 4. Two weeks of weekly history is sufficient for most SLA requirements.
Monthly copies are compliance snapshots. One copy retained is appropriate for most hosting operations. If regulatory requirements demand 90-day retention, keep 3 monthly copies but ensure they are stored on a remote destination, not locally.
This is a critical checkbox: Strictly enforce retention regardless of backup success. When checked, WHM removes backups older than the retention count even if the new backup failed. This prevents the situation where repeated failures accumulate copies because WHM was waiting for a clean run before pruning. Enable this on any server where disk space is a concern.
Only enable backup on days you actually need. Running daily backups 7 days a week on a low-change server is wasteful. For many shared hosting environments, Mon/Wed/Fri coverage (3 days) with a Sunday weekly backup provides adequate recovery points while cutting daily disk usage by 57%.
Go to WHM > Backup > Backup Configuration > Additional Destinations and click Create New Destination.
For S3-compatible storage (Backblaze B2, Wasabi, AWS S3), choose Amazon S3. For a remote Linux box, choose SFTP. FTP is available but transmits credentials in plaintext — avoid it for sensitive data.
Once a remote destination is configured, reduce local retention to 0 (no local copies beyond what is being transferred) or 1 (keep last copy locally for fast restores). This is the single biggest disk space win available to a hosting administrator.
WHM provides a Save and Validate Destination button. Always click it and confirm the test file appears in the remote location before reducing local retention. Silently failing remote destinations combined with 0 local copies means no backups at all.
When using S3-compatible storage, set a lifecycle rule on the bucket to expire objects older than your retention period. WHM does not manage deletion of remote objects automatically in all configurations — without a lifecycle rule, your S3 costs (and object count) grow indefinitely.
If managing WHM backup configuration feels like a full-time job, our CloudHouse server management service handles backup strategy, monitoring, and remote destination setup for cPanel/WHM servers of all sizes.
FAQs
How do I check how much disk space my WHM backups are using?
Run du -sh /backup/cpbackup/ (or wherever your backup directory is configured — check WHM > Backup Configuration > Backup Directory). Break it down by type with du -sh /backup/cpbackup/daily/ /backup/cpbackup/weekly/ /backup/cpbackup/monthly/ to see which retention tier is consuming the most space.
What is the difference between compressed and incremental backups in WHM?
Compressed backups create a full .tar.gz archive for every account on every run — each copy is independent and self-contained. Incremental backups store only the files that changed since the previous run, sharing unchanged files across backup sets. Incremental backups use less disk for multiple retained copies but are incompatible with most remote (FTP/S3) destinations and require more complex restores.
WHM is not removing old backups after new ones run. Why?
By default, WHM only removes a backup that has exceeded the retention count after a successful new backup completes. If new backups are failing (e.g., due to disk space or network errors), old copies accumulate. Enable Strictly enforce retention regardless of backup success in Backup Configuration to force removal even when the new backup fails.
How do I prevent WHM backups from running when disk is low?
Enable the Minimum Free Space (disk space check) option in Backup Configuration. Set it to at least the size of one full compressed backup set — typically 15–20% of your backup partition, not the default 5%. WHM will skip the backup run and log a warning rather than filling the disk.
Can WHM back up to Amazon S3 or Backblaze B2?
Yes. WHM supports Amazon S3 and any S3-compatible service (Backblaze B2, Wasabi, MinIO) via the Additional Destinations section in Backup Configuration. You need the bucket name, endpoint (for non-AWS providers), access key, and secret key. After configuring, use Save and Validate Destination to confirm connectivity before reducing local retention.