The plugin update looked fine on the changelog. Ninety seconds later the site white-screened. WooCommerce checkout threw a fatal. Your host’s “restore” button wants a support ticket and a four-hour window. The backup you thought you had is a folder of files with no database, or a database dump with no wp-content.
That is the moment a backup product proves whether it is a real snapshot or a marketing checkbox. You need files and database together, restored as one operation, without hiring someone to run mysql by hand at midnight.
Snapshotify is the DaftPlug backup plugin. This post is about one-click restore of a full snapshot: files plus database in one archive (standard ZIP and SQL), restore that handles extraction, import, and URLs, batched/chunked so large sites finish with progress visible, safe serialization when URLs differ, and retention that only prunes automatic scheduled backups (manual stays). Not email notifications as the hero, not exclude rules as the hero, not upload-existing-ZIP as the hero, not multi-cloud destinations as the hero, not database-only as the hero (those can get a brief mention). For why on-server copies are not enough, keep A WordPress backup on the same server is not a backup nearby.
What Snapshotify actually ships here
Stay inside the real feature set:
- Full snapshot with files and database in one archive; standard ZIP and SQL, readable without Snapshotify
- One-click restore that handles extraction, import, and URLs for you
- Batched/chunked processing so large sites finish; progress visible the whole way
- Safe serialization for URL rewrites when the domain differs (migration-adjacent)
- Retention only prunes automatic scheduled backups; manual backups stay until you delete them
Brief adjacent mentions OK: database-only snapshots before a risky update, cloud destinations, uploading an existing ZIP. They are not the focus. This post is about getting the whole site back in one click after something breaks.
Why one-click full restore beats “we have backups somewhere”
Agencies collect backup plugins that create archives and then fail the restore drill. Creation is the easy half.
Files + database together. Themes, plugins, uploads, and the MySQL state have to match. Restoring only wp-content onto a newer database schema is how you get ghost errors for days.
Standard ZIP and SQL. Snapshotify packages in formats you can open without the plugin. That matters if you ever need a host tech to peek, or you are recovering onto a fresh WordPress install.
One click that actually finishes. Extraction, database import, and URL handling in one flow beats a checklist of WP-CLI commands written on a sticky note. When the site is down, cognitive load is already maxed.
Chunked work on shared hosting. Large sites time out when a plugin tries to do everything in one PHP request. Snapshotify batches files and SQL so the job completes and shows progress instead of dying at 37%.
URL safety when the domain differs. Restoring to a staging host or a new domain needs serialized-safe search/replace. Blind string replace corrupts PHP serialized options. Snapshotify’s migration-adjacent rewrite path exists so the site boots instead of white-screening on home/siteurl mismatches.
Retention that does not eat your lifeboat. Automatic schedules can prune old automatic runs. Manual snapshots you took five minutes before an update stay. That distinction is the difference between “the policy deleted my pre-deploy copy” and “I can still roll back.”
How to restore in one click in wp-admin
Assume Snapshotify is installed and you already have at least one full snapshot. If the dashboard is down hard, use a host PHP recovery mode or restore from an offsite copy first, then finish in wp-admin when it loads.
1. Take a manual full snapshot before risky work (habit)
Before plugin/theme/core updates, run a full snapshot on demand. Do not rely only on last night’s schedule. Manual copies are retained until you delete them; retention prunes automatic runs, not these lifeboats.
Confirm the archive includes files and database. Database-only is fine as an extra quick checkpoint, not as your only rollback for a plugin that dropped PHP files.
2. When things break, open Snapshotify and pick the clean snapshot
In wp-admin (or recovery access), open Snapshotify’s backup list. Choose the full snapshot from before the bad update. Prefer the manual pre-update copy over an automatic run that might have captured the broken state if the schedule fired mid-incident.
3. Run one-click restore
Start Restore. Snapshotify handles extraction, import, and URLs. Watch the progress UI. On large sites you should see chunked work continue rather than a silent hang. Leave the tab open until it reports completion.
Do not start a second restore in parallel. Do not deploy new plugin zips while the import is mid-flight.
4. If the domain or host differs, trust the serialized URL rewrite
Restoring onto staging or a new domain is where blind tools fail. Snapshotify rewrites URLs/paths across the database with safe serialization, so option blobs and nested data do not corrupt. After restore:
- Load the front end and wp-admin once.
- Confirm
Settings → GeneralURLs match the environment you intended. - Spot-check permalinks, menus, and a WooCommerce page if you sell.
If you restored onto the same live domain after a bad update, URL rewrite is mostly a no-op, and that is fine. The important part is files and DB returning together.
5. Smoke-test the site before you call it recovered
Check:
- Front page loads without fatals.
- wp-admin login works.
- A primary template (shop, booking, membership) works.
- A recent post and a media file from uploads appear.
- Caching plugins / CDN purged so you are not staring at a cached fatal page.
Then redo the update carefully: staging first, or one plugin at a time, with a fresh manual snapshot between steps.
6. Keep offsite and retention in mind (supporting, not the hero)
Ideal setups also push scheduled copies to Drive/Dropbox/OneDrive so a dead server does not take the only archive with it. Retention should prune old automatic runs per destination without deleting the manual snapshot you just used. Configure that on a calm day, not during the outage. Same-server-only copies remain a single point of failure; the related post covers why.
What good looks like
- A full ZIP+SQL snapshot exists from before the change.
- One-click restore completes with visible progress, even on a large shared host.
- Front end and admin return to the pre-update state.
- Manual pre-update snapshots remain after retention runs.
- Restores to staging do not corrupt serialized data when the domain differs.
- You can open the archive format without Snapshotify if a host tech needs the SQL.
If restore “succeeds” but the site still fatals, you may have restored a snapshot that already included the bad update. Pick an older full copy and run again.
Pitfalls (the ones that bite)
No pre-update manual snapshot. Schedules lag reality.
Restoring a snapshot taken after the failure. Always check timestamps.
Closing the browser mid-import. Let chunked progress finish.
Only backing up the database. File-level plugin corruption needs files too.
Blind search-replace on staging. Use Snapshotify’s safe rewrite path instead of a risky SQL replace.
Assuming retention keeps everything forever. It prunes automatic runs; verify manual stays.
Never doing a restore drill. The first restore should not be production at 1 a.m.
Same-disk-only archives. When the server dies, so does the backup. Offsite is the next hardening step.
Practical checklist before you call it done
- Create a manual full snapshot before updates; confirm ZIP+SQL.
- Note the timestamp so you can pick it under pressure.
- On failure, restore that full snapshot with one click.
- Watch progress until extraction and DB import finish.
- If domain differs, confirm serialized-safe URLs and Settings → General.
- Smoke-test front end, admin, checkout/primary flows, and uploads.
- Purge caches/CDN.
- Confirm retention did not delete the manual lifeboat.
- Rehearse restore on staging once a quarter.
- Add offsite destinations on a calm day so the next incident is not same-server-only.
Takeaway
A bad WordPress update is inevitable. A four-hour host ticket is optional. What you need is a full snapshot (files plus database) you can put back in one click, even when the site is large and the host is strict.
Snapshotify builds that archive as standard ZIP and SQL, restores with extraction, import, and URL handling in one flow, batches the work so shared hosting finishes with progress visible, rewrites serialized data safely when the domain differs, and keeps manual snapshots out of automatic retention pruning. Take the manual copy before you click Update. Restore it when the update lies.
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 rollback should be a button, not a weekend.
Snapshot before the update. Restore once. When the site looks like five minutes ago instead of a fatal error, the backup finally earned its keep.