Home  ›  Glossary  ›  Synthetic Full Backup

What is synthetic full backup?

Synthetic full backup is a full backup that the backup software builds on the backup storage from the last full and the incremental backups taken since. No data is read from production again, yet the result restores like any other full.

It exists mainly to keep regular fulls possible once data has outgrown the time available to copy it.

A fresh edition from pages already printed

Think of a manual that gets a few corrected pages each week. Nobody retypes the whole book. An editor takes the last printed copy, swaps in the newest version of each changed page and binds a fresh edition.

A synthetic full does the same with backup data. The software looks through the last full backup and the incrementals after it. For each piece of data it picks the newest version, then writes those pieces into a new full.

Production servers only see one short incremental, taken first to bring the chain up to date. It is one of several schedules covered under data backup.

When building beats copying

  • The weekly full no longer finishes. Data has outgrown the backup window, so reading everything again is not an option.
  • Production is already busy. A full read would slow servers, storage and the network during working hours.
  • Restores are getting slow. Every incremental backup in a long chain adds a step to a restore. A fresh full shortens the chain.
  • Remote sites sit behind slow links. Pulling a full across the wide-area network could take days.

On object storage, some backup applications skip weekly synthetic fulls altogether. Veeam, for one, keeps one ever-growing chain by default when it writes straight to a bucket, as described under Veeam backup to object storage.

Damage gets copied too

A synthetic full can only contain what the older backup files contain. If a block in the chain is silently damaged, the new full inherits it, and the job still reports success. An occasional active full, read fresh from production, restarts the chain from clean data.

Building the new full is also heavy work for the backup storage. Some formats copy every block again. Others simply point at blocks already stored, which is quick and saves space.

The catch is that one bad block then sits inside every full that shares it. Restore testing is how that kind of problem surfaces before an incident does.

ARTESCA and synthetic full backup

ARTESCA stores whatever chain format the backup application writes over S3. It is validated with Veeam Backup & Replication, S3 Object Lock included. When several restore points share stored objects, each object version keeps its own retain-until date. In compliance mode no account, root included, can remove a locked version early, so data that newer restore points still need stays in place while its lock runs.

Building synthetic fulls and checking the chain stay with the backup software. ARTESCA holds the objects. It does not merge or verify backup chains.