A plugin update is about to land. Core is waiting. A bulk product edit is queued. The risk lives mostly in the database: options, posts, WooCommerce tables, membership meta. A full-site ZIP that also copies every upload can be the right weekly ritual and still feel too heavy for the sixty seconds before you click Update. A database-only snapshot is the smaller, faster safety net for that moment.
Snapshotify includes a database-only snapshot that is faster and smaller than a full backup, available on demand or on its own schedule, with one-click restore like other snapshots, as portable SQL. Batched processing helps large databases finish. Full-site ZIP plus SQL still exists for complete recoveries. This post stays on database-only.
Snapshotify is the DaftPlug backup, restore, and migrate plugin. This post is only about a WordPress database-only backup before risky updates. Not a cloud Drive/Dropbox/OneDrive deep dive, not a retention policy deep dive, not chunked upload of external ZIPs, not migration URL rewrite as the main topic, not a smart file exclusions essay. Those live elsewhere. For the complete files-plus-database archive when you need the whole site, keep WordPress one-click full site backup nearby.
What Snapshotify actually ships here
Stay inside the real feature set:
- A database-only snapshot that is faster and smaller than a full backup
- Run on demand or on its own schedule
- One-click restore like other snapshots
- Portable SQL you can reason about without a proprietary lock-in story
- Batched processing for large databases as supporting context so the job can finish on strict hosts
- Full-site ZIP + SQL exists in Snapshotify, but this post is about the database-only path
This post does not invent undocumented per-table include pickers Snapshotify does not publish on the marketing pages, hot-standby replication claims, or promises that a database-only restore will bring back deleted media files from uploads. The product promise is a database-only snapshot, on demand or scheduled, one-click restore, portable SQL, with batched processing for large databases, beside the full-site path. Stay there. Cloud destination essays, retention deep dives, chunked external ZIP uploads, migration URL rewrite as the main topic, and smart file exclusions deep dives are parallel tools, not this article’s job.
Why a database-only backup matters on WordPress
Many failures are database-shaped. A bad update can corrupt options, break a membership table, or leave WooCommerce orders in a half-migrated state. Uploads often did not change in that minute. Capturing SQL quickly matches the risk.
Speed changes whether people actually back up. If the only button takes as long as a full media copy, teams skip the pre-update snapshot “just this once.” A smaller database-only run removes that excuse in the minute before Update Now.
Schedules can match database risk. Content and commerce churn in the database daily even when theme files are quiet. A database-only schedule can run more often than a heavy full-site job without copying the entire uploads tree every time.
Portable SQL keeps you honest. Snapshotify’s database snapshot story is portable SQL, not a mystery blob that only one vendor can open. That matters for agencies that may need to inspect or restore outside a panic click.
One-click restore must stay as simple as full snapshots. A fast backup that requires a ritualistic phpMyAdmin dance fails the product test. Snapshotify restores database-only snapshots in one click like other snapshots.
Full-site backups are still required. Database-only will not resurrect a deleted theme file or a wiped uploads directory. Keep full-site ZIP plus SQL for broader disasters (related post). Use database-only for the fast gate before database-heavy risk.
How to take a database-only backup in wp-admin
Assume Snapshotify is installed. Prefer a quick on-demand database snapshot immediately before a risky update, then consider a schedule once the habit sticks.
1. Decide whether this risk is database-only or full-site
Plugin and core updates that touch options and schema are strong database-only candidates. Theme file rewrites, malware cleanups, and “we deleted half of uploads” moments need a full-site snapshot instead. Write the rule: “Before plugin/core updates, database-only. Before theme swaps or bulk media deletes, full-site.” Do not pretend one mode covers every failure.
2. Open Snapshotify and create an on-demand database-only snapshot
In wp-admin, open Snapshotify. Choose the database / database-only backup path Snapshotify exposes (as distinct from a full-site snapshot). Run it on demand. Keep the first pass boring: one successful database snapshot, leave cloud destination configuration essays, retention policy redesigns, external ZIP uploads, and migration URL rewrite projects alone until restore is verified on staging or a safe window.
3. Wait for batched processing to finish on large sites
Large databases process in batches so shared hosts can finish. Watch progress until the snapshot is complete. Do not start the plugin update while the SQL dump is still running. If a host stalls, batched design is there so the job can continue rather than dying at a PHP timeout. Do not invent undocumented “pause buttons” that are not on the marketing pages. Let the run complete.
4. Confirm the snapshot appears as a restorable database backup
In Snapshotify’s snapshot list, confirm the new database-only entry exists and is identified as a database backup (not a full ZIP+SQL archive). Note the timestamp in your update runbook: “DB snapshot [time] taken before updating [plugin/core].”
5. Optionally set a database-only schedule
If commerce or editorial churn is daily, give database-only its own schedule so you are not relying only on pre-update discipline. Keep full-site on a separate cadence that matches media risk. Do not set both to “as often as possible” on day one without checking storage. Retention details are out of scope here; just avoid surprise disk fill.
6. Smoke-test restore on staging (or a controlled window)
- Copy or restore into a staging site when you can.
- Use Snapshotify’s one-click restore on the database-only snapshot.
- Confirm posts, options, and critical plugin tables look like the moment you captured.
- Confirm media files that were never in the database-only snapshot did not magically reappear if you had deleted them on purpose in a separate test. That expectation check prevents false confidence.
- On production, after a successful on-demand snapshot, proceed with the plugin or core update.
- If the update fails, restore the database-only snapshot with the same one-click path, then diagnose on staging.
If you have never restored any Snapshotify snapshot, do not learn during an outage. Practice once on staging.
7. Document the enablement for the next teammate
Write one line in your runbook: “Snapshotify database-only on demand before plugin/core updates. Optional DB schedule [cadence]. Full-site still required for file-level risk. Re-test restore after host PHP changes.” Backups get blamed when nobody knows which snapshot type to pick under pressure.
Who this is for / when to skip
Store and membership sites with heavy database churn and frequent plugin updates.
Agencies that need a fast pre-flight backup clients will actually wait for.
Publishers updating SEO, cache, or form plugins where options tables are the blast radius.
Anyone who skipped backups because full-site runs felt too long for a small update window.
Skip database-only as your only strategy if you are about to replace themes, purge uploads, or clean malware from files. Take a full-site backup first. Also skip if you have never verified any restore path. A backup you cannot restore is a story, not a safety net.
What good looks like
- An on-demand database-only snapshot completes before a plugin or core update.
- The archive is smaller and faster than a full-site ZIP+SQL run for the same moment.
- One-click restore returns the database to the captured state.
- SQL is portable rather than a mystery proprietary-only blob.
- Large databases can finish via batched processing on strict hosts.
- A separate schedule can cover database-only cadence when you want it.
- Full-site backups still exist for file-level disasters.
- Cloud deep dives, retention essays, chunked external ZIP uploads, migration URL rewrite as the main topic, and smart file exclusions deep dives were not required for this win.
- You did not claim database-only restores deleted media files.
If the snapshot never finishes, check host resource limits, let batched processing run, and avoid starting updates mid-dump. If restore is unfamiliar, practice on staging before production night.
Common mistakes
Using database-only when files changed. Theme swaps, plugin file edits, and uploads deletions need full-site coverage.
Starting the update while the dump is still running. Wait for completion. A partial safety net is not a safety net.
Never testing one-click restore. The button must be boring under stress. Rehearse on staging.
Believing database-only replaces full-site forever. It replaces the slow pre-update ritual for database risk. It does not replace complete disaster recovery.
Scheduling only full-site and skipping pre-update DB snapshots. Schedules help, but an on-demand database snapshot immediately before Update Now is still the sharpest habit.
Turning on cloud, retention, and migration rewrite the same afternoon. Verify database-only create and restore first. Add destinations and policies as separate projects.
Confusing portable SQL with “open in Excel.” Portable means standard SQL you can use in WordPress restore flows, not a spreadsheet export of every table for casual browsing.
Practical checklist before you call it done
- Decide the risk is database-shaped (plugin/core/options), not file-shaped.
- In Snapshotify, run an on-demand database-only snapshot.
- Wait until batched processing finishes on large databases.
- Confirm the snapshot is listed and restorable.
- Optionally add a database-only schedule separate from full-site cadence.
- Practice one-click restore on staging at least once.
- Proceed with the update only after the snapshot is complete.
- Keep full-site ZIP+SQL in the toolkit for file-level risk (related post).
- Leave cloud destination deep dives, retention policy redesigns, chunked external ZIP uploads, migration URL rewrite as the main topic, and smart file exclusions essays for separate passes.
- Write the pre-update DB snapshot habit into the team runbook.
FAQ
How is database-only different from a full-site backup?
Full-site captures files and database together (ZIP plus SQL). Database-only captures the database as a faster, smaller snapshot for database-shaped risk. Use full-site when files matter. See the one-click full site backup post for the complete archive.
Can I schedule database-only backups?
Yes. Snapshotify supports database-only on demand or on its own schedule. Keep full-site on a cadence that matches file risk.
Will restore bring back deleted images?
Not if those images lived only in the uploads directory and were never part of the database-only snapshot. Database restore returns database state. File recovery needs a full-site (or file-containing) backup.
Does a large database time out?
Snapshotify uses batched processing so large database work can finish on strict hosts. Let the job complete and watch progress rather than re-clicking Update mid-run.
Is the SQL locked to Snapshotify forever?
Snapshotify emphasizes portable SQL and standard archives in its backup story. Still, prefer restoring with Snapshotify’s one-click path for the least drama, and keep the portable format as your escape hatch.
Takeaway
Risky WordPress updates often threaten the database first. A full-site archive remains essential for complete recovery, but a fast database-only snapshot is the backup people will actually take in the minute before Update Now. Snapshotify’s database-only path is smaller and faster than full, runs on demand or on its own schedule, restores in one click, stores portable SQL, and uses batched processing so large databases can finish.
Snapshotify handles database-only snapshots alongside full-site ZIP plus SQL, without asking you to export tables by hand in phpMyAdmin before every plugin update. Take one on-demand database snapshot before the next risky update. Verify restore on staging when you can. Keep sibling backup features as separate enablement work.
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 database should be snapshotted before the update, not after the support ticket.
Snapshot the database. Then click Update. When a bad change lands, one-click restore beats rebuilding options from memory.