What is reverse incremental backup?
Reverse incremental backup is a backup method in which the most recent restore point is always a complete full backup. Each job writes changed blocks into that full and saves the blocks it replaces in a rollback file, so older restore points are reached by stepping backwards from the newest one.
How does each job update the chain?
The first job creates a full. On every later job, each block that changed in production goes through three steps:
- The block about to be replaced is read from the full.
- It is written to that day's rollback file.
- The new block from production is written into the full.
Reverse incremental layout
Older restore points are rebuilt by applying rollback files to the newest full, one job at a time.
The result is a full that matches the latest backup and a series of rollback files, each holding what the full looked like one job earlier. Restoring yesterday means applying yesterday's rollback file to today's full.
Why is the newest restore point the fastest to restore?
Most restores are of the latest data. In a reverse incremental chain that point is a single full file, so nothing has to be assembled, and instant recovery can run it straight from backup storage. In a forward incremental chain the same point sits at the end and depends on every file before it. Older points work the other way round: the further back, the more rollback files a restore applies.
What does the method cost?
Each changed block costs one read and two writes on the backup target, where a forward incremental costs a single write. Jobs take longer to finish on the storage side and generate more random I/O, which suits fast disk better than high-capacity storage. Every older restore point also depends on the one full, so damage to that file affects the whole chain. Removing an expired restore point is cheap: the oldest rollback file is deleted.
Why does it conflict with immutable storage?
The method rewrites the same full file on every run. Immutable storage, whether through S3 Object Lock or WORM, forbids changing data once it is written. The two cannot be combined: a reverse incremental full cannot be locked, because the next job has to modify it. An immutable copy of the same data is kept as a separate chain in a format that writes each file once.
Frequently asked questions
Is reverse incremental the same as a differential backup?
No. A differential stores everything changed since the last full and grows through the cycle. A reverse incremental stores the previous state of changed blocks and keeps the full current.
Does reverse incremental use more capacity?
Not much. It holds one full plus rollback files roughly the size of each day's changes, which is close to a forward chain with a single full.
Why do many designs use forward incremental instead?
Forward chains with synthetic fulls avoid the extra I/O on every job and write files once, which keeps them compatible with immutable storage.
Related terms
- Forward incremental backup: the chain that grows forward from the oldest full.
- Incremental forever backup: one full and changes only, merged as points expire.
- Immutable backup: copies that cannot be changed, and why this method cannot be one.
- Instant recovery: running the latest full directly from backup storage.
- Differential backup: a different way of storing changes against a full.