Veeam backup time: Full vs Reversed incremental

[collinp]

I am backing up 23 vm's in our Hyper-v environment using Reverse incrementals, using a network backup. My backup is 6TB and it deduped/compressed 18 to 1. The full transfer size was 301GB. The next night was an incremental and its transfer size was 15.9GB. The backup time for each night was the same, 10 hours. Is that normal? I was thinking that the incremental would take less time to backup.

[Gostev]

I am backing up 23 vm's in our Hyper-v environment using Reverse incrementals, using a network backup. My backup is 6TB and it deduped/compressed 18 to 1. The full transfer size was 301GB.

Nice data reduction ratio

I was thinking that the incremental would take less time to backup.

That is correct, incremental backup always take considerably less time than full backup, however you said you are using *reversed* incremental backup mode, not regular incremental - and that makes huge difference!

Reversed incremental can indeed take the same time as full backup if your target storage has poor IOPS. Remember that reversed incremental backup requires 3x more I/O per block comparing to full backup, and it is random I/O versus sequential writes in case of full backup. That's the price you pay for low disk space usage that reversed incremental backup mode provides, it has to do all this extra processing to let you stay with a single full backup file. If you want fast incremental backup with slow target storage, change your backup mode to incremental instead. The price for the speed increase is the extra disk space requirement from having to store multiple full backups... nothing comes for free, you know

Here is the outline of I/O operations for different backup modes:

Incremental backup = 1x I/O on target (write for each changed block)
Reversed incremental backup = 3x I/O on target (write + read + write for each changed block)

Active (real) full backup = 1x I/O on target (write for each block)
Synthetic full backup for incremental backup mode = 2x I/O on target (read + write for each block)
Synthetic full backup for incremental backup mode with transform = 4x I/O on target (read + write + read + write for each block)

You may also want to review the sticky FAQ topic for the complete list of considerations how all backup modes compare to each other (factors like performance, disk space required, etc.)

[collinp]

I was shocked at the 18 to 1 dedup/compression. I am backing up twice as much vm's and data in our vmware environment and we are getting 5 to 1 dedup/compression. BTW, the vmware backups finish in half the time as the hyper-v backups. However, I am doing SAN backups in the vmware environment which may not dedup as well and is probably faster.

[Gostev]

Well, I am guessing all of your VMs in Hyper-V environment are very similar (same OS, and may be all made from the same template). While on VMware side, you may have a number of different OSes and templates...

[zoltank]

I've found when I do a Active Full backup I get a throughput of about 45mb/s, but when I'm doing reverse incremental I get a throughput of about 10-15mb/s. Is this normal behavioral, or is there a a problem I need to find?

I'm currently using network as my transport mode for my backup proxy.

EDIT: When I'm doing a Active Full backup the primary bottleneck by a large margin is the source, and when I'm doing the Reverse Incremental the primary bottleneck is the target by a large margin.

[Gostev]

1x I/O per block vs. 3x I/O per block

[zoltank]

Would the throughput drop as the backup job gets larger?

[foggy]

Yes, if this implies larger amount of changes to be processed.

[jbarrow.viracoribt]

Do you have these data throughput numbers (which were really handy) for a backup copy job type data transfers?

[foggy]

Backup copy job transformation does 2x I/O operations on target.

[jbarrow.viracoribt]

So why not just run an Active Full or Incremental backup which is only 1x I/O on target?

That would seem faster.

What am I missing?

[foggy]

To avoid touching production VMs twice, for example. There are also other considerations.

[jbarrow.viracoribt]

I love you guys. Best forum support in the industry. Just sayin'.