Incremental database backups sound efficient: only save what changed since the last snapshot, cut storage costs, speed up the process. Most WordPress backup plugins offer the option, and plenty of managed hosts enable it by default.
But incremental backups make silent trade-offs. They skip tables that haven’t registered a timestamp change, ignore transient data that might matter during recovery, and often fail to capture schema modifications. If you’ve ever restored from an incremental backup and found missing comments, broken plugin settings, or mysteriously stale content, this is why.
How incremental database backups decide what to save
An incremental backup compares the current database state to the last full or incremental snapshot. It looks for changed rows, usually by checking a modified or updated_at timestamp column. If a row hasn’t been touched since the last backup, it gets skipped.
That works well for posts, pages, and user accounts—tables with reliable timestamp tracking. It breaks down for:
- Tables without timestamp columns. Some plugins store settings in custom tables with no date field. The backup tool can’t tell if the data changed, so it assumes it didn’t.
- Schema changes. If you add a column, rename a table, or adjust an index, the incremental job may not flag that as a data change. The new structure exists, but the backup doesn’t record it.
- Transient and cache tables. WordPress uses
wp_optionsto store transients—temporary data with expiration timestamps. Incremental backups often exclude transients by design, assuming they’re disposable. That’s true for caching, but some plugins misuse transients to store semi-permanent config. - Comment metadata. If a comment gets edited or a new meta field is added via a plugin, the parent comment row’s timestamp might not update. The incremental scan misses it.
You won’t notice the gaps until you restore. Then you’re troubleshooting why a contact form stopped working or why a membership plugin forgot half its settings.
When incremental backups make sense
If your site publishes daily content and you’re backing up multiple times per day, incremental snapshots cut down on redundant transfers. A site publishing ten posts a day doesn’t need to re-export its entire wp_posts table every hour—just the new rows.
Incremental backups also help when bandwidth or storage is metered. A full WordPress database backup on a site with 50,000 posts and 200,000 comments can run 500 MB to 1 GB compressed. Doing that hourly gets expensive. An incremental job might be 5–20 MB.
But incremental-only strategies fail during migrations, plugin conflicts, or schema drift. If your last full backup was three months ago and you’ve been running incrementals since, you’re stitching together dozens of delta files during a restore. One corrupted increment in the chain, and the whole recovery breaks.
How to layer full and incremental backups without waste
Run a full database backup weekly. Run incrementals daily or after major content pushes. Store both.
Most backup plugins let you set independent schedules. UpdraftPlus, for example, supports separate intervals for full and incremental jobs. BackupBuddy and BlogVault do the same. If you’re on managed WordPress hosting with BigScoots or a similar provider, check whether their automated backups are full or incremental—and whether you can trigger a manual full snapshot before big updates.
Tag your full backups clearly. If you’re using a plugin that stores backups in Amazon S3, Google Cloud Storage, or Backblaze B2, add a naming convention: full-2026-09-27.sql.gz vs. incr-2026-09-27-14-00.sql.gz. When you need to restore, you’ll know which file is the anchor.
Test a restore at least once per quarter. Spin up a local WordPress instance with Local by Flywheel or a staging environment, restore from your most recent full backup, then layer on the incrementals. Confirm that everything loads: plugins activate, custom post types appear, user roles are intact, and forms submit. If something’s missing, adjust your backup scope or switch to full-only until you know why.
What to check in your plugin’s incremental settings
Open your backup plugin’s settings and look for these options:
- Table exclusion list. Some plugins exclude
wp_optionstransients by default. If you rely on plugins that store settings there, remove the exclusion or switch to full backups. - Change detection method. Does the plugin use timestamp columns, row checksums, or binary logs? Checksum-based detection catches more changes but takes longer. Timestamp detection is faster but misses schema edits.
- Retention policy. How many incremental snapshots does the plugin keep? If it’s set to retain only the last seven, and your last full backup was two weeks ago, you can’t reconstruct the database past seven days.
- Manual trigger. Can you force a full backup on demand? You should be able to run one before plugin updates, theme changes, or bulk imports—events that modify the database in ways incrementals might miss.
If your plugin doesn’t expose these controls, consider switching. UpdraftPlus, BackWPup, and Duplicator all offer granular settings. Managed hosts often abstract this away—ask support whether their incremental backups include schema changes and plugin config tables.
Want more breakdowns of the infrastructure tools that underpin online businesses? Subscribe to One Two Three Send and get one operator-focused deep dive every day.