Forward vs Reverse Incremental in Veeam: a practical comparison

1. The difference that matters

Forward keeps a full at the beginning of a chain and records later changes. Reverse keeps the latest state in a full and records rollback data. Both start with a full; subsequent incremental sessions transfer changed blocks rather than a fresh full image.

against official Veeam documentation. Starting with Backup & Replication 13, Reverse Incremental is deprecated; existing jobs with the option already enabled still work. Treat it as a legacy design, not a new deployment choice. This article describes VM backup chains; do not assume identical options for agents, NAS or direct object-storage workflows.

2. Where each method fits—and where to avoid it

The following choices are practical design inferences from the documented behavior. Validate them against your exact job type, repository capabilities and measured recovery requirements.

Scenario	Preferred choice	Reason / avoid
New Veeam 13 deployment	Forward with periodic fulls	Do not build a new design around deprecated Reverse
Immutable Linux Hardened Repository	Forward + Active or Synthetic Full	Reverse and Forever Forward cannot be selected
Slow or high-latency target	Usually Forward; evaluate full creation	Avoid Reverse without a measured capacity case
High change rate and concurrency	Usually Forward	Reverse read/write work can become a bottleneck
Limited space on a mutable disk repository	Evaluate Forever Forward	The retention merge must fit the backup window
Source or network cannot sustain frequent full reads	Evaluate Forward + Synthetic Full	Avoid frequent Active Full without capacity
Independent new reads from source are required	Forward + Active Full	Reserve time, bandwidth and storage
Existing Reverse job; fast target; latest recovery priority	Temporary continuation after review	Measure recovery and plan migration
Deduplication appliance	Follow device-specific Veeam guidance	Do not assume arbitrary random rewrites are efficient

3. Before selecting a backup method

Record the Veeam version, workload type, repository filesystem, immutability requirements, retention and daily change volume. Confirm whether Fast Clone is available. Reserve enough capacity for both retained chains and scheduled full operations.

4. Why incremental backups are useful

Repeated full backups consume source read capacity, network bandwidth and repository space. Incremental backups retain multiple restore points while transferring changes. CBT can identify changed blocks for supported VM backups. The chain method determines how those changes are stored and what restore depends on.

RPO is the acceptable amount of data loss and depends on successful backup frequency. RTO is the acceptable recovery time. Choosing Reverse does not automatically improve RPO; a short restore dependency does not guarantee meeting RTO without measuring an actual recovery.

5. Forward Incremental: restore moves forward

The first session writes a VBK full. Later sessions write VIB files with changes since the previous backup. To restore day 4 below, Veeam needs the day 1 VBK and the required day 2, 3 and 4 VIBs. Day 2 needs only the full and its first increment.

TEXT

Day 1: Full.vbk
Day 2: Changes.vib
Day 3: Changes.vib
Day 4: Changes.vib
Restore day 4: VBK + required VIBs through day 4

In Veeam terminology, Forward Incremental with periodic fulls creates a new chain whenever an Active or Synthetic Full is created. These shorter chains limit dependency on earlier chains. Restore reads the required backup blocks; it does not necessarily create a separate full file first.

6. Protect the recovery points

For an immutable Linux Hardened Repository, use Forward with periodic Active or Synthetic Full. Changing a chain method alone does not make backups immutable. Protect repository access and keep a separately protected copy; verify recovery rather than assuming that a full file is healthy.

7. Reverse Incremental: keep the latest full

After the initial full, each successful session injects new blocks into the VBK. Replaced old blocks are saved in VRB rollback files. The current full therefore represents the latest restore point. Older restore points require that full and the relevant reverse increments.

TEXT

After day 4:
Latest.vbk = day 4
Rollback VRBs = transitions to days 3, 2 and 1
Restore latest: VBK
Restore day 2: latest VBK + required VRBs back to day 2

Its historical attraction was a full for the latest recovery without reading the whole source daily. The cost is repository read/write work during each backup. Slow target storage can reduce throughput and extend the time VM snapshots remain open, especially with high change rates and concurrent jobs.

8. Side-by-side technical comparison

