People search this after a WordPress backup dies on a cheap host, or after PHP logs a memory exhausted / Allowed memory size error during a database dump. Those are two different problems, and they are not the same failure in 1-Click Migration today.
Memory limit vs a large WordPress database
A large database used to crash PHP when the dump was built in memory. That is already handled.
In 1-Click Migration 3.1.10 and later, the SQL dump streams to disk in chunks. Before the dump starts, the plugin compares database size to PHP memory_limit. If an in-memory dump would run out of memory, it takes the streamed path instead of dying. Low-memory warnings go to the plugin log. They are a leading indicator, not a silent failure.
You do not need to raise memory_limit just to get a database backup to finish. A memory warning in the log means the streamed path is already in use.
How to tell which parts of a backup completed
A backup is not all-or-nothing. 1-Click Migration can finish the database, themes, and plugins even when uploads do not make it into the archive.
Look at three places:
- The plugin UI. A backup that skipped a part finishes as completed with missing parts, with a warning banner. It does not report a clean backup.
- The restore-code email. That email lists what is in the backup and what was skipped.
- The Restore tab on the destination. Restore reads the backup’s part list first and warns which parts the code does not contain.
The four parts are database, plugins, themes, and uploads.
Auto-recovery when a backup stalls
Long backups can look frozen when a host kills a background worker or blocks admin-ajax loopback.
The plugin writes a heartbeat while it works. If the worker stalls, the progress poller resumes it. If the host blocks loopback, backup switches to direct processing instead of waiting on a worker that never starts. Stop & Reset is still there if you need to start over.
That recovery is for stalls and timeouts. It is not a claim that every site archives in one pass.
The failure that still hits huge sites: archive timeout on uploads
The live large-site failure is not the database memory crash. It is building and closing a huge uploads archive.
Sites with around 44GB of uploads, or around a million files under wp-content/uploads, can sit on the zip-close step until the host times out. After retries, the plugin skips uploads and keeps the parts that did finish. That is intentional honesty, not a silent success.
This is a different symptom from a memory_limit fatal. The database can stream fine while uploads are skipped. A plugin update does not make a million-file zip close faster on a host with a hard time limit.
What the restore code contains after a partial backup
If uploads were skipped, the restore code still works. It restores the parts that were backed up, usually the database, themes, and plugins. It does not include the media library.
After restore you get a working WordPress site without the skipped files. Media that lived in wp-content/uploads is not in that code. Copy those files separately (SFTP, rsync, or your host’s file manager) onto the destination, or run a second backup with only uploads if the library is small enough to archive.
Do not restore expecting photos, PDFs, and other uploads to appear from a code that listed uploads as skipped.
Finishing a move on a tight host
Use selective backup when the host is tight on disk, time, or process limits:
- Backup database, themes, and plugins first. Restore that code on the new host.
- Copy uploads yourself, or run an uploads-only backup if the media library is not huge.
- Exclude cache, old backup zips, and unused themes or plugins before you start. Those files add time and size without moving the site.
There is no 4GB zip-download cap. Selective backup is still the right move when a host cannot finish a giant uploads folder in one pass.
Need help? Use the contact form and include the email you used with the plugin so we can find your logs.
Related: Step By Step Backup & Restore