Full, incremental, differential and synthetic full backups compared

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-16

What are the backup types, and how do they compare?

The types differ in four things that matter later: how much storage they use, how long a run takes, how much work a restore needs and how much a broken link in the chain costs you.

A vendor-neutral summary based on the Veeam and Microsoft documentation listed under Sources. Individual tools differ, so read how yours stores its restore points.

How do backup chains work?

The difference between incremental and differential is clearest in what a restore needs. Restoring the third incremental needs the full backup and all three increments in order. Restoring the third differential needs the full backup and that one differential, because each differential is measured against the full backup.

Schematic. Real tools add metadata and may merge or rebuild parts of the chain.

What is forever-incremental, and what is a synthetic full?

Veeam's forever forward incremental method keeps one full backup file and a series of incremental files. When a run exceeds the retention setting, the oldest increment is merged into the full backup, so the chain never needs a new full backup. It saves the most space. The trade-offs are the merge, which loads the repository and grows with the amount of change, and a chain that never closes.

A synthetic full is built from backup files that are already in the repository, so it puts no load on the production source, but it is heavy on the repository's I/O. An active full reads the whole source again: it takes longer and loads production, but it starts a new chain from freshly read data. Both close the chain, which is why forward-incremental schemes use one or the other on a schedule.

What does deduplication do, and how does it fit in?

Deduplication stores identical data once and refers to it from every place it occurs. Microsoft's documentation describes it as looking for duplicated portions of a dataset, storing them once and optionally compressing them. It works on chunks. Fixed-size chunks are simple, but one inserted byte shifts every chunk behind it; content-defined chunking picks boundaries from the data itself, so most chunks stay the same (FastCDC is a published algorithm for this).

How much it saves depends on the data. Microsoft's Windows Server documentation lists typical savings of 30 to 50 percent for user documents and 80 to 95 percent for virtualization libraries. Those are file-server figures, not backup figures, but they show how wide the spread is.

Incremental backup and deduplication solve different problems: incremental decides what the tool reads and sends, deduplication decides what the repository keeps. With a deduplicated store, restore points share chunks instead of depending on a chain. Each restore point is complete by itself, and any one can be removed without breaking the others, because the store counts references. The risk that remains is shared: a damaged chunk affects every restore point that uses it, so such a store needs integrity checks that read the data back.

What is changed block tracking?

Reading a whole disk to find what changed is slow. Hypervisors and storage layers can instead record which blocks changed since the last backup, which is called changed block tracking; QEMU calls its version a dirty bitmap, with a fixed granularity per bitmap. The backup then reads only those blocks. If the record is lost, for example because a transient bitmap is discarded when the QEMU process exits, which its documentation describes, the tool has to read the whole disk again.

Which type should I choose?

Choose by the constraint that bites first:

• Small data and simple restores: full backups on a schedule, or a weekly full with daily incrementals or differentials.
• Large data and a short window: incremental backup with change tracking, into a deduplicated store.
• Storage without deduplication: periodic full backups, active or synthetic, to keep chains short. A chain of hundreds of increments is a risk of its own.
• Let your recovery targets decide the schedule: how often a backup runs and how long it takes set how much data you can lose. See RPO and RTO explained.
• Whatever you choose, verify it. A chain or a chunk store is only as good as the last time it was read back; see how to prove that a backup can be restored. Where the repository lives matters as much: see choosing backup storage.

How Restow handles this

Restow does not ask you to choose a backup type. There is no full, incremental or differential setting and no periodic full job to schedule. What it does instead:

Deduplicated, encrypted chunks

Data is split into content-defined chunks (FastCDC, from 256 KiB to 4 MiB, about 1 MiB on average), each named by its hash, encrypted with AES-256-GCM under the tenant's key and packed into pack files of up to 64 MiB. Identical content is stored once across items and over time within a tenant, never across tenants. Each restore point lists the chunks it needs, so any restore point can be restored or removed on its own; the storage check's garbage collection removes chunks that no restore point uses. Because restore points share chunks, a damaged chunk can affect several of them, and the weekly and monthly storage checks exist to read for that. See storage.

