The backup method determines the order and type of files in the chain and therefore the I/O pattern on the repository and the speed of restores to different points.
In v12 you could select Reverse incremental for a job; in v13 the option is deprecated and cannot be selected for new jobs, although jobs created earlier with reverse incremental keep working after the upgrade. Figure 5.1 shows where the full sits in each chain.
| Method | Chain | How you get it | Storage use | Repository I/O | Fastest restore |
|---|---|---|---|---|---|
| Forward incremental (FI) | Several VBKs, each followed by VIBs | Enable synthetic full and/or active full (synthetic full enabled is the default) | Highest; can hold more points than retention | Lowest, with peaks on synthetic full days (repository) and active full days (production) | Generally best for points that are neither earliest nor latest; documented as the most reliable |
| Forever forward incremental (FFI) | One VBK followed by VIBs | Disable both synthetic and active full | Low: one full | Moderate: oldest increment merged into the full; needs compact | Earliest point (always a full) |
| Reverse incremental (RI), deprecated | One VBK (latest) preceded by VRBs | Only existing pre-v13 jobs | Low | Heaviest: changed blocks injected into the full plus VRB written each run | Latest point (always a full) |
Active full and synthetic full
| Active full | Synthetic full | |
|---|---|---|
| Data source | Whole VM read from the source datastore | Built on the repository from existing full and incrementals |
| Load | Production storage and network | Backup repository only; no network use |
| Effect on chain | Resets the chain; new increments depend on it | Same: treated as a regular full and resets the chain |
| Schedule | Weekly or monthly; can also be run manually | Weekly on chosen days |
| Object storage target | Supported | Not created independently; enable GFS to include synthetic fulls |
On a synthetic full day the session first runs a normal incremental from production, then the repository Data Mover builds the new VBK and deletes that temporary incremental. Each kind of full is produced once on its day (a second run is an ordinary incremental), even on days the regular schedule would skip, and replaces that day’s incremental.
Fast Clone makes synthetic operations cheap by referencing existing blocks instead of copying them. It works on Linux (XFS with reflink), Windows and SMB (ReFS block cloning) repositories and on several deduplicating appliances, and is used to merge files, create synthetic and GFS fulls, transform reverse incremental chains and compact full files. After moving chains manually to a Fast Clone repository, run an active full (or a compact) to start using it; Veeam move and copy features do not need that. On Windows repositories, Fast Clone and Windows data deduplication cannot be used together. Repository-side details are in Chapter 7: Repositories: hardened, immutable, object storage and scale-out.
Switching methods
Switching methods never transforms the old chain; a new chain grows next to it. From FFI to FI, synthetic fulls start on schedule and the old chain is deleted when the new one reaches the retention limit. From FI to FFI, synthetic fulls stop; once enough points exist since the last full, the old chain goes and the earliest increment starts merging into the full each run.
Common trap: Scheduling active and synthetic full on the same day to “be safe” - only the active full is created; the synthetic full is skipped.
Common trap: Chaining a job with After this job and scheduling fulls on it - if the initial job does not run on the full day, neither active nor synthetic fulls are created for the chained job.