Updated: October 2026
Both backup types copy only what changed, so on a dashboard they look almost the same. The difference shows up twice: in how much storage the week eats, and in how many files a restore needs when something breaks. Here's what each one copies, a worked week of storage math, what a restore depends on, and how to pick.
The Short Version
A full backup copies everything. An incremental backup copies what changed since the last backup of any kind. A differential backup copies what changed since the last full backup.
| Full | Incremental | Differential | |
|---|---|---|---|
| What it copies | Everything | Changes since the last backup | Changes since the last full |
| Size of each backup | Largest | Smallest | Grows every day until the next full |
| Backup speed | Slowest | Fastest | Slows as the week goes on |
| What a restore needs | One file | The full plus every increment since | The full plus the latest differential |
| Where it hurts | Storage and backup window | One bad file breaks the points after it | Storage late in the cycle |
How a Full Backup Sets the Base
Every scheme starts with a full backup. It's the base that both incrementals and differentials depend on, so if the full is missing or damaged, nothing built on it restores.
That's why fulls get scheduled on a cycle, weekly or monthly, even when changes are small. A new full starts a new chain and caps how far a restore has to reach back.
PowerCert's short animated explainer shows the three types side by side, if you want the picture before the math.
Incremental Backup: Small Files, Long Chains
An incremental backup copies only the blocks or files that changed since the previous backup, whatever type that was. Monday's increment holds Monday's changes, Tuesday's holds Tuesday's, and so on.
That makes each run fast and small, which is why incrementals fit tight backup windows and frequent schedules. The cost comes at restore time. To get back to Saturday, the software needs the full plus every increment from Monday to Saturday, applied in order.
Differential Backup: Files That Grow Until the Next Full
A differential backup copies everything that changed since the last full backup. Microsoft's SQL Server documentation puts it plainly: "A differential backup captures only the data that has changed since that full backup," and the full it depends on is called the base.
The catch is growth. Each differential includes everything since the base, so Tuesday's contains Monday's changes too. Microsoft notes that differentials "can eventually approach the differential base in size," which is why it recommends a new full at set intervals to reset the base.
The upside is the restore. You need two files: the full, and the most recent differential. Nothing in between.
The Storage Math Over One Week
Here's an illustrative example, not a benchmark. Take a 500 GB server with a full backup every Sunday, and assume 2% of the data changes each day, about 10 GB. Assume each day changes different blocks, which is the worst case for differentials.
| Day | Incremental size | Differential size |
|---|---|---|
| Sunday (full) | 500 GB | 500 GB |
| Monday | 10 GB | 10 GB |
| Tuesday | 10 GB | 20 GB |
| Wednesday | 10 GB | 30 GB |
| Thursday | 10 GB | 40 GB |
| Friday | 10 GB | 50 GB |
| Saturday | 10 GB | 60 GB |
| Week total | 560 GB | 710 GB |
The differential week costs 150 GB more, about 27% on top of the incremental week. Stretch the full to monthly and it gets worse: by day 30 a single differential in this example is 300 GB, 60% of the full itself.
Now the restore. Getting Saturday back reads 560 GB either way, the full plus 60 GB of changes. The difference is how many files it takes: seven for the incremental chain, two for the differential.
What Each Restore Needs
File count matters because every file in a chain has to be readable. With incrementals, one damaged or missing increment breaks every restore point after it. With differentials, a bad file costs you that one day, and the next differential still restores against the full.
In this r/msp thread, an MSP running continuous incrementals checked its chains every week and still hit a wall: the recent recovery points wouldn't mount, and the last clean one was the start of a fresh chain four weeks earlier.
Incrementals are still the right tool for frequent backups. Keep the chains short, verify them automatically, and restore from them on a schedule, so a broken link shows up on a Tuesday afternoon instead of during an outage. The disaster recovery testing guide sets out a cadence for those restores.
Synthetic Fulls and Forever-Forward Chains
Modern backup tools blur the line between the two types. A synthetic full is a full backup built on the backup storage from the last full plus its increments, without reading the production server again. You get a fresh base and a short chain without a long backup window.
Forever-forward incremental goes a step further. Veeam's retention documentation describes it: when the chain exceeds its retention, the oldest increment is merged into the full and then removed, so the full "moves" forward one step. The chain never grows past the retention you set.
Both push work onto the backup storage, so slow repositories make them slow. In this r/sysadmin thread, admins compare how often they run active fulls against synthetic ones, and why fast storage changes the answer.
Backup Types Against Ransomware
Ransomware changes what "restore" means. You rarely want the newest restore point, because it may already contain the attacker. Mandiant's M-Trends 2026 puts the global median dwell time at 14 days, so the clean point you need can sit two weeks back.
That puts pressure on retention, not type. An incremental chain has to keep every link back to that clean point, and a differential scheme has to keep the full it was built on. Either way, store the chain where the attacker's credentials can't reach it, on immutable or offline storage, and make sure the retention covers more than two weeks.
Which One Fits, and Where RPO Comes In
Start by separating two decisions that get merged. How much data you can lose, your recovery point objective (RPO), is set by how often the backup runs, not by its type. An incremental every hour and a differential every hour both give you a one-hour RPO. Our RTO vs RPO guide covers setting those targets.
The backup type decides the other trade-offs. Pick incremental when backups run often, bandwidth or the backup window is tight, and your tool verifies chains and builds synthetic fulls. Pick differential when restores need to be simple and fast, storage is cheap, and the data changes slowly enough that differentials stay small between fulls.
For a lot of servers the answer is both: incrementals through the day, a synthetic full each week, and a restore test that proves the chain works.
Pick the Chain You Can Restore
Incremental saves storage and differential saves restore steps, and synthetic fulls let you keep most of both. Whatever you pick, the chain is only as good as the last time you restored from it.
For the tools that run these schedules, our roundup of MSP backup solutions is the next read.
Conrad Lunderstedt
Solution Architect
I'm Conrad, Solution Architect at Flamingo. I've spent about 26 years in IT, roughly half of it inside MSPs and the rest in enterprise environments, so I've watched vendor decisions get made on both sides of that line. Now I spend my days talking with MSPs about the stack they already run, and helping them work through the requests and issues that come with it.
