Hello,
is
still the thread to read when trying to decide which backup-mode we want to employ? 1 VM is a large file server with ~6-8TB where all other VMs are smaller application servers (~250GB).
BR
Frank
Page 1 / 1
I think this thread is a good reference, but you should see the helpcenter for version 11, too.
There are some new requirements with immutability and hardened repositories.
Will have to look for these links….
In terms of Reverse Incremental vs (Forever) Forward Incremental, your concerns are always:
- Performance: Reverse incremental has highest performance requirements on the target repository
- Secondary Features as Joe mentioned like Hardened Repositories and offloading
In the past, Reverse was the way to go for fast restores because the most recent point was always a full, but a lot has changed with the restore engine in past years, and now you ought get pretty good performance regardless of the restore mode.
If restore performance is your only consideration, I’d strongly weigh that (now less impactful) benefit against the benefits of hardened repositories, the performance cost on the target repository for backups, and simplicity of offloads.
* Harden (immutable) backup chains must be Forward Incremental: https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository_limitations.html?ver=110#limitations-for-repositories
* Move mode will never “move” the full backup from Performance tier, only the reverse-increments: https://helpcenter.veeam.com/docs/backup/vsphere/capacity_tier_inactive_backup_chain.html?ver=110
When you see at the details of some feature-implementations you will see, forward incremental should be the preferred option. From my point of view there are very less situations were I would prefer reverse incremental jobs. For example: Full to Tape every day.
BTW: for hardened Repos you need forward incremental with periodic fulls. Forward forever is not working here.
Another point depending on your repository OS - NTFS vs ReFS vs XFS will determine selection here. I stay away from reverse incremental and I believe in a future release it will be deprecated. I always go with the Forward and then depending on the file system select the synthetic or even active full.
I have not much to add here. If you don't have any special requirement or don't know why to use reverse incremental, then you probably shouldn't need to use it 
And just like
Just to add to this, you’ll get better IO efficiency with forward incremental vs reverse.
With a forward incremental backup, each incremental costs 1 Read IO from Production storage and 1 Write IO to backup storage, with 2 Backup IO for synthetic full backups (1 read + 1 write to backup storage).
With reverse incremental each incremental costs 1 Read IO from Production storage just the same but three IO to the backup storage (One initial write of the new data, then one read of the older blocks that need to be placed into a reverse incremental file, and finally one more write to insert into the reverse incremental file)
Just to add to this, you’ll get better IO efficiency with forward incremental vs reverse.
With a forward incremental backup, each incremental costs 1 Read IO from Production storage and 1 Write IO to backup storage, with 2 Backup IO for synthetic full backups (1 read + 1 write to backup storage).
With reverse incremental each incremental costs 1 Read IO from Production storage just the same but three IO to the backup storage (One initial write of the new data, then one read of the older blocks that need to be placed into a reverse incremental file, and finally one more write to insert into the reverse incremental file)
Yes performance is a big factor as mentioned here too with selection. 
“Forward”. That and only that. Primarly for performance. Secondly it’s more “natural” for my brain the forward scheme backup.
At this point, if your needs are something like RPO 24 hours, 150 days and only one full backup, then perhaps you should go with reverse incremental. The risk otherwise is you would need to go far back in time for a restore if even one incremental is corrupted/broken.
Generally, if you are using servers with direct attached storage, you should be using ReFS on Windows or XFS on Linux and in that case I would recommend to use forward incremental with synthetic full backups.
This will offer you the best of all worlds and as also mentioned by others, you can use immutability if you decide that repository is running Linux (don’t forget to add it as a hardened repository).
alongside forward or reverse.
In the past, Reverse was the way to go for fast restores because the most recent point was always a full, but a lot has changed with the restore engine in past years, and now you ought get pretty good performance regardless of the restore mode.
This implies that restores from a forward incremental chain required reading from all incremental backup files which is not the case. Due to the meta-data (VBM) file(s) Veeam can see which blocks are needed and read only those blocks from only the files containing those blocks. There was a thread on the Veeam subreddit years back where Gostev explained that restore performance from reverse was not higher than forward because of the explanation I just provided.
Comment
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.