@SysEng - Reverse does save space, but is the worst performance-wise. If memory serves...it uses 4 synthetic operations to finalize processing? (I’ll try to research and confirm) Best performance is Fwd Increm as no transform operations occur because you run an occasional Full which starts a new Active chain. Downside is..yes...space issue. Couple that with immutability if you have that enabled and space does become an issue. Immutability will cause space issues regardless of Backup Method actually because the immutable retention timer doesn’t start until after the *last* backup file in an Active Chain is reached. You can see how that can cause space issues there. Forever Fwd is pretty much a combo of the other 2. There are transform operations to merge the Full with the oldest increment to “move” the Full forward each day after the Retention period is met. It has decent speed. But, what you configure Retention-wise is what you get.

For immutability, you can only use Fwd Incremental. And, I’ve heard through the grapevine, but nothing official, Reverse is going away. So, those are some things to crunch on to decide what’s best for your environment.

Let me know if you have further questions.

One of the best space savings is XFS (Linux) and ReFS (Windows) for your repos.  You can then use the block cloning and change your job types to Incremental with Synthetic fulls, etc.  Something to also think about.

Yes! Great share @Chris.Childerhose ! This will significantly reduce the size of any extra Fulls on disk, saving a good deal of space @SysEng . And, it helps a bit with backup performance. You can read more on it here:

https://helpcenter.veeam.com/docs/backup/vsphere/backup_repository_block_cloning.html?ver=120

As I use this feature within Linux on a XFS filesystem in my environment, and talked a little bit about it in my VeeamON Linux session back in June, let me know if you have any questions on this.

I think revers is 3 operations vs 1 with forward.. Forever forward is the best method in my opinion. I believe Chris is right too about reverse going away as you get warnings if you try to use it. 

Well, I shared that..but all good 

I wasn’t aware about the warnings thing. Interesting. Fun history fact..history, meaning my Veeam usage history → Reverse was the 1st Method I used in my environment cuz it was simple and the latest is always a Full. No other reason (newbie ).

My bad. @coolsport00 shared it :)

I forget exactly when it happened, either during the last upgrade, modifying a job, or a copy job. I had a warning pop up about Reverse Incremental being depricated in future versions or something along that line as I have a few jobs still running it. I’m working at getting them all FFI but some are too big to allow the chain to extend forward.  I have new storage and FC switches, but am waiting on some servers to arrive in the next few weeks for Repos/proxies etc. 

Ah, ok. Thanks Scott. Just FYI...if you at some point go with Immutability-based Repos, you can only use Fwd.

What i am seeing is the every VBK is consuming actual full backup worth of space and filling your drive.

Great time to convert them then. Considering Linux repos. still need to do some testing and research though. 

Wow, sadly no linux options available, only windows smb.

Then start using the Fast Clone feature @SysEng . The space used will literally be negligible. 

And, I’d use Synthetic Fulls for the Fulls and not Active Fulls.

Then you can use ReFS. This filesystem enables “block cloning”, as mentioned in the above link I shared discussing Fast Clone.

Transform in to rollups was the warning. Not reverse incremental. Too much thinking today

Ok, thanks for clarifying Scott 

My question to CHATGPT - “Basically, reverse incremental in veeam saves space by injecting everything into one vbk file maintained instead creating multiple vbk and vib files for one backup job?”

I think AI is SCARY LOL. 

Response from ChatGPT below:

Yes, that's correct! The reverse incremental backup method helps save space and simplify backup management by maintaining a single VBK (full backup) file and a series of incremental changes.

Here’s how it works:

1. Initial Full Backup: The first time you run a reverse incremental backup job, Veeam creates a full VBK file.

2. Subsequent Incremental Backups: Each subsequent backup job only contains the changes (incremental) since the last backup. These incremental changes are applied to the VBK file, effectively updating the full backup with the latest changes.

3. Reverse Incremental Changes: Instead of creating multiple VBK files, Veeam writes changes into the existing VBK file, preserving the state of the data at each backup point. This approach keeps the backup chain manageable.

4. Space Efficiency: By maintaining a single VBK file and applying changes to it, you reduce the need for multiple full backup files and associated incrementals, which saves storage space.

5. Restore Flexibility: This method allows for quick and flexible restores since the most recent VBK file always represents the latest state of the data, and previous states are also preserved within the VBK.

Overall, reverse incremental backups are efficient in terms of both storage and management, as they eliminate the need for numerous VBK and VIB files while still providing robust backup and restore capabilities.

Do you agree with AI, today at least?

@SysEng - Reverse is essentially FFwd, but in reverse. 

I just ran a fw reverse incr, and i tell you, record time, everything/most recent injected into the vbk and created a vrb and wow. Let me see how best this works then update you guys. Will do some test restores from the vrb.

interesting one will be doing a restore beyond the most recent reverse full backup file