Full vs Incremental vs Differential

Backup types are about what changes you capture and how hard restores become. For WordPress on a VPS, the best approach is usually a hybrid: frequent database dumps, snapshot-style file backups, and periodic full baselines.

Quick Summary

• Full: easiest restores, most storage.
• Incremental: smallest backups, slowest/riskiest restores if the chain breaks.
• Differential: middle ground; restore needs last full + last differential.
• WordPress reality: database changes frequently; files change less often.

Core definitions

Type	What it captures	Restore requires	Typical trade-off
Full	Everything at a point in time	That single backup	Large artifacts, simplest restore
Incremental	Changes since the last backup (full or incremental)	Last full + every incremental after it	Efficient storage, complex restore chain
Differential	Changes since the last full backup	Last full + latest differential	More storage than incremental, simpler restore

What actually changes in WordPress

WordPress data has different "change rates":

• Database (posts, orders, users, settings): changes often.
• wp-content/uploads/: changes when media is added.
• Themes/plugins: change during updates (usually less often).
• WordPress core: can be reinstalled, but version drift matters.

This is why many WordPress backup designs treat:

• DB dumps as frequent "full" backups (because incremental DB backups are harder), and
• file backups as snapshot/incremental (because rsync-style deltas are easy).

Comparison (operational view)

Feature	Full	Incremental	Differential
Backup runtime	Slowest	Fastest	Medium
Storage usage	Highest	Lowest	Medium-to-high
Restore time	Fastest	Slowest	Medium
Restore complexity	Low	High	Medium
Failure blast radius	Small	Larger (chain dependency)	Medium
Best fit	Baselines, migrations	High-frequency file snapshots	Mid-cycle checkpoints

warning

Incremental backups create a dependency chain. If you delete or corrupt one link, restores may be impossible.

Practical implementations on a VPS

This section shows common Linux-friendly patterns. Use staging restores first.

Full backup (files)

Full file backup as tar.zst:

full-files-backup-tar-zst.sh

sudo mkdir -p /backups

sudo tar -C /var/www/html -cf - . \
  | zstd -3 -T0 -o "/backups/wp-files-$(date +%F).tar.zst"

Full backup (database)

full-db-dump-zstd.sh

mysqldump --single-transaction --quick --routines --events --triggers \
  --column-statistics=0 wordpress \
  | zstd -3 -T0 -o "/backups/wp-db-$(date +%F).sql.zst"

Incremental-style backups (files)

On Linux, "incremental files" is usually implemented as snapshots with rsync deltas.

incremental-files-rsync-link-dest.sh

set -euo pipefail

BASE="/backups/snapshots"
TODAY="$(date +%F)"

DEST="$BASE/$TODAY/files"
PREV="$BASE/latest/files"

sudo mkdir -p "$DEST"

sudo rsync -a \
  --delete \
  --link-dest="$PREV" \
  --exclude 'wp-content/cache/' \
  --exclude 'wp-content/*/cache/' \
  /var/www/html/ \
  "$DEST/"

sudo rm -f "$BASE/latest"
sudo ln -s "$BASE/$TODAY" "$BASE/latest"

Differential-style backups (files)

Differential means "changes since the last full". Practically, you can treat a specific baseline snapshot as the "full" and link against it.

differential-files-rsync-link-dest.sh

set -euo pipefail

BASE="/backups/snapshots"
BASELINE="$BASE/BASELINE/files"
TODAY="$(date +%F)"
DEST="$BASE/$TODAY/files-diff"

sudo mkdir -p "$DEST"

sudo rsync -a \
  --delete \
  --link-dest="$BASELINE" \
  /var/www/html/ \
  "$DEST/"

Notes:

• If you refresh the baseline weekly, differentials grow until the next baseline.
• Keep retention aware of baselines.

Restore implications you should plan for

Restoring full

You restore one artifact (files) and one artifact (DB).

restore-full-files-into-staging.sh

sudo rm -rf /tmp/restore-test
sudo mkdir -p /tmp/restore-test

sudo tar --use-compress-program=zstd -xf /backups/wp-files-2026-03-01.tar.zst -C /tmp/restore-test

Restoring incremental chains

You need:

• the baseline (full), and
• every snapshot after it up to the desired point.

This is why verification and retention policies matter. If pruning deletes the baseline, the chain is broken.

A WordPress-friendly schedule (starting point)

Choose a schedule that matches how your site changes.

Site type	Suggested DB	Suggested files	Suggested full baseline
Small brochure site	daily dump	daily snapshot	weekly full archive
Blog with media uploads	every 6-12h	daily snapshot	weekly full archive
WooCommerce	hourly dump (or more)	daily snapshot	weekly full archive

For many teams:

• database dumps are frequent and "full" (simpler restores)
• files use snapshot-style rsync (storage efficient)

Common mistakes

• Keeping only incrementals without a tested restore path.
• Changing exclude rules mid-chain and expecting deterministic restores.
• Pruning baselines before dependent snapshots.
• Backing up without doing restore drills.

---

A quick decision checklist

Use this to pick the right mix:

• If you need the simplest restore: bias toward full backups.
• If you need small daily file backups: use snapshot-style rsync.
• If you need low data loss (low RPO): increase DB dump frequency.
• If you need low downtime (low RTO): keep a fast local copy and rehearse restores.

Verification checklist

After creating backups, run checks that match your formats.

verify-backup-artifacts-by-format.sh

set -e

zstd -t /backups/wp-files-2026-03-01.tar.zst
zstd -t /backups/wp-db-2026-03-01.sql.zst

tar --use-compress-program=zstd -tf /backups/wp-files-2026-03-01.tar.zst | sed -n '1,20p'

If you use snapshot directories, confirm the expected WordPress paths exist:

verify-snapshot-has-wordpress-layout.sh

test -d /backups/snapshots/latest/files/wp-content
find /backups/snapshots/latest/files -maxdepth 2 -type f -name wp-config.php -print

Worked example schedule

This example is easy to operate and restores quickly:

Cadence	Database	Files
Daily	full dump (compressed)	snapshot-style rsync
Weekly	keep baseline dump	keep full archive (.tar.zst)
Monthly	keep one weekly	keep one weekly

Next steps

• Snapshot folder design: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/snapshot-style-backup-folder.mdx.
• Retention policies: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rotation--retention-policies.mdx.
• RPO/RTO planning: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rpo-vs-rto.mdx.