When a cPanel backup failed disk space error strikes, it can leave every account on your server completely unprotected until the problem is resolved. Backup jobs silently abort, no copies are made, and the first you hear about it is often a terse email from cPanel saying "Backup process failed" — with no disk space left to investigate. This guide walks you through diagnosing the root cause, applying an immediate fix, and building a storage architecture that prevents the problem from ever happening again.
Why cPanel Backups Fail from Disk Space Issues
cPanel's backup system writes compressed account archives directly to the backup destination. If that destination — whether it's the same partition as /home, a separate /backup mount, or a remote path — runs out of space mid-write, the entire job fails and cPanel marks the backup as incomplete.
The Three Most Common Causes
- Backups stored on the same partition as account data. Every byte an account uses also requires roughly one byte of backup space. When
/homefills up, backups fail before they can even start the compression step. - Incremental backups accumulating over time. cPanel's legacy backup system does not prune old backups automatically unless you configure a retention limit. A server left running for 90 days with daily incremental backups can silently consume hundreds of gigabytes.
- A single large account dominating backup space. One client running a media-heavy WordPress site with a 40 GB database can exhaust the backup destination on its own, causing all other accounts to fail.
cPanel Backup Error Messages Decoded
No space left on device— the filesystem has zero free inodes or zero free blocks; any write operation will fail.Insufficient disk space for backup— cPanel's pre-flight check detected that free space is below the minimum threshold (default: 100 MB) before even starting.Disk quota exceeded— the user running backups (rootin most cases, but sometimes a dedicated backup user) has hit a per-user quota on the destination filesystem.backup process failed: cannot create directory— the destination path is full and cPanel cannot write the backup manifest or lock file.
💡 None of these worked? Skip the guesswork.
Get Expert Help →How to Diagnose Disk Space Problems on cPanel Servers
Before making any changes, take a complete snapshot of the current disk state so you can identify the largest consumers and target your cleanup precisely.
df -hT
Look at the Use% column. Any filesystem above 85% is at risk; above 95% means backups will almost certainly fail. Pay particular attention to the filesystem that hosts /home and the one that hosts your backup destination (often /backup).
du -sh /home/* | sort -rh | head -20
This ranks every account by its disk footprint. An account consuming 30–40 GB is a red flag — check whether its public_html and MySQL dumps are being included in backups.
du -sh /backup/*
ls -lah /backup/cpbackup/
Compare the total backup size to the free space on that filesystem. If backups are larger than available free space, you need to either purge old backups or move to external storage before the next scheduled run.
find /backup/cpbackup -name "*.tar.gz" -mtime +7 | sort | head -30
Anything older than your retention window is safe to delete manually, freeing space immediately.
df -i
A filesystem can run out of inodes while still showing free block space. cPanel backups create thousands of small temporary files — on ext4 partitions with many tiny files this is a genuine failure mode. If the IUse% column shows 100%, add a separate backup partition or purge small files.
tail -200 /usr/local/cpanel/logs/cpbackup/backup.log
This shows exactly which account failed, at what point in the backup, and the underlying OS error. Filter for No space or quota errors to confirm the cause.
# Remove daily backups older than 7 days
find /backup/cpbackup/daily -mtime +7 -name "*.tar.gz" -delete
# Remove weekly backups older than 4 weeks
find /backup/cpbackup/weekly -mtime +28 -name "*.tar.gz" -delete
Always verify the retention policy first via WHM → Backup Configuration before deleting.
Go to WHM → Backup → Backup Configuration → Retention Settings. Set:
- Daily backups: 3–7 (not 0 — "0" means unlimited)
- Weekly backups: 2–4
- Monthly backups: 1–3
Setting these to 0 is the single most common misconfiguration that causes backup storage to grow unbounded.
In WHM → Backup → Backup Configuration → Accounts to Exclude, you can exclude individual cPanel accounts temporarily while you migrate their backup to an external destination. For per-account file exclusions, use the cpbackup-exclude.conf mechanism:
# Place in the account's home directory
echo "public_html/wp-content/uploads/video" >> /home/username/cpbackup-exclude.conf
cPanel stores uncompressed MySQL dumps in /home/username/.cpanel/datastore/ during partial backups. These accumulate silently:
find /home/*/mysql -name "*.sql" -mtime +3 | xargs gzip -9
/usr/local/cpanel/bin/backup --all-accounts
This triggers an on-demand full backup outside the cron window, so you can verify the fix before the next scheduled run.
Long-term Backup Storage Solutions (FTP, Cloud, External)
The only permanent solution to cPanel backup disk space failures is moving backups off the local filesystem entirely. Here are the three production-grade approaches used by enterprise hosting companies.
Option A: FTP/SFTP to a Dedicated Backup Server
In WHM → Backup → Backup Configuration → Additional Destinations, add a new destination of type FTP. Enter the hostname, port (usually 21 for FTP or 22 for SFTP), username, password, and remote path. Enable Transfer Retention so old backups are deleted from the remote server automatically. Test the connection before saving.
Best practice: use a backup server on a different network segment or data centre from your primary server. A backup on the same rack as the primary is nearly worthless in a hardware failure scenario.
Option B: Amazon S3 or S3-Compatible Object Storage
For servers managed through CloudHouse server management, we typically configure S3-compatible object storage (AWS S3, Backblaze B2, or Wasabi) as the primary backup destination. This eliminates disk space as a constraint entirely — object storage scales infinitely and costs roughly $0.005/GB/month on Wasabi.
In WHM, add a new Custom (S3-Compatible) destination and enter:
- Bucket name and region endpoint
- Access key ID and secret access key
- Remote path prefix (e.g.
backups/server1/) - Timeout: 900 seconds for large accounts
For AWS S3 specifically, attach an IAM policy that grants only s3:PutObject, s3:GetObject, s3:DeleteObject, and s3:ListBucket on the target bucket — not full S3 access.
Option C: Separate Local Partition Mount
If external storage is not yet an option, at minimum mount a dedicated partition (or an LVM logical volume) at /backup. Never store backups on the same partition as /home. A separate mount means backup space exhaustion cannot crash account operations, and vice versa.
# Create and mount a new LVM volume for backups
lvcreate -L 200G -n backup vg0
mkfs.ext4 /dev/vg0/backup
mkdir -p /backup
echo "/dev/vg0/backup /backup ext4 defaults 0 2" >> /etc/fstab
mount -a
Multi-Destination Strategy
Enterprise-grade hosting operations configure at least two destinations: one local (fast restore) and one remote (disaster recovery). cPanel supports up to 10 additional destinations simultaneously. Configure both to the same retention window so local and remote copies stay in sync.
Monitoring and Prevention: Alerting on Low Disk Space
The highest-impact prevention measure is getting alerted before disk space becomes a problem, not after a backup fails.
cPanel/WHM Built-in Disk Alerts
In WHM → Server Configuration → Tweak Settings → Notifications, enable:
- Disk Usage Warning Threshold: 75% (email alert sent)
- Disk Usage Critical Threshold: 90% (escalation alert)
- Backup failure notifications: enabled
Confirm that the Contact Email in WHM → Server Configuration → Basic WebHost Manager Setup is a monitored inbox, not a mailbox on the same server that could be unreachable if the server has problems.
Custom Bash Alert Script (cron-based)
For finer-grained control, deploy this script as a cron job that fires 30 minutes before the backup window:
#!/bin/bash
# /usr/local/sbin/check_backup_space.sh
THRESHOLD=80
BACKUP_MOUNT="/backup"
EMAIL="admin@yourdomain.com"
USAGE=$(df "$BACKUP_MOUNT" | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
echo "ALERT: Backup partition at ${USAGE}% on $(hostname)" | mail -s "Low Backup Space Warning" "$EMAIL"
fi
# Add to root crontab (fires at 00:30, before 01:00 backup window)
30 0 * * * /usr/local/sbin/check_backup_space.sh
Automated Backup Pruning Before Each Run
For advanced environments, run a pre-backup hook that removes old backups automatically:
#!/bin/bash
# /usr/local/cpanel/scripts/pre_backup
# Automatically remove daily backups older than 5 days before each run
find /backup/cpbackup/daily -maxdepth 1 -type d -mtime +5 -exec rm -rf {} \;
logger "pre_backup hook: old backup directories pruned"
cPanel executes scripts at /usr/local/cpanel/scripts/pre_backup and post_backup automatically at the start and end of each backup run.
Prometheus + Alertmanager for Multi-Server Setups
If you manage more than a handful of servers, a metrics stack is far more scalable than per-server cron email scripts. Install node_exporter on each cPanel server and configure an Alertmanager rule:
- alert: BackupDiskSpaceLow
expr: (node_filesystem_avail_bytes{mountpoint="/backup"} /
node_filesystem_size_bytes{mountpoint="/backup"}) < 0.20
for: 5m
labels:
severity: warning
annotations:
summary: "Backup disk below 20% free on {{ $labels.instance }}"
This fires a PagerDuty or Slack alert the moment any backup partition drops below 20% free, giving you hours of lead time before the next backup window.
FAQs
Why does cPanel say "no space left on device" even though df shows free space?
This usually means the filesystem has run out of inodes, not blocks. Run df -i and check the IUse% column. If it shows 100%, the filesystem cannot create new files even though block space remains. Prune small temporary files under /tmp, /var/tmp, or /home to free inodes, or move backups to a partition with a higher inode count (XFS handles this better than ext4 for large numbers of small files).
How much free disk space does cPanel need to run backups?
As a rule of thumb, the backup destination needs at least 1× the total size of all accounts you are backing up (more if you keep multiple generations). WHM's pre-flight check requires a minimum of 100 MB free before it will even start. For incremental backups, add 10–20% overhead for the compression and manifest files. Always aim to keep backup partitions no more than 70% full under normal operation.
Can I pause backups for specific large accounts to free up space?
Yes. In WHM → Backup → Backup Configuration → Accounts to Exclude, add the cPanel username. The account's data will be skipped in all future backup runs until you remove it from the exclusion list. This is a useful emergency measure but should not be left in place long-term — move that account's backups to an external destination instead.
What is the safest way to delete old cPanel backups manually?
Use find with -mtime to target only files older than your retention window, and always do a dry run first with find ... -print before adding -delete. Never delete the incremental directory base snapshots without also removing all the child incremental chains that depend on them — orphaned incrementals cannot be used for restore and waste space.
Does moving backups to S3 eliminate local disk space issues entirely?
It eliminates the backup destination disk space problem, but cPanel still uses local temporary space during backup creation before transferring to S3. Ensure /tmp has at least 2–3 GB free. You can change the cPanel temp directory by setting BACKUP_TEMP_DIR in /etc/cpanel/cpanel.config if your /tmp is small and you have a larger partition available.
