Skip to content
Rescue 404
Rescue

Website Backup & Restore

WordPress Backup Failed

Intermediate Risk: high

Last reviewed

Hosting access often needed Database access often needed

Direct answer

A WordPress backup usually fails because PHP hits a memory or execution-time limit, the server runs out of disk space or entry processes mid-job, or the remote storage destination (Dropbox, Google Drive, S3, FTP) rejects the connection — so read the exact error, free up resources or fix the destination, then retry the database and files as separate jobs if the full backup still times out.

Backups are the one job that has to touch every file and every database row, which makes them the fastest way to expose a hosting account that is low on memory, disk, or time. This guide separates the common failure signatures — memory exhaustion, timeouts, disk quota, broken remote storage, and database corruption — so you fix the actual bottleneck instead of clicking "retry" on a job that will fail the same way every time.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • A full WordPress restore needs both the database and the files; downloading wp-content alone does not back up MySQL/MariaDB data that lives outside the web root. (WordPress backups)
  • WordPress recommends keeping at least 3–5 recent backups in different locations so one failed or corrupted copy does not strand the site. (WordPress backups)
  • WordPress documents backing up the database before upgrades and moves, with phpMyAdmin Export as a supported manual path when plugin backups fail. (WordPress backups)

What the error means

A WordPress backup has two halves that fail differently: exporting the database (usually mysqldump under the hood) and archiving the files (themes, plugins, uploads, wp-config.php). Backup plugins wrap both into one job and report a single "failed" status, which hides which half actually broke. Shared hosting enforces PHP memory_limit and max_execution_time, plus CPU and entry-process caps that a backup can burn through in seconds on a large site. A multi-gigabyte uploads folder or a database bloated with post revisions, transients, and stale logs turns a five-minute job into one that never finishes inside those limits. Remote storage adds another failure point: expired OAuth tokens, full storage quotas, or a firewall blocking outbound connections will fail the upload step even after a clean local export. Treat "backup failed" as a symptom and find which stage — export, archive, or upload — actually stopped before changing anything.

Common symptoms

  • Backup plugin shows "Backup failed," a timeout notice, or the progress bar stalls at the same percentage every run
  • Manual export in cPanel/phpMyAdmin never completes, times out in the browser, or produces a 0-byte SQL file
  • PHP error log shows "Allowed memory size exhausted" or "Maximum execution time exceeded" during the backup window
  • Remote destination (Dropbox, Google Drive, S3, FTP) reports an authentication error, expired token, or connection refused
  • "No space left on device" or disk quota exceeded errors appear in the host panel or error log during the run
  • WP-CLI wp db export hangs or returns "MySQL server has gone away"
  • Downloaded backup archive is truncated, corrupt, or fails to extract
  • Scheduled automatic backups silently stop — the plugin dashboard shows a last-successful date that is weeks old with no failure alert

Most likely causes

  1. 01 PHP memory_limit or max_execution_time set too low for the site's current size
  2. 02 Large uploads folder or bloated database (post revisions, transients, log tables, orphaned postmeta) pushes the job past resource or time caps
  3. 03 Third-party storage credentials expired, were revoked, or the destination quota is full
  4. 04 Shared hosting CPU/entry-process limits throttle or kill the backup process mid-run
  5. 05 Security plugin, firewall, or mod_security rule blocks the outbound connection to remote storage or blocks the plugin's own admin-ajax calls
  6. 06 Corrupted database table (often MyISAM) causes mysqldump or the plugin's export routine to hang or error out
  7. 07 Server disk space exhausted because old local backup copies were never rotated out
  8. 08 Backup plugin conflicts with a caching or security plugin that intercepts the long-running request

What changed before the problem started

  • Site grew — more media uploads, more orders/posts, or years of accumulated revisions and transients since the last successful backup
  • Backup plugin or WordPress core updated and changed default chunk size, timeout handling, or storage integration
  • Hosting plan downgraded, or the site moved to a more resource-constrained shared server
  • Storage provider (Dropbox/Google Drive/S3) revoked or expired the connected API token
  • wp-config.php or server php.ini changed, lowering memory_limit or max_execution_time
  • A traffic spike or another scheduled job (cron, cache warm, security scan) is now competing for resources during the same backup window