Criterion	Forward with periodic fulls	Reverse
Files	VBK + VIB	VBK + VRB
Full position	Beginning of each chain	Latest restore point
Incremental session	Write a new VIB	Update VBK and write VRB
Latest recovery	Base full + required VIBs	Latest VBK
Older recovery	Full for that chain + VIBs to target	Latest full + rollback VRBs
Daily repository work	Mostly new incremental writes	Read old blocks, write rollback and new blocks
Space pattern	Periodic fulls and overlapping chains	Current full plus reverse increments
Retention	Old chains remain until dependencies allow removal	Expired oldest reverse points can be removed
Immutable Hardened Repository	Supported with periodic Active or Synthetic Full	Cannot be selected
Veeam 13	Available for new designs	Deprecated; existing enabled jobs continue

These are dependency and workload differences, not fixed speed ratios. Restore time depends on storage, destination and restore type. Space also depends on change rate, compression and block sharing; a VRB is not guaranteed to have the same size as a VIB.

9. Active, Synthetic and Forever Forward

Method	How it works	Main cost or limitation
Active Full	Read the full backup data again from source	Source reads, network transfer and target writes
Synthetic Full	Build a full from existing repository backups	Repository processing; Fast Clone may reduce work
Forever Forward	One initial full; merge the oldest increment into it at retention	Merge I/O; unavailable on immutable Hardened Repository

Incremental selected without scheduled Active or Synthetic Full means Forever Forward. Its full advances to the oldest retained point, not to the latest point as in Reverse. This distinction matters when planning capacity and immutability.

10. Advantages and disadvantages

Method	Advantages	Disadvantages
Forward + periodic fulls	Clear chain structure; new files; periodic chain boundaries; hardened compatibility	Full storage and processing costs; dependent restore files; overlapping retention
Forever Forward	Fewer full files; no scheduled full source reads	Merge workload; mutable base; dependency on chain health; hardened restriction
Reverse	Latest recovery data is in one full; incremental source transfer	Target read/write pressure; old restores depend on VRBs; full changes each run; deprecated

A missing or corrupt required VIB can prevent dependent forward restores; earlier independent points may remain usable. A missing required VRB can prevent rollback through that transition while the latest full may remain usable. Corruption of a base/current full can affect many dependent points. None of these methods replaces integrity checks or a separate protected copy.

11. Retention and a capacity example

A retention setting of 14 points does not guarantee exactly 14 files or points on disk in Forward mode. A full cannot be removed while retained increments depend on it. Old chains may overlap a new chain until deletion is safe; immutability can delay removal further.

TEXT

Illustrative decimal units; stored Full = 1000 GB; each increment = 50 GB
1 full + 13 increments = 1000 + 13 * 50 = 1650 GB
2 fulls + 12 increments = 2 * 1000 + 12 * 50 = 2600 GB

This is file-volume arithmetic, not production sizing or a guarantee of physical consumption. Add room for chain overlap, full construction, maintenance and growth. ReFS/XFS Fast Clone can let synthetic fulls share blocks, so logical file sizes can exceed physical usage. Measure the actual stored increments and free-space peaks.

12. Diagnose backup and retention problems

Symptom	What to check
Backup slows down on Reverse	Target latency, IOPS, concurrent jobs and changed data volume
More points than configured	Chain dependencies, newer fulls and immutability expiry
Restore point cannot be read	Required VBK/VIB/VRB availability and health; test another protected copy
Synthetic Full is slow	Fast Clone availability and repository load during full construction

13. A practical selection checklist

Start a new deployment with Forward and periodic fulls. Choose the full type and schedule only after checking source capacity, target throughput, space and retention. For a mutable repository with tight capacity, compare Forever Forward and its merge time. Keep Reverse evaluation limited to existing jobs.

Before accepting the design, record backup duration, snapshot duration, repository latency and peak space. Restore both the latest and an older point, verify application data, and record recovery time. A successful backup job alone is not evidence that the required recovery works.

14. Choose for your recovery requirement

For new Veeam 13 designs, start with Forward and periodic fulls. Forever Forward is an alternative for suitable mutable repositories when merge performance and capacity justify it. Reverse remains a legacy-job consideration. Accept the design only after both recent and older recovery tests meet your requirements.

15. Frequently asked questions

Does Reverse download a full every day? No. Incremental runs transfer changes and update the stored full. Does it always restore faster? The latest point has fewer file dependencies, but measured end-to-end performance determines the result.

Is Forever Forward the same as Reverse? No. Its retention merge advances the oldest retained full, while Reverse updates the full to the newest state. Can either be selected for an immutable Hardened Repository? No; use Forward with periodic Active or Synthetic Full according to Veeam requirements.