Microsoft 365: incremental through delta queries

Exchange Online mail, calendar and contacts, and OneDrive, are backed up through Microsoft Graph delta queries, so a normal run fetches only what changed; the document libraries of SharePoint Online sites use the same delta approach as OneDrive. The first backup of a large tenant can take days because Microsoft throttles the Graph API. See Microsoft 365 and IMAP backup.

Servers and clients: restic

The agent for Linux and macOS backs up files with restic, which also deduplicates, into one repository per machine in the same storage target. It is file-based: there are no disk images or bare-metal restore yet (both are planned). See server and client backup.

File shares: incremental with restic, over a read-only mount

Restow backs up an SMB share or an NFS export without an agent on the file server. For the length of one run it mounts the share read-only and backs it up with restic into a repository of its own on the primary repository. That is incremental in the sense of this page: after the first run, files whose size or modification time changed are read again, and content that restic already stores is not stored a second time, so a normal run reads and stores only what changed. Every run still makes a restore point that stands on its own, so you never schedule a full backup. Open, unreadable and offline files are skipped and listed, and the run then ends with warnings. Like the agent, it is file-based: no disk image. See file shares (SMB and NFS).

Proxmox VE: changed 4 MiB blocks (a preview)

Proxmox VE backup is a preview in every edition, for Proxmox VE 8.4 and newer, and not yet recommended as your only backup. VM disks are read over NBD with dirty bitmaps, and only the changed 4 MiB blocks are read and uploaded; containers go through restic. Every restore point holds the full block map of each disk, so it works as a synthetic full: any restore point can be restored or removed on its own. After a VM stop and start, a stop-mode backup, a disk resize or move, or a backup of a powered-off VM, the whole disk is read again and only blocks whose hash changed are uploaded. Every 30th backup of a disk is a full read on purpose. A Proxmox VE job can also run a boot test (off by default): the node restores a restore point as a new, isolated guest, starts it and destroys it, which shows that the restore point boots but says nothing about the applications inside. See Proxmox VE backup.

Restow has no differential backups, no tape support and no scheduled active or synthetic full job.

Frequently asked questions

Sources

Read on 16 October 2026.

1. Veeam Best Practice Guide: Backup job methods. Forward incremental with synthetic or active fulls, forever forward incremental, and their trade-offs
2. Veeam Backup & Replication Quick Start Guide: Backup methods. Definitions of forever forward incremental, active full and synthetic full
3. Microsoft Learn: Differential backups (SQL Server). A differential backup is based on the last full backup and grows until the next one
4. Microsoft Learn: Data Deduplication overview (Windows Server). What deduplication is and typical savings by content type; the figures are for file servers
5. Xia, W. et al.: FastCDC: a fast and efficient content-defined chunking approach for data deduplication (USENIX ATC 2016). The chunking algorithm Restow uses
6. QEMU documentation: Dirty bitmaps and incremental backup. How a dirty bitmap marks changed regions and when it is lost
7. Microsoft Learn: Use delta query to track changes in Microsoft Graph data. How Microsoft Graph returns only what changed since the last request

Related articles

• Grandfather-father-son (GFS) rotation Daily, weekly, monthly and yearly restore points with a calendar example, how it differs from keeping every backup for N days, and how it maps from tape to disk and object storage.
• The 3-2-1 backup rule Three copies, two kinds of storage, one location apart, and the extension with an immutable copy and zero errors. With a worked Microsoft 365 example.
• Does Microsoft 365 back up your data? What Microsoft keeps, for how long (recycle bins, version history, retention), why retention is not a backup, and what Microsoft 365 Backup is.
• RPO and RTO explained The two recovery objectives as NIST and SNIA define them, how backup frequency and restore paths set them, a worked example and a small calculator.
• Choosing backup storage Local disk, NAS and NFS, S3-compatible object storage, tape and cloud archive tiers compared on cost, durability, immutability and restore speed.
• Backup glossary reference Short definitions of backup, restore and retention terms, from 3-2-1 rule to WORM, with links to the articles and features pages that go deeper.