IO profile of backup modes

[ChrisGundry]

Hi There,

I was wondering if someone could clarify something for me. We have some slow BCJ's and also primary jobs. I think this is to do with our backup storage and I am looking at options now but I would like to clarify the below as well.

I have been doing a lot of reading about different backup modes and their IO profiles. A lot of what I read references the amount of time and data that builds up on a VM snapshot during the backup and keeping that time to a minimum, but at the cost of later time/IO on the backup storage after the actual backup process on the live VM has finished.

We are using storage snapshots, so the time the VM snapshot is in place is not as much of a concern to us. We want to get:
1. The fastest overall backup we can. Overall being complete start->finish time
2. The latest backup being a full for easy/quick restores, ability to use Veeam extract tool if needed (or a good reason to not have a latest full)
3. We use backup copy jobs from our main backups, so if any particular mode has an affect on the BCJ I would be interested to know

Many thanks

Chris

[foggy]

Chris, have you reviewed bottleneck stats for those "slow" jobs? That is always the first step in job performance troubleshooting.

[foggy]

That said, depends on the chain length, however chances are you will not notice difference in restore times if comparing restore from an increment and a full backup.

Backup method of the source backup job doesn't also play much of a role.

[ChrisGundry]

Foggy,
I have and most of our jobs have the bottleneck of target.
Source 58%
Proxy 7%
Network 38%
Target 64%

Another was:
35%
6%
24%
78%

Our source backup job chains are very short, only 7 days. Then several backup copy job retain 5 weekly & 3 monthly points. Another copy job takes the whole lot offsite to our DR location.

My logic was as follows given a 7 day rolling backup window:
Forward incremental: Full initial backup, incremental, incremental, incremental, incremental, incremental, incremental. On the 8th day the first incremental was rolled into the full backup file. So that uses 1 read and 1 write to 'fold' it into the full backup. The whole time we don't have a full backup as the latest backup.

Reverse incremental: Reverse of above.

So to me it didn't make much odds either way and by using reverse incremental we don't run the risk of having the latest restore point not being a full and having an issue with the interim incremental backup points etc.

Thanks

Chris

[foggy]

Both are actually 3 IOPS per block, though forever forward does 2 of them after the backup.