You click Backup on a multi-gigabyte WordPress site. The progress spinner runs. PHP hits max execution time. The archive is half-written. Shared hosting killed the process mid-SQL dump. You try again at midnight hoping the server is quieter. Same stall. The site that most needs a reliable snapshot is the one least likely to finish on a naive one-shot backup.
Snapshotify is built for that reality: everything runs in batches, so snapshots and restores complete however large the database or however strict the host. SQL imports in batches. Progress stays visible. If the host stalls, the job resumes instead of forcing you to start from zero.
Snapshotify is the DaftPlug backup, restore, and migration plugin. This post is only about batched processing for large sites (backups and restores in batches, batched SQL import, resume when the host stalls, visible progress). Not chunked ZIP upload of an existing archive (covered separately), not cloud destination setup as the main topic, not retention policy as the main topic, not database-only backup as the main topic. Those live elsewhere. For adjacent large-file intake (upload large backup ZIPs in chunks past PHP limits), keep WordPress chunked upload for large backup ZIPs nearby.
What Snapshotify actually ships here
Stay inside the real feature set:
- Large sites support described as batched: files and SQL in chunks
- Gigabyte sites finish on shared hosting as stated on the product page
- SQL imported in batches, so memory limits hold
- Progress is visible the whole way through
- Resumes if the host stalls
- Feature grid includes Batched SQL Import for performance on imports
- Distinct from Chunked Upload (upload large files in smaller chunks when bringing an existing ZIP in)
This post does not invent custom batch-size APIs as marketing promises, claim infinite PHP limits disappear forever, or conflate batched engine work with the separate chunked upload path. Finishing large backups and restores on strict hosts is the promise here.
Why batching matters more than “buy a bigger host” slogans
Shared hosting kills long requests. Max execution time, memory ceilings, and aggressive process managers are normal. A backup tool that assumes a 10-minute uninterrupted PHP request will fail exactly when the site is large enough to hurt.
Databases grow sideways. WooCommerce orders, logged automations, and plugin tables create SQL dumps that cannot safely load as one giant import in memory. Batched SQL import exists so restores do not blow memory limits.
Visible progress changes operator behavior. When you can see the job move, you stop refreshing frantically and spawning duplicate backups. Progress is not cosmetic. It prevents human-caused pileups.
Resume is the difference between “almost” and “done.” Hosts stall. Networks hiccup. A system that resumes beats one that orphans partial archives and forces a cold restart.
Upload chunking solves a different problem. Chunked upload gets a large ZIP into the dashboard past PHP upload limits. Batched processing finishes creating and restoring snapshots on the server. You often need both on large sites. They are still different features.
How to run batched large-site backups in wp-admin
Assume Snapshotify is installed and the site has enough disk headroom for a full snapshot plus temporary working files.
1. Free space and exclude noise before the first large run
Large sites fail early when disk is nearly full or when caches and backup folders recurse into themselves.
- Check available disk vs. approximate site size.
- Use smart exclusions for caches, logs, and other regenerable paths where Snapshotify allows criteria-based exclusions.
- Confirm you are not backing up an old backups directory into a new backup forever.
Batching helps time and memory. It does not invent free disk.
2. Start a full snapshot and watch progress
In Snapshotify, run a full-site snapshot (files + database) from the dashboard. Leave the tab open enough to confirm progress is visible and advancing. On a large site, expect the job to work through files and SQL in batches rather than a single frozen spinner with no feedback.
Do not start three manual backups because the first one “looks stuck” at 40%. Check progress. If it is moving, let batching work.
3. Treat stalls as resume territory, not panic territory
If the host interrupts a long request, Snapshotify’s large-site design is to resume rather than demand a full restart from nothing. When something interrupts:
- Note the last visible progress state.
- Resume / continue the job from Snapshotify rather than immediately deleting partial work.
- Avoid parallel overlapping backups that race for disk and CPU.
- If stalls repeat at the same point, check disk, permissions, and whether a specific giant directory should be excluded.
4. Practice restore with batched SQL on staging first
Backups you never restore are fiction. On staging or a disposable copy:
- Restore a snapshot the way you would in an emergency.
- Confirm SQL import proceeds in batches without exhausting memory.
- Confirm the site boots, URLs look right, and critical WooCommerce or membership flows work.
- Only then trust the same engine on production overnight schedules.
Migration URL rewrite is related but separate. This pass is about finishing the heavy lift: files and SQL through batching.
5. Do not confuse this with chunked upload day
If you already have a backup ZIP from elsewhere and need to get it into WordPress past upload_max_filesize, that is Chunked Upload. Use that workflow when intake is the bottleneck. Use batched processing when creating or restoring snapshots on a large/slow host is the bottleneck. Many teams need both. Label them correctly in runbooks so juniors do not toggle the wrong mental model.
6. Schedule only after a manual large run succeeds
Scheduled backups are useless if the manual large run never finishes. Prove one full snapshot completes with visible progress. Then enable schedule + offsite destinations as their own pass. Retention pruning keeps storage honest later. First win: a complete archive.
What good looks like
- A gigabyte-class site completes a snapshot on shared or otherwise strict hosting.
- Restore/import can run with SQL applied in batches without memory collapse.
- Progress remains visible during long jobs.
- A stall resumes instead of forcing a hopeless full restart.
- Chunked upload was not required for this win (unless you were also importing an external ZIP).
- Exclusions prevent caches from bloating the archive.
- A teammate can follow progress without starting duplicate jobs.
If progress never moves past a specific directory of multi-GB media you do not need in every snapshot, exclude or split strategy before blaming batching.
Pitfalls (the ones that bite)
Spawning duplicate backups mid-job. Parallel runs fight for disk and confuse resume. One job.
Assuming batching replaces disk space. Partial archives still consume space. Monitor free disk.
Skipping restore drills. A finished backup that never restored on staging is unverified.
Conflating chunked upload with batched backup/restore. Upload path vs. processing engine. Different buttons, different docs.
Backing up everything including old backups and node_modules. Exclusions matter more as sites grow.
Changing hosts mid-failure without noting progress. Capture state. Resume when the product supports it. Then migrate calmly.
Turning on daily schedules before a single large manual success. Fix completion first. Automate second.
Ignoring PHP and host error logs. Batching reduces timeout risk. Permission errors and disk-full errors still need a human.
Operator notes for agencies and multi-site Pros
If you manage client sites on mixed hosts, batched processing is how you stop writing “backup failed, please upgrade hosting” as the default reply.
- Standardize a pre-backup checklist: disk headroom, exclusions, one running job only.
- Require a staging restore drill after the first successful large snapshot on each new client.
- Separate runbook lines for “create/restore with batches” vs. “upload existing ZIP with chunked upload” so juniors pick the right tool under pressure.
- For WooCommerce catalogs that grow every season, re-verify completion after peak catalog imports, not only after initial setup.
Snapshotify still benefits from sensible hosting, offsite copies, and retention. Batching simply means the engine can finish on the hosts many WordPress sites actually use, instead of only on unconstrained VPS sandboxes.
When a host stalls mid-job, resume visibility is what keeps midnight emergency restores calm. Train the team to read progress before they click Backup again.
Practical checklist before you call it done
- Check free disk vs. site size. Exclude caches and junk.
- Run one full Snapshotify snapshot on the large site.
- Confirm progress is visible and advancing through batches.
- If the host stalls, resume instead of stacking duplicate jobs.
- Restore on staging and confirm batched SQL import completes.
- Verify critical store or membership flows after restore.
- Keep chunked upload documented separately for external ZIP intake.
- Only then enable schedules and offsite destinations.
- Write a one-page runbook: where progress lives, how to resume, who gets notified.
- Re-test after major plugin or media library growth. Size changes the job.
Takeaway
Large WordPress sites do not fail backups because you forgot a checkbox. They fail because hosts refuse long, memory-heavy, one-shot processes. Snapshotify’s answer is batched processing: backups and restores that move in batches, SQL imported in batches, progress you can see, and resume when the host stalls.
Snapshotify ships that large-site engine alongside one-click backup/restore, migration, schedules, and cloud destinations, without asking you to SSH a custom dump script at 2am. Pair batching with exclusions and a real restore drill. Keep chunked upload as the separate answer for getting big ZIPs into the dashboard.
One Pro membership unlocks Progressify plus Lightify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when gigabyte sites on strict hosts should finish snapshots instead of dying mid-spinner.
Run one batched backup to completion. Restore once on staging. When large sites finish reliably, shared-hosting timeouts stop deciding your disaster-recovery story.