You have a 2GB backup ZIP from the old host. The new WordPress dashboard is ready. You hit Upload, watch the progress bar crawl, and PHP dies at 512MB or thirty seconds. The host says “raise upload_max_filesize.” Shared hosting says “no.” FTP feels like time travel. That is the moment migrations stall on a limit that has nothing to do with whether the archive is valid.
Snapshotify’s Chunked Upload splits large backup archives into chunks so PHP upload limits and timeouts stop mattering. You upload an existing backup ZIP from the dashboard, then restore it like any other snapshot. Host limits stop being the project plan.
Snapshotify is the DaftPlug backup, restore, and migrate plugin. This post is about chunked upload of large existing backup ZIPs, then restore from the dashboard. Not scheduled cloud retention as the main story, not one-click restore theory alone, not URL rewrite migration deep-dive as the only angle. Those live elsewhere. For the broader “upload an existing ZIP and restore” workflow, keep upload an existing WordPress backup ZIP and restore from the dashboard nearby.
What Snapshotify actually ships here
Stay inside the real feature set:
- Chunked Upload: upload large backup archives in chunks with no PHP upload limits or timeouts to worry about (product wording)
- Upload existing backups: upload a backup ZIP you already have and restore it directly from the dashboard
- Product messaging that uploads happen in chunks, so host limits stop mattering
- Uploaded backups restore exactly like a snapshot taken here
- Extractor with progress tracking and error reporting for ZIP extraction
- SQL importer that batches large databases so memory and execution limits hold during restore
- Manual and uploaded backups are never pruned automatically by retention (retention targets automatic backups)
- Standard ZIP and SQL packaging readable without proprietary lock-in
This post does not invent infinite cloud relay uploading for free when Pro cloud is a separate feature, bit-torrent style peer upload, or a claim that every third-party backup format on earth is supported without checking. Snapshotify’s verified path is chunked upload of backup ZIPs you already have, then dashboard restore. Stay there.
Why chunked upload beats “just raise PHP limits”
Shared hosts cap uploads for everyone. upload_max_filesize and post_max_size are often far below a full site ZIP. You do not control php.ini on many plans.
Timeouts kill honest progress. Even when size limits are high, max_execution_time aborts a single long request. Chunking turns one fragile request into many short ones.
Migrations are when archives are largest. Moving hosts is exactly when you carry media libraries and years of uploads. The ZIP is big because the site is real.
FTP is not a restore workflow. Dropping a file in a folder does not extract, import SQL in batches, or rewrite URLs. Snapshotify’s dashboard path is upload, then restore with the same engine you trust for local snapshots.
Failed big uploads waste afternoons. Chunked uploads that reconnect / retry (as Snapshotify’s broader reliability story describes for uploads) beat starting a 2GB POST from zero after a blip.
How to chunk-upload a large ZIP and restore
Assume Snapshotify is installed on the destination site (the site that will receive the archive).
1. Confirm you have a real backup ZIP
Chunked upload moves bytes. It does not invent a backup:
- Prefer a Snapshotify-format full snapshot when you have one (SQL dump + files in a standard ZIP).
- If the ZIP came from another tool, confirm Snapshotify’s upload/restore docs and UI accept that package before you spend an hour uploading.
- Keep a checksum or at least a file size note so you know the transfer finished complete.
Do not upload random theme zips and expect a site restore.
2. Open Snapshotify upload and start the chunked transfer
In wp-admin, open Snapshotify and choose the upload existing backup flow. Select the large ZIP from your computer. Snapshotify’s Chunked Upload sends the archive in pieces so PHP’s single-request limits are not the ceiling. Leave the tab alone while chunks complete. On flaky networks, prefer a stable connection over cafe Wi-Fi.
When finished, the archive should appear alongside other snapshots / uploaded backups in the dashboard list.
3. Verify the upload before you restore
Before restore:
- Confirm the listed size matches what you expect.
- Confirm the backup is marked as an uploaded / available archive (not a failed partial).
- Remember: uploaded backups are not auto-deleted by retention policies that prune automatic backups. Still treat disk space as finite on small hosts.
4. Restore from the dashboard like any snapshot
Run Snapshotify’s restore on the uploaded archive. The verified restore path covers extraction, import, and the usual Snapshotify restore behavior:
- Extractor unpacks with progress and error reporting.
- SQL importer runs in batches so large databases do not blow memory limits.
- If you are landing on a new domain or host, Snapshotify’s migrate / URL rewrite behavior (covered in related posts) rewrites URLs and paths, including serialized data, when that is part of your restore scenario.
Smoke-test wp-admin, homepage, and a media-heavy URL after restore.
5. Keep scheduling and cloud as separate decisions
Pro scheduled backups and Google Drive / Dropbox / OneDrive copies are powerful. They are not required to chunk-upload a ZIP you already have. Finish the upload + restore job first. Then decide whether the destination site should schedule offsite snapshots going forward.
6. Pair with the “existing ZIP” mental model
Chunking is the transport. The product story is still: upload an existing backup ZIP and restore from the dashboard. If you only need the conceptual overview without the large-file angle, the related upload post covers that path. This post is the large-file / PHP-limit failure mode.
What good looks like
- A multi-hundred-MB or multi-GB ZIP finishes uploading without raising php.ini.
- The dashboard lists the uploaded archive at the expected size.
- Restore extracts and imports without a PHP timeout white screen.
- Large SQL imports complete via batches.
- Uploaded backups remain available (not silently pruned as if they were old scheduled copies).
- You did not need FTP + manual phpMyAdmin as plan A.
- Host “upload limit” tickets were never opened.
If upload stalls at 99%, check disk space on the host and browser extensions that interrupt long sessions. Chunking removes PHP caps; it cannot create free disk.
Pitfalls (the ones that bite)
Uploading to the wrong site. Chunk to the destination that will run the restore. Confirm the wp-admin URL.
Disk full mid-extract. Upload success plus tiny remaining disk still fails restore. Check free space first.
Wrong archive type. A plugin zip is not a site snapshot. Use full backup ZIPs Snapshotify can restore.
Closing the browser aggressively mid-upload. Let chunks finish. Retry cleanly if the UI reports failure rather than assuming success.
Expecting retention to ignore disk forever. Uploaded backups are preserved from automatic pruning, but disks still fill. Remove obsolete archives intentionally.
Skipping post-restore login and permalink checks. Always open wp-admin and a pretty permalink before calling migration done.
Mixing cloud download and local chunk upload in one confused step. If the archive is already in Pro cloud, use restore/download-from-cloud flows. Chunk upload is for a ZIP on your machine (or similar local source) entering the dashboard.
Changing DNS before the restore finishes. Finish upload + restore + smoke tests, then flip traffic when that is the plan.
Practical checklist before you call it done
- Measure the ZIP size and confirm destination disk free space is comfortably larger.
- Install Snapshotify on the destination site.
- Start Upload existing backup and let Chunked Upload finish.
- Confirm the listed archive size matches the source.
- Run dashboard restore (extract + batched SQL import).
- Smoke-test wp-admin, homepage, login, and media.
- If domain/host changed, confirm URLs rewrote as expected.
- Remove obsolete archives only after you are sure you have a good restore point.
- Optionally enable scheduled / cloud backups for the future (Pro), separate from this upload.
- Document where the source ZIP lives offline so you are not dependent on one laptop folder.
Takeaway
PHP upload limits and timeouts are not a strategy. They are a wall that appears the moment your backup ZIP becomes real. Snapshotify Chunked Upload sends large archives in pieces so host caps stop mattering, then lets you restore that ZIP from the dashboard like any other snapshot, with batched SQL import for large databases.
Snapshotify keeps the package as standard ZIP and SQL, preserves uploaded backups from automatic retention pruning, and treats the upload path as a first-class restore source. Stop opening php.ini tickets for a one-time migration. Upload in chunks. Restore once. Verify.
One Pro membership unlocks Snapshotify plus Progressify, Lightify, Generatify, and Rankify. 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 the backup is ready but the host upload ceiling is not.
Start the chunked upload. When the multi-GB ZIP lands and restore finishes without a PHP funeral, the limit stopped owning the migration.