Forever Forward - Implication on Backup Copy?

[andreash]

Hi,

we are planning to upgrade to v8 once the Endpoint Backup integration is available.

One of my jobs is a single 2.6TB VM on 21 day Reverse Incremental with Backup Copy Jobs set to run every day and GFS of 4 weeks, 6 months.
With the upgrade I'm looking into options to speed up the Copy Jobs, which run several hours currently.

Basically there are two time consuming parts:
1. process the copy from Daily Backups to the Backup Copy Destination
- this is limited by the source. We'll add more disks to the RAID10 here
- maybe changing to Forever Forward will improve this as well? See below for my thoughts.

2. GFS Transformation
- limited by the IOPS of the storage. Little to do other than adding more disks.

Would changing to Forever Forward have an implication on the copy from Daily to the Backup Copy Destination?
Currently it has to read a (probably) badly fragmented file from the Source, which should explain the 100% utilisation we see. With Forever Forward it should only process the last incremental, which should be a file with very little fragmentation.

Any toughts on this?

Regards,
Andreas

[veremin]

The method used by source backup job should not matter. What about major bottleneck identified in backup copy job sessions? Is it really source? I'm wondering because in most cases the major bottleneck in backup copy job scenario is target and applying changes to "source" site would not speed things up. Thanks.

[andreash]

Hi Vladimir,
thanks for the quick reply!

This is from last Mondays Copy Job:
Processing Rate: 58MB/s
Bottleneck: Source
Processed: 405,9 GB
Transferred_ 154 GB

Transfer from Source to Backup Copy Repository is 2 hours, with 58MB/s
GFS transformation is 2.5 hours (which is rather quick compared to other days)

I guess the Bottleneck does only report for the transfer from Source to Target?
The "real" bottleneck surely is the Target during GFS transform, which can take anywhere between 2 and 8 hours.

Source is 4x4TB in RAID10, connected over iSCSI on 3x1GBit links.
Destination is 7x4TB in RAID5. I can't change this to RAID10 for number of disks, and so far the speed is acceptable.

My thoughts basically were related to the files the Copy Job has to read. Instead of collecting the blocks from the fragmented vbk on a Reverse Incremental it seems logical that getting the data from a vib would be "easier" for veeam and the storage.

Regards,
Andreas

[foggy]

I guess the Bottleneck does only report for the transfer from Source to Target?
The "real" bottleneck surely is the Target during GFS transform, which can take anywhere between 2 and 8 hours.

Correct, backup copy job transformation activity is not counted in the bottleneck stats.

Source is 4x4TB in RAID10, connected over iSCSI on 3x1GBit links.
Destination is 7x4TB in RAID5. I can't change this to RAID10 for number of disks, and so far the speed is acceptable.

RAID10 is indeed more preferable for the target storage, due to less I/O penalty.

My thoughts basically were related to the files the Copy Job has to read. Instead of collecting the blocks from the fragmented vbk on a Reverse Incremental it seems logical that getting the data from a vib would be "easier" for veeam and the storage.

You're correct that forward incremental is a better source for backup copy in terms of performance, so worth trying.