If your cPanel backup failed overnight and you are not sure whether your hosting accounts are actually protected, you are not alone. Backup failures are one of the most common — and most dangerous — issues on cPanel/WHM servers. A silent failure means no alert, no recovery copy, and a very bad day when a drive fails or a client account gets hacked. In this guide, we cover the 6 most common cPanel backup failure types and how to fix each one with step-by-step WHM commands.
Why cPanel Backup Failures Are Dangerous for Hosting Servers
For a web hosting company managing dozens or hundreds of cPanel accounts, backups are your last line of defence. When WHM reports a backup failure — or worse, silently fails without any alert — you face several risks:
- No recovery point — if a client account is compromised or files are deleted, you have nothing to restore from
- SLA violations — most managed hosting SLAs guarantee a recovery time objective that requires working backups
- Client trust — a hosting company that cannot restore files loses clients permanently
- Compliance risk — GDPR and similar regulations require data protection measures; missing backups expose you to liability
The most dangerous scenario is a silent backup failure — where WHM shows success in the UI but the backup file is corrupt or never reached the remote destination. We cover how to prevent this at the end of this guide.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Fix 1: "Connection to Remote Server Stalled" Error
This is the most common cPanel remote backup error. WHM attempts to connect to your FTP, SFTP, or S3 remote backup destination and the connection drops mid-transfer.
What causes it
- Firewall blocking FTP passive mode ports on the remote server
- Network timeout between the cPanel server and the backup destination
- Incorrect FTP credentials or the remote directory no longer exists
- Backup file too large, hitting a default FTP transfer timeout
Step-by-step fix
Test the FTP connection directly from the server:
ftp -n your-backup-host.com
user your-ftp-username your-password
lsIf this fails, the credentials or a firewall rule on the destination — not cPanel itself — is the problem.
In WHM → Backup → Configure Backup → Additional Destinations, change the transport to SFTP. SFTP uses a single port (22) and is far more reliable across firewalls than passive FTP.
Add to /var/cpanel/backups/config:
backup_timeout=14400This allows 4 hours per account, which covers most large-account backups.
echo "40000 50000" > /etc/pure-ftpd/conf/PassivePortRange
systemctl restart pure-ftpd
firewall-cmd --permanent --add-port=40000-50000/tcp && firewall-cmd --reloaddf -h /path/to/backup/directoryIf the partition is full, either expand it or lower your backup retention count in WHM → Backup → Configure Backup → Retention.
chown -R backupuser:backupuser /backups/cpanel/
chmod 755 /backups/cpanel/The FTP/SFTP user must own the backup destination directory. World-writable directories (777) will also cause cPanel to reject the write for security reasons.
quota -u backupuserIf a quota is set and reached, either increase it or use a dedicated backup user with no quota limit.
cat /root/.my.cnfThe [mysqldump] section must have the correct root password. If the MySQL root password was changed manually without updating this file, all database backups will silently fail.
/scripts/mysqlpasswd --user=root --pass=NEW_SECURE_PASSWORDThis cPanel-native script safely resets the MySQL root password and updates all relevant config files simultaneously, including /root/.my.cnf.
systemctl status mysql
mysql -e "SHOW STATUS LIKE 'Uptime';"If MySQL crashes repeatedly, check /var/lib/mysql/hostname.err for InnoDB corruption errors before attempting the backup again.
du -sh /home/*/public_html | sort -rh | head -20Accounts over 5GB are the most likely culprits.
In WHM → Backup → Configure Backup, set Backup Process Niceness to 19. This prevents the backup process from competing with live web traffic, which is the primary cause of timeout-inducing server overloads.
Switch to Incremental backup type in WHM → Backup → Configure Backup → Backup Type. After the first full backup, incremental runs only copy changed files — reducing backup runtime by 70–90% for large accounts.
Add exclusions to /etc/cpbackup-userskip.conf:
tmp
cache
.cache
node_modules
.npmdu -sh /backup/cpbackup/*/
ls -lht /backup/cpbackup/daily/ | head -20In WHM → Backup → Configure Backup → Retention, set:
- Daily backups to keep: 3 (7 days of large accounts fills disks fast)
- Weekly backups to keep: 2
- Monthly backups to keep: 1
# /etc/cron.daily/cpanel-backup-cleanup
find /backup/cpbackup/daily -name "*.tar.gz" -mtime +4 -delete
find /backup/cpbackup/weekly -name "*.tar.gz" -mtime +16 -deleteA full backup disk must never take down live sites. Mount a dedicated backup volume at /backup and point WHM at it — this is the single most important infrastructure decision for any cPanel hosting company.
crontab -l -u cpanelbackup 2>/dev/null
ls -la /etc/cron.d/ | grep cpanel/usr/local/cpanel/bin/servers_queue run --verboseIf the queue is blocked, restart the cPanel queue service:
systemctl restart cpanel-taskqueuewhmapi1 backup_create_backup account=username type=accountWatch /usr/local/cpanel/logs/cpbackup/ in real time to see exactly what happens.
In WHM → Server Contacts → Configure Server Notifications → Backup, enable failure alerts. This is disabled by default on most cPanel installations.
#!/bin/bash
# /usr/local/bin/check-cpanel-backups.sh
BACKUP_DIR="/backup/cpbackup/daily"
FAILURES=0
for account_dir in "$BACKUP_DIR"/*/; do
account=$(basename "$account_dir")
backup_file=$(ls "$account_dir"*.tar.gz 2>/dev/null | head -1)
if [ -z "$backup_file" ]; then
echo "MISSING: $account" >&2
((FAILURES++))
elif ! tar -tzf "$backup_file" > /dev/null 2>&1; then
echo "CORRUPT: $account" >&2
((FAILURES++))
fi
done
[ "$FAILURES" -gt 0 ] && echo "$FAILURES backup failures on $(hostname)" | mail -s "cPanel Backup Alert" [email protected]Schedule this at 07:00 daily — 4 hours after your nightly backup window ends.
When to Call a Managed Server Support Expert
Some backup failures point to deeper infrastructure problems that require expert hands:
- Recurring MySQL crashes during backup — InnoDB table corruption requires careful repair; the next backup will also fail without fixing the root cause
- Backup I/O causing site slowdowns — requires tuning the backup schedule, niceness, and concurrent account limits together
- Setting up S3 or Backblaze B2 remote backup destinations — API credential setup and lifecycle rules need careful configuration
- Restoring from a partially corrupt backup — requires skilled partial restore techniques and file carving
Our managed cPanel support team at CloudHouse Technologies handles backup configuration, failure diagnosis, and restoration for hosting companies in the US, UK, Canada, Europe, and Asia — 24/7. If your backups are failing and you need them fixed today, we can help.
cPanel backup failures are almost always fixable once you identify which of the 6 failure types you are dealing with. The critical step most hosting companies skip is proactive monitoring — knowing about a failure within hours rather than finding out during a disaster recovery. Set up WHM backup alerts, add the integrity check cron, and use a dedicated backup partition. If you are managing multiple cPanel servers and need someone to handle backup infrastructure reliably, CloudHouse's managed server support is built exactly for that.