Your backup plugin starts, climbs a few percent, then sits there forever. In WPvivid the message is Task, backup_db is not responding. and the bar stops at 13%. Other plugins show a spinner that never ends or a backup with no SQL file in it.
That exact case is on the WordPress.org forums right now, with a 432 MB database. A manual SQL export from the host’s control panel worked fine. Only the plugin could not finish.
That pattern tells you a lot. The database is fine. The PHP process doing the dump runs out of time, memory or disk before it finishes, and a dump taken outside PHP does not have those limits.
So my fix is to get a good database backup first with WP-CLI, then shrink what makes the dump slow, then decide what the plugin should still do.
Step 1. Check free disk space before anything else
A dump needs room for itself, and a plugin often writes the SQL file and then a zip of it. On a full account the backup just dies partway.
df -h ~
du -sh wp-content/wpvivid* wp-content/updraft wp-content/ai1wm-backups 2>/dev/nullThe second line shows how much old backups take up for the common plugins. Folders that do not exist are skipped silently. If the disk is nearly full, start with Disk Quota Full in WordPress.
Step 2. Find the tables that make the dump slow
Ask WP-CLI for the total size, then the biggest tables first:
wp db size --human-readable
wp db size --tables --all-tables-with-prefix --orderby=size --order=desc --human-readableThe --orderby and --order flags were added in WP-CLI 2.7, per the wp db size docs. If your WP-CLI is older and the command fails, use this query instead:
SELECT table_name,
ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb,
table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 15;Run it with wp db query or paste it into phpMyAdmin. table_rows is an estimate for InnoDB tables, which is fine for this.
On most sites the top of the list is one of the usual suspects: wp_options full of transients, wp_postmeta, Action Scheduler tables, or a log table from a security, redirect or email plugin. A single log table can be bigger than all your content combined.
Step 3. Export the database with WP-CLI
Now take the backup the plugin could not. wp db export runs mysqldump for you and, as the official docs put it, accepts any valid mysqldump flags.
mkdir -p ~/db-backups
wp db export - --single-transaction --quick | gzip > ~/db-backups/db-$(date +%F).sql.gz
ls -lh ~/db-backups/The - sends the dump to STDOUT so it is compressed on the fly and never sits on disk uncompressed. --single-transaction gives a consistent snapshot of InnoDB tables without locking the site, and --quick streams rows instead of loading each table into memory.
The folder is in your home directory on purpose, outside the web root. A .sql file inside public_html can be downloaded by anyone who guesses the name.
Check that the dump is complete:
zcat ~/db-backups/db-$(date +%F).sql.gz | tail -n 1By default mysqldump ends the file with a -- Dump completed on line. If the last line is half an INSERT instead, the dump was cut off, so check disk space and the shell’s error output.
Need a smaller copy for staging? --exclude_tables skips tables you do not need there, like a huge log table:
wp db export ~/db-backups/staging.sql --exclude_tables=wp_actionscheduler_logs --single-transaction --quick💡 Replace wp_ with your table prefix, and only exclude tables from copies you would be fine restoring without them. Your real backup should have everything.
Step 4. Shrink what does not need to be backed up
With a good backup in hand, you can clean up safely. Expired transients are the easiest win:
wp transient delete --expiredYou should get a Success: line with the number of expired transients removed. More on that in Delete Expired WordPress Transients.
For log tables, use the plugin’s own setting to limit how long it keeps logs, then clear the old rows from its settings page. I would not truncate a plugin table by hand unless you know it only holds logs.
If wp_options is the big one, Suggestions to reduce the wp_options table size goes through what is usually safe to remove.
Decide what the plugin should still back up
Run the plugin again after the cleanup. If it still stalls, split the job the way people in the forum thread suggested: try a database-only backup to confirm it is the DB step that hangs, and switch the plugin to files-only.
Then let cron handle the database. A daily dump with a 7-day retention looks like this in crontab -e:
30 3 * * * cd /home/USER/public_html && wp db export - --single-transaction --quick | gzip > /home/USER/db-backups/db-$(date +\%F).sql.gz
0 4 * * * find /home/USER/db-backups -name 'db-*.sql.gz' -mtime +7 -deleteNote the \%. In a crontab line a bare % is treated as a newline, which cuts the command in half and breaks the job. If wp is not found under cron, use its full path from which wp.
Copy those files off the server too. A backup on the same disk as the site does not help when the disk or the account is gone.
If you would rather keep everything inside the plugin, ask your host what kills long PHP requests on your plan. Raising max_execution_time does nothing if the web server or a proxy in front of it drops the request first.
On OpenPanel the panel handles this side for you: the Backups feature dumps each MySQL/MariaDB database with --single-transaction before archiving, and users can set the schedule, retention and a remote destination themselves. On many cPanel servers the backup schedule is set by the server admin, and users mostly get manual downloads under Backup. Either way, the panel dump does not depend on a PHP request finishing.
For dumping only some tables with plain mysqldump, see Dumping specific tables using mysqldump or WP-CLI.
TL;DR: when a backup plugin hangs on the database step, the dump is usually dying inside a PHP request, not failing in MySQL. Check disk space, find the biggest tables with wp db size --tables, take the backup with wp db export - --single-transaction --quick | gzip outside the web root, clean up transients and logs, and let cron do the database while the plugin handles files. Plugin behavior can change between releases, so as of 2026-11-07 check your backup plugin’s own settings for a database-only or chunked option too.
