An overnight backup still shows 73 percent in the morning, while a second attempt fails after several minutes. The site remains online, but repeatedly restarting the job consumes disk space and makes the original evidence harder to interpret.
This guide shows how to tell a slow backup from a stalled one, isolate the failed stage, and retry without putting the last valid recovery point at risk.
What it means
A backup is stuck when its worker no longer makes meaningful progress; it has failed when the process ends without a complete, usable package. Archive creation, database export, local staging, and remote transfer are separate stages, so the percentage shown in wp-admin does not identify the cause by itself.
- A changing archive size or fresh log entry indicates slow progress, whereas unchanged timestamps support a genuine stall.
- Large media files, unreadable paths, insufficient temporary space, execution limits, and remote-storage timeouts fail at different stages.
- A single slow job on a very large site may need observation rather than cancellation if files and logs continue to change.
A realistic WordPress example
An overnight backup still shows 73 percent in the morning. Its temporary archive has not changed for two hours, and the log ends during the upload stage. Starting the job again would create another large temporary file without addressing the likely storage or network problem. The useful next step is to preserve the job details and determine whether a complete local archive exists.
Why it matters and when to investigate
Investigate when scheduled jobs overlap, packages repeatedly remain incomplete, or the newest valid recovery point is older than your retention policy allows. First distinguish a slow backup from a stalled one: changing file sizes and fresh log entries show activity, while unchanged files, timestamps, and logs make a genuine stall more likely.
A straightforward route for beginners
- Before cancelling, record the job identifier, start time, last reported stage, latest log lines, and current package size.
- Check free disk space and inode availability on the server, then check the remote destination’s quota and availability.
- Run one smaller diagnostic job, such as a database-only backup or a file backup without a known large media directory.
- Correct the specific cause. Remove only temporary packages that no running worker still uses, then retry once.
- Open the finished package and restore it in an isolated environment. A completion message alone is not a recovery test.
The advanced route
Match the failure time with PHP, web-server, system, and backup logs. Look for memory exhaustion, execution time limits, killed workers, unreadable paths, file-size limits, and connection timeouts. If a complete local archive exists, the backup stage succeeded and the fault lies in transfer or remote storage. If it does not, inspect the last file or database step reached.
On a large site, note which files change during the run and whether archive growth is steady. One unusually large file, recursively included old backups, or a directory with many small files can dominate the job. After a successful run, keep its duration and package size as a realistic baseline for the next investigation.
Risks, common mistakes, backup, and rollback
- Repeated retries can fill the disk, overlap workers, and hide the first useful error.
- Deleting temporary files while a worker still owns them can turn a slow job into a failed one.
- Increasing every PHP limit may mask the cause and create new load without fixing permissions or remote storage.
- A newly completed package must not replace the last verified recovery point until it passes a restore test.
If the diagnostic change does not help, restore the previous schedule and settings, retain the logs, and keep the last known-good backup. Escalate the exact failing stage to the host or storage provider instead of launching more identical jobs.
How AIOWS helps
AIOWS Backup Manager
AIOWS Backup Manager keeps supported backup jobs and their selected scope in one place. When a job appears stuck, note its start time, destination, current stage, and package size before cancelling it. A smaller database-only or files-only job can help identify which part of the full backup is failing without immediately repeating the same workload.
The module cannot remove server resource limits, repair unreadable files, or guarantee a third-party storage connection. Use the job information alongside server and PHP logs, local capacity, and the remote destination’s status. After correcting the cause, run one controlled retry and verify the resulting package with an isolated restore.
Keep the previous verified recovery point until that test succeeds. Record the correction, the successful duration and size, and the next scheduled run. Those figures provide a useful comparison if the same site later slows down or stops at a similar stage.
Related AIOWS articles
- WordPress Restore Failed or Stuck? Causes and Fixes
- Back Up a Large WordPress Site: Safe Step-by-Step Guide
- Verify a WordPress Backup: Prove It Can Be Restored
Conclusion and recommended route
Do not solve a stuck backup by repeatedly pressing Start. Preserve the job evidence, locate the stalled stage, correct that specific storage, permission, resource, or network condition, and run one controlled retry. The work is complete only when the resulting package passes an independent restore test.