Troubleshooting steps

  1. 01

    Read the exact failure message, not just "backup failed"

    Open the backup plugin's log/history screen and the host's PHP error log for the timestamp of the failed run. A memory error, a timeout, a storage-auth error, and a disk-space error each point to a different fix — do not guess. Success signal: you can name the specific stage (export, archive, or upload) and the specific limit that was hit.

  2. 02

    Check disk space and database size on the host

    In cPanel/Plesk statistics or via SSH (df -h), confirm free disk space. In phpMyAdmin, check the database size and largest tables — wp_options, wp_postmeta, and revision-heavy wp_posts are common bloat sources. Success signal: at least 2–3x the database size is free on disk for a local dump before upload.

  3. 03

    Clean up bloat before retrying

    Delete old post revisions and expired transients (via WP-CLI wp post delete or a trusted cleanup plugin), empty spam/trash comments, and remove local backup copies the host or plugin left behind from earlier failed attempts. Success signal: database size and disk usage both drop measurably.

  4. 04

    Raise PHP memory and execution time modestly for the backup window

    Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, or ask the host to raise memory_limit and max_execution_time for the backup process specifically. Do not set these to unlimited on shared hosting — the host's hard cap will still apply and may terminate the process anyway.

  5. 05

    Verify the remote storage destination independently

    Disconnect and reconnect Dropbox/Google Drive/S3 in the plugin settings, or test the FTP/SFTP credentials with a standalone client. An expired OAuth token or full storage quota will fail every backup until reconnected, even though the local export step works fine.

  6. 06

    Split the job into database-only and files-only backups

    Most backup plugins let you run a database export and a files archive separately. If one half succeeds and the other times out, you have isolated the bottleneck (usually the files archive on media-heavy sites) instead of re-running the whole combined job repeatedly.

  7. 07

    Retry manually during a low-traffic window with logging enabled

    Trigger the backup by hand rather than waiting for the schedule, ideally at off-peak hours when other cron jobs and visitor traffic are not competing for the same CPU/entry-process allowance. Success signal: the job completes and the plugin log shows no timeout or memory warnings.

When to stop troubleshooting

Stop troubleshooting on production if the site is large enough that every retry consumes a meaningful chunk of your hosting resource allowance, if you suspect database corruption beyond a single table, if you do not have SSH/WP-CLI or hosting panel access to check real resource usage, or if you need a verified-restorable backup before a risky change and cannot confirm one exists. Escalate with the exact error text, database size, current PHP limits, and the last date a backup actually completed and was restore-tested.

Information to collect before requesting help

  • 01 Backup plugin name, version, and the exact error or log excerpt from the failed run
  • 02 Whether the failure happens on database export, file archive, or remote upload specifically
  • 03 Current PHP memory_limit and max_execution_time (from phpinfo() or wp-admin → Site Health)
  • 04 Disk space used vs. available on the hosting account
  • 05 Storage destination in use (local, Dropbox, Google Drive, S3, FTP) and any auth error shown
  • 06 Database size and the largest tables (from phpMyAdmin)
  • 07 Hosting provider, plan type (shared/VPS/managed), and any recent plan or resource-limit changes
  • 08 Date of the last backup that actually completed and was verified restorable

How a professional repairs the problem

We isolate which stage of the backup pipeline is failing — export, archive, or upload — by reading plugin logs alongside the raw PHP and MySQL error logs, then measure actual database size, table health, and disk headroom rather than guessing at limits. We clean up bloat (revisions, transients, oversized log tables), right-size PHP memory and execution time within what the host allows, repair any corrupted tables, and reconnect or replace a failing remote storage destination. Once a backup completes cleanly, we run a real test restore to staging to confirm the archive is usable, then set a sustainable, monitored backup schedule so failures surface immediately instead of silently for weeks.

Frequently asked questions

Why does the backup fail at the same percentage every time? +
A consistent stall point usually means a specific large table or folder is hit at that stage — check the plugin log for what it was processing when it stopped, since it is rarely a random timeout.
Is a 0-byte or missing backup file the same problem as a "failed" status? +
Often worse — it can mean the job crashed silently without the plugin recording a proper failure. Always check the actual file size and try opening/extracting it, not just the plugin's reported status.
Should I just disable the security plugin to fix a backup failure? +
Only temporarily and only to test. If disabling it fixes the backup, add a specific allowlist rule for the backup plugin's process instead of leaving security protections off long-term.
Can I back up the database and files separately and still restore fully? +
Yes — a database export plus a files archive together are a complete backup set. Just make sure both are from close to the same point in time so content and structure stay in sync.
Will upgrading my hosting plan fix repeated backup failures? +
It can help if you are genuinely out of memory, disk, or CPU headroom, but clean up bloat and fix any broken storage connection first — a bigger plan will not fix an expired Dropbox token or a corrupt table.
How do I know a backup is actually good without restoring my live site? +
Restore it to a staging site or a local environment. A backup you have never test-restored is unverified, regardless of what the plugin dashboard says.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.