Home  ›  Glossary  ›  Incremental Forever Backup

What is incremental forever backup?

Incremental forever backup is a backup method that takes one full backup at the start and only incremental backups after that, with no further full reads of production. As old restore points expire, their changes are merged into the base, so a complete restore point can always be assembled from a chain of fixed length.

How does the chain stay the same length?

  1. The first job copies the whole protected system as a full backup.
  2. Every later job copies only the blocks or files that changed since the previous one, as an incremental backup.
  3. Once the retention limit is reached, the oldest incremental is merged into the full, which moves the base forward by one restore point.
  4. The chain therefore always holds one full and a set number of incrementals, and the full always represents the oldest restore point kept.

With 14 restore points kept, the chain holds the base and 13 incrementals on every day after the second week.

What does the method save?

Production is read in full only once. After that, each job reads and sends only what changed, so the backup window stays short and the source systems and network carry a light load even as the data set grows. This is why the method is common for large virtual machine estates and for remote sites with limited bandwidth.

What does it trade away?

  • No fresh copy of the source. The base is never rebuilt from production, so a block damaged in the base or in an incremental stays in every restore point built on it, and the backup storage cannot detect this by itself.
  • Work moves to the storage side. Each merge reads and rewrites data on the backup storage. Storage that can reference blocks it already holds makes the merge much lighter.
  • One chain for everything. Every restore point depends on the same base, so damage to it affects all of them at once.

Schedules commonly add health checks that reread stored blocks against their checksums, or an occasional new full from production, which turns the design into a forward incremental chain with periodic fulls.

How does the merge interact with locked storage?

The merge changes the base every time the oldest restore point expires. Storage that locks data against change, such as storage using S3 Object Lock, refuses that change for as long as the lock lasts. Incremental forever on immutable storage therefore depends on the backup software writing the merged result as new data instead of rewriting the locked base.

Frequently asked questions

Is incremental forever the same as forward incremental?

It is one form of it. A forward incremental chain either takes periodic fulls or, in the forever form, merges old incrementals into the base and never takes another full.

Are restores slower with incremental forever?

Not necessarily. Retention caps the chain length, so the software never has to apply more than a fixed number of incrementals to assemble a restore point.

Does incremental forever replace synthetic fulls?

It can. Some designs merge into the base on every run; others keep a forward chain and build a synthetic full on a schedule. Both avoid reading production in full again.