A failed backup may involve account packaging, local storage or remote transfer. Identify the failed stage before rerunning a large job, because repeated attempts can fill the disk or obscure the original error.
IN THIS ARTICLE
Gather the details you will need
Collect the job time, affected account or destination and the complete failure notification. Check free disk space and confirm no backup or transfer is already running for the same scope.
01 Investigate a failed WHM backup job
- As an authorised administrator, open the matching job log in
/usr/local/cpanel/logs/cpbackup/and locate the first relevant creation error. Match the job time and account before interpreting the entry. - For a remote-copy problem, inspect
/usr/local/cpanel/logs/cpbackup_transporteras an authorised administrator. Separate a completed local archive from a failed remote upload. - Check account quota, server free space, destination credentials, path permissions and network reachability according to the error.
- Correct the identified cause, then rerun only through the supported backup workflow at a time that will not overlap a production cycle.
- Verify the resulting archive and remote copy, and perform a sample recovery check. Confirm alerts return to their expected healthy state.
Check the backup or recovered data
The affected stage should complete and a usable recovery copy should exist. Retain older verified backups until the replacement is confirmed, particularly when retention settings could otherwise prune them.
If the problem continues
If a process appears stuck, inspect its status and logs before terminating it. Do not delete arbitrary staging files belonging to an active job. A destination validation pass does not guarantee enough storage or time for the largest real archive.
Should I raise the timeout first?
Only when evidence shows a legitimate transfer or restore needs more time. Authentication failures, full disks and inaccessible paths will not be fixed by waiting longer.