Reverse Incremental time to complete increasing significantl

[michaelryancook]

I am not sure if this is something that I should make a support call for or not. I'm looking for some advice on whether this sounds normal or not. I have done some reading on similar questions but I'm still not clear. My first backup in a reverse incremental chain took 1 hour 45 minutes. Two weeks later my incremental is taking 10 hours 30 minutes. Each day the time has steadily increased. I understand there is a transform process each day to merge the last .vbk and that days incremental to create a new .vbk and .vrb. As my .vrb file size and compression are staying rather static from one day to the next I would have assumed day 2 and day 14 would have similar overhead and processing times. Does this increase seem odd and worthy of a support call? I have tried changing the compression and optimization to see if that was the cause but there has been little change.

[fix-all-the-things]

Look back at your history and see if your bottleneck has changed. If your early jobs said the majority of the load was on the source, and now it says target, then that will give you an idea of where to look for problems. There's a lot of parts involved in making a backup so it's really hard to give suggestions without more info. Your best bet is to do a log dump through Veeam and let support look at it to see if they spot anything obvious.

[veremin]

If target is always apart (from initial run) identified as a major bottleneck, it will mean that target storage can't handle the random I/O well, and you might be in better shape, if you stick to either forward forever incremental or forward incremental with regular active full backup mode. Thanks.

[michaelryancook]

Thanks for the replies. I was worried this was the case as target is showing as the bottleneck. We are going to 24 * 10K SAS drives local to the Veeam B&R server. We had started with forward incremental with regular active full but when we had called in on a support issue we were told our backup chain was too long. This was causing surebackup issues where jobs timed out. Reverse incremental was working well for us for about a week and was very convenient for restores or surebackup jobs.

[veremin]

We had started with forward incremental with regular active full but when we had called in on a support issue we were told our backup chain was too long.

What did they mean by saying "the chain is too long"? As long as you perform full backups on regular basis, you're in good shape. Thanks.

[michaelryancook]

Sorry for the slow reply. We were performing monthly active full backups. The issue with the chain being too long was that our one repository was on server with 1 GBe NICs which caused SureBackup jobs to timeout. If we tried a restore point near the start of the chain it was fine. If we moved the chain to another repository with 10 GBe NICs we could use any restore point. Unfortunately we do not have enough space for weekly active full backups but we plan on replacing the 1 GBe NICs soon.