Switch from reverse incremental to forever forward incremental

[LKLD]

Hello guys,

we are currently planning to switch from reverse incremental to forever forward incremental since we have some performance issues regarding our backup process.
We hope to get some performance improvements by using the forward incremental variant.
Our problem is, that we can't go for active- or synthetic full backups, because we dont have the space on our NAS to store 2 full backups instead of one of each VM and using retention periods results in no other way than having at least 2 full backups of a VM when u want to go for periodic synthetic or full backups because the old full backup can only be deleted through the retention policy, when the new full backup covers the whole retention policy. Or am I wrong and there is an other way?

So the only available option would be to use forever forward, since u only have this one full and all the increments afterwards. Once a week we perform a Backup to Tape job, which synthesizes a full backup and copies it to the tape. Most of our jobs have a retention period of 14 days, but two of our jobs have one of 60 days. The problem is, that this synthetic full for the tape job has to create this synthetic full out of one full backup and 60 increments. Is there a huge performance problem regarding this and comparing it to reverse incremental, which has the full backup always at the most recent date?
It seems to me, that reverse incremental has a huge advantage in such a situation compared to incremental, because the job doesnt have to build a synthetic our of 60 increments. Or isnt this process as bad as I am thinking it is?

We are currently still on Veeam 11, but planning to upgrade promptly.

Best wishes

[david.domask]

Hi Landkreis,

1. using retention periods results in no other way than having at least 2 full backups of a VM when u want to go for periodic synthetic or full backups because the old full backup can only be deleted through the retention policy, when the new full backup covers the whole retention policy. Or am I wrong and there is an other way?

Correct, with periodic full backups, retention will behave as outlined in this KB article, and only inactive chains will be removed by retention.

2. The problem is, that this synthetic full for the tape job has to create this synthetic full out of one full backup and 60 increments. Is there a huge performance problem regarding this and comparing it to reverse incremental, which has the full backup always at the most recent date?

The Virtual Full process is fairly fast and works by first creating a "map" of what blocks from each backup file are needed to create a virtual full on tape, and these are read asynchronously for pretty fast Virtual Full creation. This process means that likely not all 60 points (in your example) would necessarily be "touched" for Virtual Full creation, and I suspect you should be able to do this without any major issues, but I would do some testing first as this will be very dependent on the environment. I imagine the NAS will be the bottleneck here, but it may not be the case, so give it a shot with a test job -- the Virtual Full process remains the best and fastest way to get full backups on tape; in v10 we did a fairly major overhaul to the Virtual Full process and saw very impressive results for many clients, so I expect it will not be as bad as you're imagining, but again this depends heavily on the environment.

[LKLD]

Thanks alot for the input David!

U stated, the virtual full process remains the best and fastest way to get full backups on tape. But Reverse incremental would still be faster, right?

Can u confirm that using forever forward incremental is - generally speaking - better regarding performance compared to reverse incremental? The problem is that, as I already mentioned, we are struggling with some performance problems, since our backups take a pretty large amount of time. We are hoping, that we get some improvements with forever forward incremental.

[david.domask]

You're very welcome, happy to shed light on this.

In general Virtual Fulls will be faster; environmental factors may sometimes give an edge to the direct copy of a full backup from disk to tape, but from my experience with many clients and Support cases, Virtual Fulls always had a lead over normal full copies. Fulls are still pretty fast, but Virtual Fulls typically will be faster without needing additional space on disk.

Regrettably, with performance, it usually comes down to environmental factors and will be fairly specific to each environment, so it's best to start with just a test to establish a base line. Our KB article for simulating Veeam IO patterns with Diskspd and fio has a few tests you might run towards the repository. I think use the Restore parameters as our goal is to simulate random read. Then you can try it without the -r flag and compare, and that will give you some understanding of the performance. This won't be a 1:1 test, so expect some variance between the test and the actual backup performance, but it will give you an idea of possible performance.