A differential backup is a backup that copies every change made since the last full backup, regardless of how many differential backups have run in between. In backup and recovery for servers, it sits between the full backup and the incremental backup: it uses more storage and time than incrementals, but a restore needs only two backup sets, the last full and the latest differential.
Each differential is therefore cumulative. A differential taken on Friday after a Sunday full backup contains all of Monday through Friday’s changes, which makes it larger than Thursday’s differential but also makes Thursday’s copy unnecessary for restoring Friday’s state.
How a differential backup identifies changed data
A differential backup needs a reference point, which is always the most recent full backup. Backup software determines what changed since that point using one of several change-tracking methods, and the choice affects speed, accuracy and load on the server.
| Method | How it works | Typical use |
|---|---|---|
| Archive bit | File system flag set on modification, cleared only by full backups | Traditional Windows file backups |
| Modification timestamp | Compares file times with the full backup time | Simple file-level tools |
| Changed block tracking | Hypervisor or driver records modified disk blocks | Virtual machine and image backups |
| Database differential bitmap | Engine marks changed data extents | SQL Server and similar databases |
| Checksums or hashes | Compares content fingerprints with a catalog | Deduplicating backup systems |
The key mechanical difference from an incremental backup is that a differential does not reset the change marker. With the archive-bit method, a full backup clears the bit, an incremental also clears it, but a differential leaves it set, so the next differential sees the same changes again plus new ones.
Differential backup compared with full and incremental backups
The three classic backup types trade backup cost against restore cost. Full backups are expensive to take and simple to restore; incrementals are cheap to take and complex to restore; differentials sit in the middle on both measures.
| Property | Full backup | Differential backup | Incremental backup |
|---|---|---|---|
| Data copied | Everything | Changes since last full | Changes since last backup of any type |
| Backup size over a week | Constant and largest | Grows each day | Small and roughly constant |
| Sets needed to restore | One | Two | Full plus every incremental in the chain |
| Restore speed | Fastest | Fast | Slowest, chain dependent |
| Chain failure risk | Lowest | Low | Higher, one damaged link breaks later restores |
Differentials are also distinct from snapshots. A storage snapshot records a point-in-time state, often on the same storage system, while a differential backup is a separate copy that is usually written to other media or another location and survives the loss of the original volume.
How differential backups grow over time
The size of a differential depends on the daily change rate and on how much changed data overlaps from day to day. If the same database pages change every day, the differential stays relatively small; if new data is written to fresh areas each day, it grows roughly linearly until the next full backup.
The following illustration assumes a 1 TB server with about 3 percent of data changing daily in distinct areas and a full backup every Sunday. It is a simplified model, not a measurement, and real growth is usually lower because of overlapping changes.
| Day | Differential size | Incremental size |
|---|---|---|
| Monday | About 30 GB | About 30 GB |
| Wednesday | About 90 GB | About 30 GB |
| Friday | About 150 GB | About 30 GB |
| Saturday | About 180 GB | About 30 GB |
This growth is why differentials are usually paired with a weekly or more frequent full backup. Extending the full-backup interval to a month can make late-cycle differentials nearly as large as a full backup, which removes most of their advantage.
Choosing a differential backup schedule
Differential backups fit best where restore speed matters and storage or backup windows are moderate. They are common in database environments, where a typical scheme combines a weekly full, daily differentials and frequent transaction log backups to reach a small RPO.
| Situation | Recommended scheme | Reason |
|---|---|---|
| Moderate change rate, fast restore needed | Weekly full plus daily differential | Restore uses only two sets |
| Very high change rate | More frequent full or incremental forever | Differentials grow too quickly |
| Database with tight RPO | Full, differential and log backups | Logs fill the gap between differentials |
| Limited backup window | Incremental with synthetic fulls | Each nightly job stays small |
| Tape or offline media | Full plus differential | Fewer media to locate during restore |
Whatever the scheme, retention must keep the full backup that each differential depends on. Deleting or expiring a full backup while its differentials remain leaves those differentials unusable for restoration.
Limitations and common mistakes
- Breaking the base: an ad hoc full backup taken outside the normal job can become the new reference point, so later differentials depend on a copy that may not be retained. Database engines offer copy-only backups to avoid this.
- Assuming constant size: capacity planning based on Monday’s differential underestimates storage needs late in the cycle.
- Skipping restore tests: a differential is only proven when a restoration test combines it with its full backup successfully.
- Keeping all copies on one system: differentials stored next to the data they protect are lost together with it in ransomware attacks or hardware failure.
In simple terms
Imagine photocopying an entire notebook on Sunday. Each following evening, instead of copying the whole notebook again, you copy every page that has changed since Sunday. By Friday that pile is bigger than on Monday, but it is still much smaller than the whole notebook.
If the notebook is lost on Friday night, you need only two things to rebuild it: Sunday’s complete copy and Friday’s pile of changed pages. That is the whole idea of a differential backup.
A practical example
A regional accounting firm runs its client database on a single server with about 400 GB of data. The IT administrator schedules a full backup every Sunday night, a differential backup every weeknight and transaction log backups every 15 minutes during office hours, all written to a separate backup appliance with an offsite copy.
On a Thursday afternoon a storage failure corrupts the database. The administrator restores Sunday’s full backup, then Wednesday night’s differential, then the log backups taken since that morning. The database is back online in about two hours with at most 15 minutes of lost entries, and the staff re-enter the few affected transactions from paper records.