"Packet bigger than max_allowed_packet" is a MySQL server/client limit, not a sign your backup file is corrupted. It's also not the same thing as phpMyAdmin's file upload limit, which is a separate, commonly confused problem. This is different from UpdraftPlus's own backup errors, which happen during backup creation. This error shows up during restore — importing a .sql file back into a database — and it happens the same way regardless of which tool you're using: phpMyAdmin, WP-CLI, a migration plugin, or the raw mysql command line.

Symptoms

You see this exact error while importing a WordPress database backup:

ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes

It shows up in phpMyAdmin's import screen, in WP-CLI's wp db import output, on the command line running mysql -u user -p database < backup.sql, or buried in a migration plugin's log after the import stalls or fails partway through.

Why this happens

The real cause is narrower than "the file is too big." A single SQL statement inside the file, usually one INSERT statement, exceeds MySQL's configured packet-size limit. Standard export tools (mysqldump, WP-CLI's wp db export, most backup plugins) write multi-row INSERT statements by default for speed, so a table with wide rows or a lot of columns can trip this on one statement even if the overall file isn't huge.

According to MySQL's own reference manual, the default packet-size limits are 16MB for the MySQL client and 64MB for the server as of MySQL 8.0. Here's the part most troubleshooting guides skip: both the client and the server have their own separate max_allowed_packet setting. MySQL's docs state it directly: "if you want to handle big packets, you must increase this variable both in the client and in the server." Raising the limit in my.cnf alone fixes server-side imports but does nothing for a command-line import, because the mysql client you're running still enforces its own 16MB default.

This is a different limit from phpMyAdmin's upload restriction. phpMyAdmin imports pass through PHP's own upload_max_filesize and post_max_size settings before the file ever reaches MySQL. A file can get rejected by phpMyAdmin before any database error happens at all, or it can pass phpMyAdmin's upload check and still fail with the MySQL 1153 error once the import actually starts running. If your error happens the instant you try to upload the file, before any progress bar or import log appears, you're likely hitting the PHP upload limit instead — that's a different fix (raising upload_max_filesize/post_max_size in php.ini), not the one below.

WP-CLI does not bypass this error. Per WP-CLI's own wp db import documentation, the command runs the system mysql client under the hood, the same one subject to the 16MB client default described above. What WP-CLI actually skips is phpMyAdmin's browser upload step, since it reads the file straight from disk instead of uploading it through HTTP. That's a real advantage for large files, but it doesn't touch the packet-size limit itself — you still need the fix below.

Fix it: lowest-risk steps first

Step 1 — Confirm you're hitting the right limit

Check exactly where the error appears. If phpMyAdmin rejects the file before any import activity starts, that's the PHP upload limit, not this one — raise upload_max_filesize and post_max_size in your host's PHP settings instead. Only continue with the steps below if you see the exact ERROR 1153 text quoted above, during the import itself.

Step 2 — Raise it temporarily with SET GLOBAL (no restart needed)

Connect to MySQL (via phpMyAdmin's SQL tab, WP-CLI's wp db cli, or a direct mysql -u root -p session) and run:

SET GLOBAL max_allowed_packet=1073741824;

That sets it to 1GB, MySQL's maximum possible value, and takes effect immediately without restarting the service. This is the fastest fix for a one-time restore. It resets back to the configured default the next time MySQL restarts, so it's not meant to be permanent — for that, see Step 3.

WP-CLI users can do this in one session with wp db cli to open an interactive MySQL shell using WordPress's own database credentials, run the SET GLOBAL command above, then SOURCE backup.sql; to run the import from inside the same session.

Step 3 — Make it permanent in my.cnf, if you'll do this again

For anyone restoring backups more than once — agencies, frequent site migrations — edit the MySQL configuration file directly. On most Linux hosts this is /etc/mysql/my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf. Add or edit this line under the [mysqld] section:

[mysqld]
max_allowed_packet=256M

Restart MySQL for the change to take effect. On an aaPanel-hosted server, the same my.cnf file is reachable through the panel's Database section rather than editing it over SSH directly — if you're not comfortable finding the exact file through the panel UI, editing it directly over SSH at the path above works identically and is the more universally documented route.

Remember the client-side half of this from the "why this happens" section above: if you're importing from the command line rather than through phpMyAdmin, you may also need max_allowed_packet=256M under a [client] section in the same file, or pass --max_allowed_packet=256M directly as a flag to the mysql command.

Step 4 — If you can't touch MySQL config at all

Some budget shared hosting doesn't give you access to my.cnf or a MySQL session with permission to run SET GLOBAL. In that case, fix it at the export side instead: re-export the database with single-row INSERT statements, which keeps every packet small regardless of the server's configured limit. With WP-CLI:

wp db export --extended-insert=false

The resulting file imports slower, since MySQL processes one row per statement instead of batching many rows together, but it sidesteps the packet-size ceiling entirely without needing any server-side access.

Verify the fix

Re-run the import and confirm it completes without the 1153 error reappearing. Don't just trust a clean-looking console output — spot-check the result directly: log into wp-admin, check that recent posts and a few option values (site title, permalink structure) are actually present. An import that stalls partway through a large table can sometimes leave a database in a partially-restored state without throwing this specific error again on the retry.

If you need to roll back

If you imported into a new or staging database, there's nothing to roll back — just apply the fix and re-run the import against the same target. If you imported directly over a live production database and it only partially completed, don't try to patch the gap by hand. Restore again from the same backup file after applying the fix above; the original .sql file is unchanged by a failed import attempt.

Related fixes

FAQ

Is "packet bigger than max_allowed_packet" the same as phpMyAdmin's file upload limit?

No. phpMyAdmin's upload limit (upload_max_filesize/post_max_size in PHP) rejects a file before it reaches MySQL at all. The max_allowed_packet error happens inside MySQL itself, after the import has already started, when one SQL statement in the file is larger than the configured limit. They need different fixes.

Does WP-CLI avoid this error?

Not by itself. wp db import still runs the system MySQL client, which enforces its own max_allowed_packet limit (16MB by default). WP-CLI skips phpMyAdmin's separate browser upload restriction, which helps with large files generally, but you still need to raise max_allowed_packet using the steps above.

Do I need to restart MySQL after running SET GLOBAL max_allowed_packet?

No — SET GLOBAL takes effect immediately for new connections. But the value resets to whatever's in my.cnf the next time MySQL restarts. If you're only doing a one-time restore, the temporary SET GLOBAL command is enough. If you expect to import large backups again later, add the setting to my.cnf as well so it survives a restart.