You know the drill. A plugin update notification pops up. You hover over Update. You remember you should take a backup first. Then you look at the clock, remember the last full-site backup took forever, and click Update anyway.
That habit is how WooCommerce shops lose orders, how membership sites lose settings, and how content sites lose hours of edits that never lived in a file. The part you cannot rebuild by hand is almost always the database. Themes and plugin folders can be reinstalled. Media can often be recovered. The database holds posts, pages, options, orders, form entries, and the messy serialized data that ties your site together.
A database-only WordPress backup is the practical answer for that moment. It is smaller. It is faster. And with Snapshotify, you can run one on demand or on its own schedule, then restore it with the same one-click flow you use for any other snapshot.
This post walks through when a DB-only backup is the right move before a plugin update, when you still need a full-site snapshot, how to create and name one properly, the pitfalls people hit, and how to practice restores so you are not learning under pressure.
Why people skip backups before plugin updates
Full-site backups are the gold standard. Snapshotify’s full-site snapshot packs the database and files into a ZIP plus SQL. That archive is standard ZIP and SQL, so you can open it without the plugin if you ever need to. Restore handles extraction, import, and URL rewriting for you.
The problem is time and size. On the Snapshotify product page, a real-world comparison looks like this: a full snapshot around 1.8GB took about 14 minutes, while the database-only run was about 62MB and finished in about 38 seconds. When you are updating three plugins on a Monday morning, fourteen minutes feels like a tax. Thirty-eight seconds feels like brushing your teeth.
So people skip. Or they rely on a host “daily backup” they have never tested. Or they keep the only copy on the same server, which is not a real safety net (more on that in our post A WordPress backup on the same server is not a backup).
Plugin updates mostly touch plugin files and sometimes write to the database (new tables, option keys, migrations). If the update goes wrong, you often need the previous database state more than you need yesterday’s media library. That is exactly where a database-only WordPress backup earns its keep.
What “database-only” actually means
A database-only snapshot is the SQL dump of your WordPress tables (and related tables for WooCommerce, membership plugins, form plugins, and so on). It does not include uploads, theme folders, or plugin folders.
In Snapshotify you create a backup with a clear name and independent exclude checkboxes for Core, Media, Plugins, Themes, and Database. For a DB-only run before an update, you exclude Core, Media, Plugins, and Themes, and leave Database included. There is also an “exclude nothing” preset for full runs. You cannot exclude all five categories at once, which is a sensible guardrail.
Every snapshot carries a manifest with WordPress version, site URL, and table prefix. That metadata matters when you restore later, especially if you are moving between staging and production or comparing two backups from different days.
When a database-only backup is the right call
Use a database-only WordPress backup when:
You are updating plugins or themes and your files are already recoverable. Plugin and theme files live in the repo of origin (WordPress.org, your vendor, Git). If an update breaks things, you can roll the plugin back from a known version, but you cannot “reinstall” last week’s orders or option rows. Snapshot the database first.
You are changing settings, permalinks, or running a migration script that writes to the DB. Many “safe looking” admin clicks rewrite options and rewrite rules. A 40-second DB snapshot before you touch those screens is cheap insurance.
You need a frequent schedule without drowning storage. Full-site archives grow with media. Database-only snapshots stay small, so daily or even more frequent DB runs are realistic. Snapshotify Pro can schedule daily, weekly, or monthly jobs, upload to cloud, and prune oldest automatic backups by retention. Manual backups and uploaded archives are never auto-pruned, so your named “Before WooCommerce 9 update” snapshot stays until you delete it.
You want a fast pre-update ritual the team will actually follow. Process beats perfection. A backup people take every time beats a perfect full-site backup they skip.
When you still need a full-site snapshot
Do not treat DB-only as a replacement for full backups. Take a full-site snapshot when:
You are about to change hosting, migrate domains, or rebuild the server. You need files and database together. Snapshotify’s migration flow rewrites URLs and paths, including serialized data, without hand-editing wp-config.php or running search-replace scripts yourself.
You are updating WordPress core, or doing a major redesign that touches themes, custom plugins, and uploads. File changes and database changes travel together.
You have never verified a restore. Start with a full snapshot onto staging once, so you trust the whole path: extraction, SQL import, URL rewrite, and the site actually loading.
Your media or custom code is not elsewhere. If your only copy of theme customizations or uploaded assets lives on that server, exclude nothing and take the full ZIP.
A healthy pattern for most sites: weekly or monthly full-site snapshots with cloud upload, plus a database-only schedule (daily is common) and an on-demand DB snapshot named for the reason right before risky plugin updates.
How to take a database-only backup with Snapshotify before an update
Here is a practical workflow you can repeat every time.
1. Name the backup for the reason
Call it something like “Before WooCommerce 9 update” or “Before Rank Math migration.” Future-you will thank present-you when three plugins fail in the same week and you need to know which snapshot matches which change. Snapshotify’s docs treat naming for the reason as good practice alongside backing up before risky changes.
2. Exclude everything except the database
On create, use the exclude checkboxes so Core, Media, Plugins, and Themes are out, Database stays in. That is your database-only WordPress backup. Keep the “exclude nothing” preset for full runs on a calmer day.
3. Run it on demand (or confirm the schedule already ran)
On-demand is perfect for the “I am about to click Update” moment. You can also give database-only snapshots their own schedule, separate from full-site jobs, so overnight DB copies keep stacking even when nobody is watching.
4. Get a copy off the server
A backup that only lives on the same disk as the site fails when the disk fails. Upload to cloud. Snapshotify Pro supports Google Drive, Dropbox, and OneDrive, including multiple destinations, with reconnects and retries when a transfer hiccups. Retention prunes the oldest automatic backups. Your manual “Before …” snapshot is not auto-pruned.
If you are still on Free, you get manual backup, restore, migrate, upload, and notifications. Scheduling, retention, and cloud destinations are Pro. One DaftPlug Pro membership unlocks Snapshotify Pro and the rest of the DaftPlug Pro plugins (Progressify, Lightify, Generatify, Rankify, and more as they ship) under the same license. Plans are Pro $37.99 (1 site), Pro Plus $74.99 (5 sites), and Pro Max $138.99 (100 sites) annual, with a 14-day money-back guarantee. Details live on pricing.
5. Then update the plugin
Now click Update. If something breaks, you are minutes away from a one-click restore of the database, not hours away from hunting host panel backups.
How restore works (and why practice matters)
Snapshotify restores handle extraction and SQL import for you, with batched work for large sites and shared hosting, batched SQL import, and visible progress. Jobs keep going even if you close the tab, because they continue on ticks in the background. That matters on shared hosts where a long import would otherwise time out in the browser.
A database-only snapshot restores like any other snapshot: one click, same flow. You are not hand-importing SQL in phpMyAdmin unless you choose to open the standard SQL yourself.
Good practice from the docs: restore onto staging once to verify. Do this before you need it. Pick a recent DB-only snapshot, restore it on a staging copy, spot-check orders, settings, and a few content pages. You will learn how long your site takes, whether serialized data and URLs look right, and whether your cloud download path works. That dry run is worth more than another untested backup sitting in a folder.
If you are restoring across hosts or URLs, remember Snapshotify’s migration path rewrites URLs and paths including serialized data. You should not be editing wp-config.php by hand or running search-replace scripts for a normal Snapshotify restore or migrate.
What Snapshotify deliberately leaves out of archives
Knowing exclusions helps you trust (and not over-trust) a snapshot. Snapshotify always excludes from archives:
wp-config.php.user.ini,php.ini,web.configwordfence-waf.php.maintenance- drop-ins such as
object-cache.php - caches
node_modules.git- other backup plugins’ directories
- logs and tmp
- Elementor generated CSS
One important reason: a .user.ini with absolute paths can break cross-host restores. Excluding host-specific and ephemeral files keeps the archive portable. Your credentials and environment stay on the server where they belong. Caches and generated CSS rebuild. That is intentional.
For database-only backups, most of those file exclusions are moot because files are not in the archive anyway. Still, understanding the full-site rules helps when you mix DB-only and full schedules.
Pitfalls that turn a “quick DB backup” into a false sense of safety
Thinking the host backup is enough. Host snapshots are useful. They are not a substitute for a named, downloadable, restorable copy you control, especially right before a plugin update you chose to run.
Keeping the only copy on the same server. Disk failure, malware, or a bad deploy can wipe site and backup together. Cloud upload (or at least downloading the ZIP/SQL) closes that gap. Read the same-server argument in full here: A WordPress backup on the same server is not a backup.
Never testing restore. An untested backup is a hope file. Restore to staging on a quiet afternoon.
Using DB-only when you also changed files you cannot replace. Custom mu-plugins, unpaid theme edits living only on production, or a media library with no offsite copy still need a full snapshot.
Vague backup names. “Backup 2026-09-07” helps less than “Before WooCommerce 9 update.” Name for the reason.
Assuming Free covers schedules and cloud. Free covers manual backup, restore, migrate, upload, and notifications. Scheduled jobs, retention pruning of automatic backups, and Drive / OneDrive / Dropbox are Pro. If your ritual depends on overnight runs and offsite copies, you want Pro (or the membership that includes it).
Importing old archives without a plan. Snapshotify can import an existing ZIP with chunked upload. Imported archives are never auto-pruned. That is great for bringing history in. It is also how storage fills if you upload every old backup without housekeeping. Import what you need. Label it. Keep the rest in cold storage if you must.
Closing the browser mid-job and panicking. Snapshotify jobs continue if the tab is closed. Progress is visible while you watch. Trust the ticks, then verify the completed snapshot in the list and in cloud if upload was enabled.
A simple pre-update checklist you can steal
- Confirm you have a recent full-site snapshot in cloud (this week is fine for most sites).
- Create a database-only WordPress backup named for the plugin update.
- Wait for it to finish (often under a minute for the DB alone).
- Confirm it appears in the list and, if Pro, that cloud upload succeeded or is queued.
- Update the plugin.
- Smoke-test the front end and the admin screens that plugin owns (checkout, forms, SEO metabox, whatever it touches).
- If something is wrong, restore the DB snapshot on staging first if you can, or restore production carefully with the one-click flow you already practiced.
That checklist turns “I should back up” into a two-minute habit instead of a fourteen-minute chore.
Free vs Pro for this workflow
If you only need occasional manual backups and restores, Snapshotify Free already covers backup, restore, migrate, upload, and notifications. You can absolutely take a database-only snapshot before an update on Free.
If you want the ritual to run without you, add Pro: schedules (daily, weekly, monthly), retention that prunes oldest automatic backups, and cloud destinations (Google Drive, Dropbox, OneDrive) with multiple destinations and reconnect/retry behavior. Manual and uploaded backups stay until you remove them.
Snapshotify Pro is included in DaftPlug Pro membership. One license unlocks all current DaftPlug Pro plugins, and new Pro plugins join existing memberships without a new line item. See Snapshotify for the product walkthrough and pricing for Pro, Pro Plus, and Pro Max.
Reliability notes for large sites and shared hosting
Big WooCommerce catalogs and shared hosting CPU limits are where backup plugins earn or lose trust. Snapshotify batches work for large sites and shared hosting, batches SQL import on restore, shows progress, and keeps jobs running after you close the tab. Database-only runs help here twice: less data to dump, and less data to import if you roll back.
You still should not run a heavy full-site snapshot during peak checkout traffic if you can avoid it. Schedule full runs for quiet hours. Keep DB-only for the moment right before you update.
Takeaway
Plugin updates fail often enough that “I will back up later” is a bad bet. Full-site backups are essential on a cadence, but they are slow enough that people skip them at the worst time. A database-only WordPress backup is the missing middle: fast enough to take every time, focused on the data you cannot rebuild, and restorable with the same one-click path as a full snapshot.
With Snapshotify you can exclude Core, Media, Plugins, and Themes, leave Database in, name the snapshot for the reason, push a copy off the server, and restore when an update goes sideways. Pair that with scheduled full-site archives, cloud destinations on Pro, and one practiced restore on staging, and updates stop feeling like Russian roulette.
Next update notification you see: take the DB snapshot first. Thirty-eight seconds now beats a day of reconstructing orders from email receipts later.
Ready to make that the default? Install or upgrade via Snapshotify, or unlock schedules and cloud with membership on pricing. And if your only backup still lives next to the site it is supposed to save, read A WordPress backup on the same server is not a backup before the next update day.