How to Fix the “Could Not Backup Table” Backup Error

Why am I seeing this?

The “Could not backup table” error means a specific database table is either corrupted or too large for your server’s current resource limits to export. The fix depends on which: repair the table if it’s corrupted, or raise server limits if it’s intact but oversized. Most sites resolve this with a single table repair in phpMyAdmin.

Key Takeaways

• A corrupted database table is the most common cause and repairing it in phpMyAdmin resolves the issue immediately.
• If the table is intact but large, data flows from MySQL → PHP → ManageWP’s servers, so troubleshoot in that order: MySQL limits first, then PHP limits.
• A bloated table (usually from a plugin storing excessive transient data or logs) should be cleaned up after the backup is working again to prevent recurrence.

What typically causes this?

The error names the specific table that failed. In most cases, it’s one of:

• Table corruption — the table is physically damaged, usually from a server crash, disk issue, or interrupted MySQL write operation.
• MySQL packet size or timeout limit — the max_allowed_packet setting (the maximum size of a single data chunk MySQL will export at once) is too low for a large table, or the wait_timeout value is too short and MySQL drops the connection mid-export.
• PHP resource exhaustion — PHP runs out of memory or execution time while processing the exported data.
• Table bloat — a plugin is storing excessive data (transients, logs, activity records) in a table that grows indefinitely. The table isn’t corrupted, just too large for the current server limits to handle.

If the error names a particularly large table, all causes are plausible. If it names a smaller table, corruption is almost certainly the issue.

How do I fix this error?

Step 1: Repair the table in phpMyAdmin

This resolves the majority of cases. You’re checking whether the table is corrupted and repairing it if so.

Check the table first:

1. Log in to your hosting control panel and open phpMyAdmin.
2. Choose the affected database from the left sidebar. If you only have one database, it should already be selected.
3. In the main panel, you’ll see a list of your database tables. Find and select the table named in your error message.
4. At the bottom of the table list, there’s a drop-down menu. Choose Check Table from that menu.

When the page refreshes, you’ll see a status summary. If the result says “OK,” the table isn’t corrupted, you can skip ahead to Step 2. If you see any errors or a “corrupt” status, repair it next.

Repair the table:

1. Select the corrupted table from the list.
2. Choose Repair Table from the same drop-down menu at the bottom of the screen.

The repair usually completes in a few seconds. Once it’s done, retry the backup from your ManageWP dashboard. If it succeeds, you’re done, the corruption was the issue. If the table checks out as healthy but the backup still fails on it, the problem is server resource limits. Continue to Step 2.

Step 2: Increase the MySQL max_allowed_packet and wait_timeout values

The max_allowed_packet setting caps the size of a single data packet during database export. When a table or row exceeds this limit, the export breaks mid-stream before PHP ever touches the data.

The wait_timeout setting controls how long MySQL keeps a connection open when it’s idle between operations. If your host has set this low and there are pauses between table exports during the backup process, MySQL drops the connection mid-backup.

1. Ask your hosting support team to check your my.ini or my.cnf file (MySQL’s main configuration file, usually managed by your host) for the current max_allowed_packet and wait_timeout values. If you have server-level access, check them yourself.
2. Raise max_allowed_packet. A common starting point is 256M, but the right value depends on your largest table size (your host can advise).
3. Raise wait_timeout if it’s set low. The default is 28800 (8 hours), if your host has lowered it, ask them to restore it to at least that value.

Retry the backup after the changes. If it completes, MySQL was the bottleneck. If it still fails, the data is leaving MySQL successfully but PHP can’t handle it and you can continue to Step 3.

Step 3: Raise your PHP resource limits

Once the data leaves MySQL, PHP processes the backup. If PHP’s resource limits are too low for the size of the export, it runs out of memory or time partway through and the process dies.

1. Log in to your hosting control panel and open File Manager.
2. Navigate to the root directory of your WordPress installation.
3. Locate the php.ini or .user.ini file.
4. Compare the values against these recommended settings:

memory_limit = 512M

max_execution_time = 300

5. If either value is lower, edit the file and save.

The new limits take effect after the PHP cache refreshes — usually within 5 minutes on most hosting environments.

Note: php.ini defines global PHP settings for the entire server, while .user.ini allows PHP settings to be overridden on a per-directory basis and is typically used when php.ini can’t be modified directly.

If you can’t find or edit the file: On shared hosting, your ability to change these values is often restricted. Contact your hosting support team as they can either raise the limits for you or confirm that your plan caps them below what backups need.

Step 4: Clean up the bloated table

If the table is healthy but its size is causing the backup to fail, the underlying issue is a plugin storing data without ever cleaning it up.

1. Open phpMyAdmin and navigate to the table named in your error message. Click Browse to view its contents.
2. Identify which plugin is responsible. The entry names or prefixes typically make this obvious.
3. Once you’ve identified the plugin, check its settings for a data retention, log rotation, or cleanup option. Many plugins have this buried under an advanced or performance tab. If it has one, configure it to auto-purge entries older than a reasonable window (30–90 days is typical).
4. Delete the unnecessary entries. In phpMyAdmin, you can use the Delete function on selected rows, or run a query to remove entries older than a specific date if the table has a timestamp column.
5. After cleanup, go back to the table list, select the cleaned-up table, and choose Optimize Table from the drop-down menu at the bottom of the screen. This reclaims the disk space freed by the deleted rows.
   

What to keep in mind for next time?

Table corruption is a hosting-level event: server restarts, disk errors, or resource exhaustion during high-traffic periods. A quick CHECK TABLE in phpMyAdmin confirms it in seconds. For large-but-healthy tables, the signal is a plugin that grows a table indefinitely without cleanup.

Still stuck?

If repairing the table and raising both MySQL and PHP limits haven’t resolved the backup failure, your site likely has an edge case beyond what the standard fix covers. Contact our support team with:

• The exact error message (including the table name and size)
• Whether CHECK TABLE reported the table as healthy or corrupted
• Your current max_allowed_packet, wait_timeout, memory_limit, and max_execution_time values

Frequently Asked Questions

Can I exclude the problem table from backups instead of fixing it?

You can exclude specific database tables in your ManageWP dashboard under the site’s Backup settings. But excluding a table means that data won’t exist in your restore points — if you ever need to restore, whatever that table holds is gone. Fixing the root cause is the better path unless the table is genuinely disposable (transient caches, expired session data, etc.). Note that default WordPress tables (like TABLE_PREFIX_options or TABLE_PREFIX_posts) cannot be excluded and if one of those is the problem, you’ll need to repair or clean it up directly.

Will this corruption come back?

It depends on what caused the database tables to be corrupted. Persistent recurrence is a signal to talk to your host about server health or consider a hosting upgrade.

What if the table is huge because of a plugin filling it with data?

This usually means a plugin is storing data without cleaning up after itself (activity logs, analytics records, form entries, or expired transients that accumulate indefinitely). Identify which plugin owns the table (the table name prefix usually matches the plugin), check that plugin’s settings for a data retention or purge option, and optimize the table in phpMyAdmin after cleanup. Leaving the table bloated means you’ll hit this issue again as it grows.