Every backup schedule eventually runs into the same wall: a full backup of the entire dataset every night is safe, simple to restore, and completely unworkable once the dataset grows past a few hundred gigabytes. The backup window blows past its limit, the storage bill climbs, and the network link to the target starts to look like the bottleneck it is. The fix practitioners reach for is some combination of incremental and differential backup — but the two terms get used interchangeably often enough that teams design restore procedures around the wrong assumptions. That confusion is not academic. It shows up at 3 a.m. during an actual recovery, when someone discovers that “differential” restore they assumed would take one step actually requires walking a six-week chain of dependent files.
This piece breaks down how full, incremental, and differential backups actually work, where the storage and time tradeoffs land, why the restore-chain risk differs so sharply between incremental and differential strategies, how grandfather-father-son (GFS) retention schedules organize all three, and how modern block-level and deduplicating tools have quietly changed — without eliminating — the classic tradeoff.
Full, Incremental, and Differential: The Building Blocks
A full backup copies every selected file or block, regardless of whether it changed since the last backup. It is the baseline every other backup type depends on: incrementals and differentials are both defined relative to the most recent full. Fulls are the simplest to restore — one copy operation, one dataset — but the most expensive to run repeatedly. A weekly full of a 10 TB file server, for instance, means moving and storing 10 TB every single week even if only a few gigabytes actually changed.
An incremental backup copies only the data that changed since the last backup of any kind — full or incremental. A differential backup copies everything that changed since the last full backup, and keeps copying the same growing set of changes with every run until the next full. That single distinction — “since the last backup” versus “since the last full” — is the entire difference between the two, and it drives every downstream tradeoff in storage consumption, backup duration, and restore complexity.
Most contingency planning frameworks treat this choice as a core design decision rather than an implementation detail. NIST Special Publication 800-34, the federal contingency planning guide, frames backup method selection explicitly around recovery time and recovery point objectives — the same variables that determine whether incremental or differential is the better fit for a given system, a topic covered in more depth in our guide to RPO vs RTO.
How Incremental Backup Works (and Why It’s Efficient)
Picture a Sunday full backup followed by incrementals every night through Saturday. Monday’s incremental captures only what changed since Sunday. Tuesday’s incremental captures only what changed since Monday’s incremental — not since Sunday. Wednesday’s captures only what changed since Tuesday, and so on. Each incremental is small, because it only has to account for one day’s worth of change instead of an accumulating week’s worth.
The efficiency gain is real and significant. On a dataset with a 2-3% daily change rate, a nightly incremental might be a fraction of the size of a differential run on day five or six of the same cycle. Backup windows shrink, network transfer drops, and storage consumption on the target stays close to the actual rate of data churn rather than growing throughout the week.
The cost of that efficiency is restore complexity. To recover the full dataset as of Saturday, a restore has to apply the full backup from Sunday, then every incremental in sequence: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday. Skip one, corrupt one, or lose one link in that chain and every subsequent incremental becomes unusable — the restore stops wherever the chain breaks. This is the incremental dependency chain, and it is the single biggest operational risk incremental strategies introduce. A media failure on Wednesday’s incremental does not just cost you Wednesday’s changes; it can silently invalidate Thursday, Friday, and Saturday as well, depending on how the backup software tracks change blocks.
How Differential Backup Works (and Why Restores Are Simpler)
A differential backup takes a different reference point. Every differential run captures everything changed since the last full backup, not since the last backup of any kind. Monday’s differential captures Monday’s changes. Tuesday’s differential captures both Monday’s and Tuesday’s changes. By Saturday, the differential contains everything that changed all week — which means each day’s differential is larger than the last, and by the end of a long cycle it can approach the size of a full backup itself.
That growing size is the tradeoff, and it is a real one: storage consumption and backup duration both increase as the cycle goes on, the opposite of the incremental’s flat, small daily footprint. What you get in exchange is a dramatically simpler restore. Recovering Saturday’s data requires exactly two steps: restore Sunday’s full backup, then apply Saturday’s differential. There is no multi-day chain to walk and no intermediate day that can silently break the restore. One full, one differential, done.
For systems where recovery time objective is tight and restore reliability matters more than shaving backup-window minutes, that two-step restore is often worth the extra storage and transfer cost. For systems with high change rates or long cycles between fulls, the differential’s growth curve can erase most of its simplicity advantage by the end of the week.
Restore-Chain Risk: The Real Tradeoff
Strip away the storage math and the decision between incremental and differential really comes down to one question: how much restore-chain risk is the organization willing to carry, and in exchange for how much saved storage and backup time?
Incremental’s chain risk is cumulative and grows with cycle length. A weekly cycle with six nightly incrementals has six links that all have to hold. A monthly cycle with 29 incrementals has 29 links — and 29 opportunities for a single corrupted, missing, or improperly indexed increment to cap how far back a clean restore can reach. Backup software that tracks incrementals with strong indexing and consistency checks mitigates this, but it does not eliminate the structural fact that recovery depends on an unbroken sequence.
Differential’s risk profile is flatter and bounded: exactly two components, always. The failure mode is different in kind, not just degree — losing the differential means falling back to the full backup and eating whatever data loss that represents, but it never cascades the way a broken incremental link does partway through a restore.
Many production environments split the difference deliberately: a full backup on a fixed schedule, differentials through most of the cycle, and incrementals reserved for systems where the change rate is high enough that a growing differential would blow the backup window. Neither approach is universally correct — a distinction any solid discipline built on the 3-2-1 backup rule has to account for when deciding how the third, offsite copy of data gets refreshed.
Where GFS Retention Fits In
Grandfather-father-son (GFS) is a retention scheme, not a backup method — it answers “how long do we keep copies and at what granularity,” not “how do we capture changes.” GFS layers three tiers on top of whatever full/incremental/differential method is in use:
- Son: daily backups, retained for a short window (commonly a week or two)
- Father: weekly backups, retained for a month or more
- Grandfather: monthly (or sometimes quarterly/annual) backups, retained for a year or longer
In practice, the daily “son” backups are usually incrementals or differentials run against a weekly full, the weekly “father” backups are often the full backups themselves, and the monthly “grandfather” tier consolidates into a long-retention full copy. GFS gives an organization a defensible answer to “how far back can we go” without keeping 365 full backups’ worth of storage on hand, and it maps naturally onto whichever incremental or differential cadence a given system uses day to day. The retention question is closely related to, but distinct from, the recovery point and recovery time targets discussed in NIST 800-34 — GFS determines what exists to restore from; RPO and RTO determine how current and how fast that restore needs to be.
How Block-Level and Deduplicating Tools Change the Calculus
The classic incremental-versus-differential tradeoff was built around file-level backup: a tool decides whether a file changed, and if so, copies the whole file again. That model is why differentials grow the way they do — a single modified byte in a large database file means the entire file gets recopied on every differential run for the rest of the cycle.
Modern backup tools built around content-addressable, block-level deduplication change this math substantially. Tools in the class of Borg and Restic — along with block-level dedup features in many commercial platforms — split files into content-defined chunks, fingerprint each chunk, and only store chunks that haven’t already been seen. The practical effect is that every backup run, regardless of whether you conceptually call it “incremental” or “full,” only transmits and stores genuinely new data at the block level. A tool like Borg can present each run to the user as a full, independently restorable snapshot, while physically storing only the deduplicated delta against everything already in the repository.
This doesn’t make the underlying tradeoff disappear so much as it moves where it lives. The restore-chain risk that plagues traditional incrementals is largely neutralized, because deduplicating tools typically expose every snapshot as a complete, independently mountable point-in-time view rather than a fragile sequence of diffs — the repository’s internal chunk store handles the “what’s actually new” bookkeeping instead of the restore process. The engineering effort shifts instead to protecting the integrity of the shared chunk store and its index: if that index is corrupted, every snapshot referencing it is affected, which is a different failure mode than a broken incremental chain but not a trivially smaller one. Compression, encryption, and chunk-level verification (via checksums or Merkle-tree style structures) become the load-bearing reliability features in this model, in much the same way that indexing and chain integrity are load-bearing for traditional incremental strategies. Organizations moving to these tools still need the same underlying 3-2-1 backup rule discipline around copy count, media diversity, and offsite placement — deduplication changes storage efficiency and restore mechanics, not the fundamental need for independent, verified copies.
Frequently Asked Questions
Which is faster to restore, incremental or differential?
Differential is generally faster and simpler to restore because it only requires two components: the last full backup and the most recent differential. Incremental restores require applying the full backup plus every incremental in sequence since that full, which takes longer and introduces more points where a single bad or missing increment can stall the recovery.
What is a synthetic full backup?
A synthetic full is a full backup created by combining a previous full with subsequent incrementals or differentials on the backup server, without re-reading the entire source dataset again. It gives you a fresh, restorable full backup on the schedule you want while avoiding the transfer and I/O cost of a true full backup pass against production systems.
How does deduplication change this tradeoff?
Block-level deduplication, used by tools in the Borg and Restic class, chunks data and stores only content that hasn’t already been seen, so every run — however it’s labeled — moves and stores just the genuinely new bytes. This largely removes the traditional restore-chain fragility of file-level incrementals, though it shifts reliability concerns onto the integrity of the shared chunk index.
Do I still need a full backup if I use incremental or differential backups?
Yes. Both incremental and differential backups are defined relative to a full backup and cannot stand alone — there is nothing to apply the changes to without one. Even deduplicating tools that avoid traditional “full” passes still need an initial complete ingest of the dataset before any subsequent run has a baseline to diff against.
How often should I run a full backup versus incrementals or differentials?
There’s no universal number; it depends on daily change rate, backup window, and how much restore-chain risk is acceptable. A common pattern is a weekly full with daily incrementals or differentials in between, adjusted upward in frequency for high-change-rate systems and mapped onto a GFS retention schedule for longer-term recovery points.