An incremental backup is a backup that copies only the data that changed since the most recent backup of any type, whether that was a full backup or another incremental one. In backup and recovery for servers, it is the most economical way to protect data frequently, because each run transfers and stores only a small fraction of the full dataset.
The price of that efficiency is the restore chain: recovering a given point in time requires the last full backup plus every incremental backup taken after it, applied in order. Designing an incremental scheme is therefore a trade-off between backup speed and storage on one side and restore time and chain risk on the other.
How an incremental backup detects changes
Every incremental backup needs a reliable way to decide which data changed since the previous run. The detection method determines both the speed of the job and how small each increment can be.
| Method | Granularity | How it works | Typical context |
|---|---|---|---|
| Modification time | File | Compares file timestamps with the last run | File-level tools such as rsync-based scripts |
| Archive bit | File | Uses a file attribute that the backup clears | Older Windows backup software |
| Changed block tracking | Block | The hypervisor or driver records written blocks | Virtual machine backup |
| Content hashing and deduplication | Chunk | Stores only chunks with new hashes | Modern repositories such as Borg or restic |
| Transaction log | Transaction | Copies database logs written since the last backup | PostgreSQL WAL, MySQL binary logs |
Block-level and chunk-level methods are far more efficient than file-level ones for large files that change slightly, such as database files or virtual disks, because a file-level tool would copy the whole file after any single modification.
Incremental, differential and full backups compared
The three classic backup types differ in what each run copies and therefore in what a restore needs. The table compares them for a weekly full backup followed by daily runs.
| Backup type | Copies since | Size growth during the week | Needed to restore day 6 |
|---|---|---|---|
| Full backup | Nothing, copies everything | Constant and large | Only the day 6 full backup |
| Differential backup | The last full backup | Grows every day | Full backup plus the day 6 differential |
| Incremental backup | The last backup of any type | Small and roughly constant | Full backup plus incrementals 1 to 6 |
Incremental backups therefore offer the shortest backup window and the lowest storage use, while differential backups offer a simpler and faster restore. Snapshots are a related but different tool: they capture a point in time on the same storage system and are not a backup until they are copied elsewhere.
Common incremental backup schemes
Real deployments rarely use incrementals forever without structure. Several schemes keep the restore chain short while preserving the storage savings.
| Scheme | How it works | Main benefit | Main caution |
|---|---|---|---|
| Weekly full plus daily incrementals | A new full backup starts each chain | Chain never exceeds about 7 links | Weekly full backups load the source |
| Forever incremental | One initial full, then incrementals only | Minimal backup traffic | Requires merging or a robust repository |
| Synthetic full | The server merges a full from existing increments | Fresh full without reading the source | Needs repository CPU and I/O |
| Multilevel backup | Levels 0 to 9 as in the classic dump tool | Flexible balance of size and chain length | Harder to understand and audit |
Deduplicating repositories effectively make every snapshot restorable on its own, because each stored point references all chunks it needs. This removes most chain risk while keeping incremental transfer sizes.
Choosing frequency and retention
The frequency of incremental backups follows directly from the recovery point objective, the maximum acceptable data loss. Retention follows from how far back an error may be discovered.
| Workload | Incremental frequency | Full or synthetic full | Reason |
|---|---|---|---|
| Static website files | Daily | Weekly or monthly | Content changes rarely |
| File server | Every 4 to 12 hours | Weekly | Moderate daily change rate |
| Transactional database | Log backups every 5 to 15 minutes | Daily | RPO of minutes |
| Virtual machines | Daily to hourly with block tracking | Weekly synthetic | Large disks, small changes |
Risks and common mistakes
Incremental backups are reliable only when the whole chain stays intact and restores are verified regularly.
- A broken link such as a corrupted or deleted incremental makes every later point unrestorable in chain-based formats.
- Long chains slow restores, because dozens of increments must be read and applied in sequence.
- Missed changes occur when timestamps are preserved by a copy tool or when the archive bit is reset by another program.
- No restoration test means chain problems surface only during a real incident.
- Same-location storage loses the full backup and all increments together in a fire or ransomware attack.
A plain-language summary
Imagine photographing a whole bookshelf once, then each evening photographing only the books that moved. That is far quicker than photographing the full shelf every day.
To rebuild the shelf as it looked on Friday, you start with the first full photo and apply every evening’s changes in order. If one evening’s photo is lost, everything after it is uncertain, which is why the full picture is retaken regularly and the whole set is checked.
An example from practice
A small accounting firm stores about 2 TB of documents on a file server, and roughly 15 GB change on a typical working day. A nightly full backup over its office uplink would take many hours, so the administrator configures a full backup every Sunday and incremental backups every night, each finishing in under 20 minutes and sent to an offsite repository.
When an employee overwrites a client folder on Thursday, the administrator restores Wednesday evening’s state by applying the Sunday full backup and three incrementals. The restore takes about 25 minutes. A monthly restoration test of a random folder confirms that the chain remains complete and usable.