Short answer: a full backup copies everything. An incremental copies what changed since the last backup of any kind. A differential copies what changed since the last full backup.
The difference between the last two is one word — "any kind" versus "full" — and it decides how many files you need to perform a restore.
| Copies | Backup size | Restore needs | Restore speed | |
|---|---|---|---|---|
| Full | Everything | Largest | 1 file | Fastest |
| Incremental | Since last backup | Smallest | Full + every incremental in order | Slowest |
| Differential | Since last full | Grows daily | Full + latest differential only | Middle |
The week, laid out
Full backup Sunday, then Monday to Saturday. Restore on Saturday afternoon:
Incremental — each day copies only what changed since yesterday:
Sun [FULL 100 GB] → Mon [2] → Tue [3] → Wed [2] → Thu [4] → Fri [2] → Sat [3]
Restore Saturday: Sunday + Mon + Tue + Wed + Thu + Fri + Sat = 7 files, in order
Differential — each day copies everything changed since Sunday:
Sun [FULL 100 GB] → Mon [2] → Tue [5] → Wed [7] → Thu [11] → Fri [13] → Sat [16]
Restore Saturday: Sunday + Saturday = 2 files
Same data, same week. Incremental stored 16 GB of deltas; differential stored 54 GB. But the incremental restore depends on seven files being present and readable, and the differential on two.
Why that matters more than the storage saving
An incremental chain is only as strong as its weakest link. Lose Wednesday's file — corrupted, deleted by a retention script, or written to a disk that failed — and you cannot restore Thursday, Friday, or Saturday either. You can restore up to Tuesday. Three days of work are gone, not because those backups failed, but because a file in the middle of the chain did.
This is the failure mode that makes people distrust incrementals, and it is a real one. Differential chains have exactly two links, so there is far less to go wrong.
Restore time is where the cost lands. Applying six incrementals in sequence, each waiting for the last, is meaningfully slower than applying one differential. That difference goes straight into your RTO — and RTO is the number measured while your service is down.
The classic rule of thumb: incremental optimises the backup window, differential optimises the restore window. Backups happen every night and nobody watches. Restores happen once and everyone watches.
Synthetic full and forever-incremental
Two techniques exist to escape the trade-off, and you will see both marketed heavily.
Synthetic full. The backup server takes the last full plus the incrementals since, and merges them into a brand new full backup — without touching the production system. You get a fresh single-file restore point at no cost to the source.
Forever-incremental. One full backup, ever. Everything after is incremental, and the system periodically synthesises new fulls in the background so the restore chain never grows unbounded.
Both are real improvements. Both are also compensating for a design where a "backup" is a sequential file that must be replayed.
The modern answer makes the question obsolete
Content-addressed, deduplicating backup systems — this one, restic, Borg — do not have these categories at all, and it is worth understanding why rather than treating it as marketing.
Data is split into chunks by content, and each chunk is stored under a hash of itself. A snapshot is a list of chunk hashes. So:
- Physically, every backup is incremental. Only chunks not already stored get uploaded. A 100 GB database with 2% churn ships roughly 2 GB.
- Logically, every backup is full. The snapshot names every chunk in the dataset, so restoring needs that one snapshot and nothing else.
There is no chain. Deleting an old snapshot cannot break a newer one, because chunks still referenced are simply kept:
// Each run is a complete restore point AND uploads only the delta.
const snapshot = await client.backup(["./db-dumps"], {
description: "nightly",
tags: { type: "db-backup", env: "prod" },
});
// Restoring needs this snapshot alone — no chain to replay.
await client.restore(snapshot.snapshotId, "./restore-target");
That is the whole trade-off — small backups versus simple restores — resolved rather than balanced. It is also why deduplication matters more than the backup-type taxonomy it replaced.
So which should you use?
If your tool has these modes, pick differential unless the backup window forces otherwise. The storage is cheaper than the risk, and the restore is simpler on the day you care.
If you are choosing a tool, prefer one where the question does not arise. A system where every snapshot restores independently removes an entire class of failure — the broken chain — rather than managing it.
Either way, one thing is not optional: test the restore. A chain-based scheme in particular can look perfectly healthy for months while a middle link is quietly unreadable, and the only thing that surfaces it is actually replaying the chain.
Common questions
Can I mix incremental and differential? Yes, and a common pattern is weekly full, daily incremental, plus a mid-week differential to shorten the chain. It works and it is more moving parts to get wrong.
Which is faster to back up? Incremental, always — it copies the least. The gap widens the further you are from the last full.
Which uses less storage? Incremental, before deduplication. After deduplication, the difference largely disappears, because a differential re-copying yesterday's unchanged blocks stores nothing new.
Is a snapshot the same as an incremental backup? No — different concept entirely. See backup vs replication vs snapshot vs archive.
What about the first backup? Always full, in every scheme. There is nothing to be incremental against.
Start with the free tier: backupdata.io has 5 GB free, no card, and the 10-minute quickstart gets you to a first verified snapshot today.