Block size question

[ferrus]

I finally have an opportunity to reset the blocksize on our Veeam backups - with Active Fulls.
At the moment, they are still set to the same settings that followed the v8->v9 upgrade - Legacy 8MB

I've read the guides for block size recommendations, but they do seem to contradict sometimes.

Could someone advise the best setting for our infrastructure:

Backup Jobs to RAID 6 DAS
Backup Copy Jobs to EMC Data Domain
Replication Jobs across 1Gbps WAN

Not limited at all by CPU, Memory or Backup Window - but free capacity on the RAID 6 is low, and Instant Restore performance is quite poor

Because of the Backup Copy Jobs to DataDomain - we haven't enabled DeDuplication on the Source Backup Jobs. Does block size even help with disk space, if this is the case?

All jobs were left at Local 16+TB at install - but apart from the recommendation that this mathches the DataDomain well - I don't understand the benefit of it.
DD's use there own block size regardless of this setting, I think.

[foggy]

Backup copy jobs have their own inline deduplication/compression settings, so you can have them enabled in the original backup jobs. Block size affects consumed disk space regardless of whether inline deduplication is enabled or not (the smaller the block size, the less space is required to keep changes and higher dedupe rate).

The block size change for the "Local 16+TB" setting was intended right to improve performance of recovery scenarios that involve random I/O (like Instant Recovery), so definitely worth a try.

[ferrus]

Thanks

So I could turn on deduplication on the Tier1 DAS storage - without a negative effect on the Tier2 Datadomain copy?

Between Local 16TB+ and Local, which would you expect to be better in this environment?
I believe that the Backup and Backup Copy setting should match, so it should be one that works best for both?

[foggy]

So I could turn on deduplication on the Tier1 DAS storage - without a negative effect on the Tier2 Datadomain copy?

Correct. Just don't forget to disable it in the backup copy.

Between Local 16TB+ and Local, which would you expect to be better in this environment?
I believe that the Backup and Backup Copy setting should match, so it should be one that works best for both?

Correct. Worth trying both to see which one works better on average. Or think of which backup storage is involved in restores more frequently or has lower RTO, since 'Local target' is good for your primary backup storage and 'Local 16TB+' for secondary.

[Gostev]

Block size does not make any difference with Data Domain as backups land there uncompressed, and any recovery process will read only the required data instead of the entire block surrounding the needed bits. In fact, we did the latter until v9, and it was REALLY slowing down performance of all restores, especially with large Veeam block sizes.

[rnt-guy]

So should in-line dedupe be disabled on copy job to the DD but left enabled on the backup job to tier1 storage?

[PTide]

So should in-line dedupe be disabled on copy job to the DD but left enabled on the backup job to tier1 storage?

Yes.

[foggy]

As for the block size, not all types of restore read data granularly, for example, full VM restore will benefit from a larger block, as well as all synthetic operations. Besides, smaller block implies more metadata, which also can affect performance.

[rntguy]

Yes.

Forgot to ask why if the goal is to send it the fastest and use least amount of space on the copy job dd?

If destination dd has 'decompress data blocks before storing ' checked how does inline dedupe hurt on the copy job?

[foggy]

Inline dedupe and compression are different data reduction techniques, decompression doesn't mean the data will be rehydrated (i.e. similar blocks from different VM disks will stay deduped with decompression setting enabled).