Quick fixes
- Run at low-traffic times: In UpdraftPlus → Settings, schedule backups for off-peak hours.
- Increase resumption attempts: UpdraftPlus → Advanced tools → Show expert settings → set “Split archives” to a smaller size (e.g., 25–50MB) and raise “Backups to attempt resumption” to 10–15.
- Switch database engine: In UpdraftPlus → Settings → Database backup:
- If available, try using
mysqldump (fast and reliable).
- If
mysqldump is not available or unstable, fall back to PHP mode.
- Disable DB encryption (temporarily): If enabled, turn off database encryption to remove CPU overhead while testing.
- Manually start a fresh backup after saving the changes.
Step 1: Read the last log (know what failed)
Go to UpdraftPlus → Advanced tools → View last log. Look for lines that mention database, resumption, timeout, or a specific table name. Note the last table processed; that’s your likely bottleneck.
Step 2: Find and tame oversized tables
Huge or constantly written tables (e.g., wp_actionscheduler_*, WooCommerce sessions, analytics logs, security logs) commonly stall backups. Use WP-CLI to list sizes:
# List table sizes (top offenders bubble up)
wp db size --all-tables --format=table
# (Optional) Export just the DB first to confirm access/performance
wp db export updraft-db-test.sql
Options if a single table is enormous:
- Prune logs/transients in the offending plugin (e.g., analytics, security, caching).
- Temporarily exclude that table in UpdraftPlus → Settings → Exclude these tables (then back it up separately later).
- Optimize/repair the table (see Step 3).
Step 3: Repair and optimize the database
Corruption or fragmented indexes can halt the dump process.
# Quick health check
wp db check
# Attempt repairs (safe; monitor output)
wp db repair
# Optional: optimize (reclaims space; can be slow on large tables)
wp db optimize
No WP-CLI? Use phpMyAdmin’s Repair/Optimize on the largest tables or enable WordPress’s built-in repair page temporarily by adding to wp-config.php:
define('WP_ALLOW_REPAIR', true);
Visit https://example.com/wp-admin/maint/repair.php, run Repair/Repair and optimize, then remove that line from wp-config.php.
Step 4: Pick the right database dump engine
mysqldump is faster and more resilient but requires host support. In UpdraftPlus Settings → Database:
- Enable “Use
mysqldump” if the server provides it (your host can confirm the path; common: /usr/bin/mysqldump).
- If
mysqldump fails or isn’t available, set UpdraftPlus to use PHP for the DB dump and increase the resumption attempts.
Step 5: Give PHP more room (timeouts/memory)
On constrained hosting, the dumping/compression step may hit limits. Increase values (any one method you control):
// wp-config.php (above the "That's all" line)
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');
# .user.ini or php.ini (if available)
max_execution_time = 300
memory_limit = 256M
After saving, restart PHP (or ask your host) and retry.
Step 6: Make UpdraftPlus more “resumable”
- In Settings → Advanced/expert options, set Split archives to 25–50MB to keep chunks small.
- Increase Resumption attempts to 10–15 so the job restarts more times instead of aborting.
Step 7: Make sure WP-Cron and scheduled jobs actually run
If DISABLE_WP_CRON is true or the site gets little traffic, jobs may never resume.
// wp-config.php ensure this is absent or set to false
define('DISABLE_WP_CRON', false);
# Manually run due cron events once
wp cron event run --due-now
Step 8: Test a database-only backup
In UpdraftPlus → Backup/Restore, click Backup now and select only Database. If that succeeds, your fixes are working; re-enable full backups.
If it still fails…
- Send the full UpdraftPlus log to your host or UpdraftPlus support. Look for repeated retries on the same table or “killed” processes.
- Ask your host for the path to
mysqldump or for a temporary bump to max_execution_time/memory_limit.
Prevention tips
- Schedule backups when traffic is light; keep resumption attempts > 8.
- Regularly purge log tables (analytics, security, cache) and expired transients.
- Monitor growth of
wp_actionscheduler_*, wp_options (autoload bloat), and session tables.