Why does my WordPress backup stop at the same percentage every time?

It is usually hitting a server limit at the same point: PHP's max_execution_time, the memory limit, or a single very large file or database row. A backup that works in small resumable steps avoids all three.

Is there a maximum backup size for WordPress?

Not in WordPress itself. The practical limits are your server's free disk space, PHP limits and your host's file size limits. ZIP64 removes the old 4 GB ZIP limit.

Does a large site need a different backup plugin?

It needs one designed for large sites: resumable steps, a streaming archive for big backups, and a database export that does not depend on mysqldump.

Why WordPress Backups Fail on Large Sites (and How to Fix It)

A backup that works perfectly on a 300 MB site can fail every time on a 20 GB one. The plugin is not broken. It is running into limits that small sites never reach.

The four usual causes

1. PHP time limits

Every PHP request has a max_execution_time, often 30 to 120 seconds on shared hosting. Zipping gigabytes of uploads in a single request does not fit, so the request is killed and the backup stops.

2. Memory limits

Building an archive or a database export in memory needs memory proportional to its size. Large sites run out.

3. No mysqldump

Many hosts do not allow running command-line tools from PHP. A backup that relies on mysqldump either fails or silently skips the database.

4. One oversized row

A single huge value, such as a serialized page builder layout or a log stored in the database, can exceed MySQL's max_allowed_packet when the export is imported again. The backup "works", but the restore fails.

What works instead: small, resumable steps

The fix is to stop treating a backup as one long operation:

Split the job into steps (scan, database, archive, verify), and each step into small slices that finish well inside the time limit.
Save the position after every slice, so the next request continues where the last one stopped. A server restart or a closed browser tab no longer means starting over.
Lock the job so two requests never write to the same backup at once.

This is how BackupScope runs every backup, small or large. The Large Site Guide explains the details.

Archives over 4 GB: ZIP64 and streaming

The classic ZIP format cannot describe files or archives larger than 4 GB. ZIP64 removes that limit and is supported by all current unzip tools.

Building a huge archive in one pass is also where many backups run out of time. A streaming writer adds files in batches across many requests instead. BackupScope estimates the size during the scan: up to 5 GB it builds a standard ZIP, above that it streams a ZIP64 archive in batches, and if the standard path fails it falls back to streaming automatically. The 5 GB value only chooses the engine; it is not a size limit.

Database exports that survive large tables

A robust export:

reads each table page by page instead of all at once,
writes very large values in chunks, so the import works with a default max_allowed_packet,
exports binary and BIT columns in a form MySQL reads back exactly,
runs through WordPress's own database connection, so no mysqldump is needed.

More on that in WordPress database backups without mysqldump.

Practical tips for large sites

Check free disk space first. The server needs room for the archive, roughly the estimated backup size.
Leave out what is not needed. Caches and other plugins' backup folders should never be in a backup. Untick large folders you already keep elsewhere.
Verify the result. Large archives are exactly where truncation goes unnoticed.
Upload in parts. For off-site copies, multipart uploads mean an interrupted upload does not start from zero.

A large site is not a reason to give up on reliable backups. It just needs a backup that was built for it.