Upload an Existing WordPress Backup ZIP and Restore It From the Dashboard

You already have a backup. It sits on a laptop, a Dropbox folder, or an old host download page. The plugin that made it is gone, expired, or locked behind a dashboard you no longer control. What you need is a way to get that archive into WordPress and put the site back.

That is a different job from scheduling nightly Drive copies, and a different job from migrating to a new domain. It is the “I have a ZIP, make it live” path.

Snapshotify supports uploading an existing backup ZIP from the dashboard, with chunked uploads so host PHP size limits stop mattering, and the same one-click restore path used for snapshots it created. Uploaded backups are never pruned automatically. Retention only cleans automatic scheduled runs. Native Snapshotify archives are standard ZIP and SQL, readable without the plugin.

If storage fill-up is the other half of your backup headache, read Set WordPress backup retention per cloud destination before storage fills up. Retention and upload are complementary: one keeps scheduled history sane, the other protects manual archives you brought in on purpose.

What Snapshotify actually ships for upload and restore

Stay inside the real feature set:

• Upload an existing backup ZIP from the dashboard
• Chunked uploads so PHP upload_max_filesize limits stop blocking large archives
• Uploaded backups never pruned automatically
• Restore uses the same one-click path as native snapshots
• Native archives are standard ZIP / SQL, readable without the plugin
• Supporting context: full snapshot files+DB, migration with serialized-safe URL rewrite, scheduled daily/weekly/monthly, Google Drive / Dropbox / OneDrive (multi destination), retention per destination, DB-only backup, batched/chunked for large sites, smart file exclusions, email notifications, download archives

This post centers bring-your-own ZIP. Migration URL rewrite and cloud restore-from-Drive are nearby tools when the archive is already in cloud storage or the domain is changing.

Why “I have a ZIP” still fails on many hosts

Common traps:

1. Host gave you a raw archive after a hack, but no one-click restore.
2. Old plugin exported a ZIP+SQL pair you can open on disk, but not reinject easily.
3. PHP upload_max_filesize rejects anything over 64MB or 128MB.
4. You are scared to run a blind search-replace on serialized data.
5. Retention on another tool deleted the manual copy you thought was safe.

Snapshotify’s answer is boring on purpose: upload the archive in chunks, then restore with extraction and import on the same path as native snapshots. Manual and uploaded backups stay until you delete them. Automatic scheduled backups are what retention prunes.

How to upload and restore from the dashboard

1. Confirm what is inside the archive before you upload

Open the ZIP on your computer. You want a clear files layout plus a database dump you trust (SQL). Snapshotify’s own archives are standard ZIP/SQL for that reason. If an old vendor used a proprietary blob you cannot inspect, do not invent confidence. Prefer an archive you can list and spot-check.

Note the site URL the backup came from. If the domain or path will differ after restore, plan to use Snapshotify’s migration / serialized-safe URL rewrite rather than a risky manual search-replace.

2. Open Snapshotify’s upload flow in wp-admin

In wp-admin, open Snapshotify and find Upload / restore for existing backups. Start the upload of your ZIP.

Because uploads are chunked, large archives should continue past typical single-request PHP limits. Keep the tab open until the progress finishes. Do not assume a silent browser sleep on a phone hotspot is safe for a multi-GB site. Use a stable connection.

3. Verify the uploaded backup appears and is marked as manual

After upload, confirm the archive shows in Snapshotify’s backup list. Treat it as a manual / uploaded item. Retention should not auto-delete it. If you also run scheduled backups to Drive or Dropbox, keep retention policies aimed at automatic runs only (see the related retention post).

4. Restore with the same one-click path as native snapshots

Run restore on the uploaded archive the same way you would for a Snapshotify-made snapshot. Confirm you understand the destination: restoring overwrites the current site contents with what is in the archive. Take a fresh Snapshotify snapshot of the live site first if there is anything on production you might still need.

If the domain or host changed, use the migration-aware restore / URL rewrite path so serialized options and post content do not keep pointing at the old URL.

5. Smoke-test the restored site

After restore:

1. Load the homepage and a few key templates logged out.
2. Log into wp-admin with credentials from that backup era (or reset if needed).
3. Spot-check media, menus, and a WooCommerce product if applicable.
4. Confirm cron, permalinks, and caching plugins are not serving stale ghosts. Flush caches once.

6. Decide where the uploaded archive should live long term

Leaving one uploaded copy only on the origin disk is fragile. Download a copy, or send future scheduled backups to Google Drive, Dropbox, or OneDrive with retention per destination. The uploaded ZIP you just restored from should also exist offsite if it is your golden recovery point.

What good looks like

A clean bring-your-own ZIP recovery feels uneventful:

• The archive listed its files and SQL before you trusted it.
• Chunked upload finished without a PHP size error.
• The backup showed as uploaded / manual and stayed put after a scheduled run pruned older automatic copies.
• One-click restore completed on the same path as a native Snapshotify snapshot.
• Homepage, admin, media, and key templates matched the backup era.
• A copy of that golden ZIP also exists offsite, not only on the server you just rebuilt.

If anything in that list failed, stop and fix that step before you touch production DNS.

Pitfalls (the ones that bite)

Uploading a proprietary format you cannot open. Inspect first.

Restoring over production without a fresh safety snapshot. Always keep an exit ramp.

Assuming retention will “clean up” uploaded ZIPs. It will not. Delete manually when you truly mean it. That is a feature, not a bug.

Fighting PHP upload limits by raising them for one giant POST. Chunked upload is the point. Use it.

Skipping URL rewrite on a domain change. Broken links and serialized option corruption follow.

Calling a same-server copy “offsite.” It is not. Pair upload/restore with cloud destinations for the next incident.

Restoring a DB-only dump when you needed files too. Know whether the ZIP is full (files+DB) or database-only before you click.

Practical checklist before you call it done

1. Inspect the ZIP/SQL contents on disk.
2. Snapshot the current live site first (safety copy).
3. Upload the existing ZIP via Snapshotify’s chunked uploader.
4. Confirm it appears as an uploaded / manual backup (not auto-pruned).
5. Restore with the same one-click path as native snapshots.
6. Use serialized-safe URL rewrite if host/domain changed.
7. Smoke-test front end, admin, media, and commerce paths.
8. Store a copy offsite (Drive / Dropbox / OneDrive) and set retention for automatic runs only.
9. Delete the uploaded archive from the panel only when you intentionally retire it.

Takeaway

Having a ZIP is not the same as being able to put the site back. Chunked upload plus one-click restore closes that gap without fighting PHP file limits or trusting retention to leave your manual archive alone.

Snapshotify lets you upload an existing backup ZIP, keep it safe from automatic pruning, and restore it on the same path as native full snapshots (files+DB), with standard ZIP/SQL archives you can still open without the plugin. Use it when the old tool is gone and the archive is all you have.

One Pro membership unlocks Snapshotify plus Progressify, Lightify, Generatify, and Rankify. New Pro plugins join existing memberships. Plans differ by site count only. See pricing when you want bring-your-own ZIP recovery in the dashboard.

Upload one archive on a staging site first. Restore it. When the homepage matches what you expected, production is a calmer click.