best practice or deduplication

[billeuze]

Case ID: 03947000

Somehow I ended up with a backup job that some VMs have a block size of 1024 but one is set to 512 which results in a failure of the copy job for the one VM that is set to 512. So now that I have to make all VMs in the job the same block size, it is a good time to ensure all settings optimal for our environment.

My challenge is to come up with the best settings that work for us in our combination of target repositories , backup jobs and copy jobs. As far as I can see, different compression levels can be set for each backup, or copy job. But the block size is determined in the backup job and cannot be changed for the copy job. This means the block size will have to be a compromise since some copy jobs are going to different repositories with different settings. Based on the the link given to me in our support case: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4 and on the following depuplication article https://www.veeam.com/blog/data-dedupli ... veeam.html, I believe it is best to change all VMs to use block size of 512. And that is what I thought I did months ago when I changed the setting in the job from "Local Target" to "LAN Target". But what I am learning from the support case I opened based on what happened when I added a new VM to the backup job, this setting change only applies to VMs added AFTER the change, it did not change backups for VMs that were already in the config.

The summary is: backups go to local storage, NTFS with windows depulication. One backup copy goes to a locally hosted portable USB connected disk (formatted NTFS without windows deduplication). The other backup goes over a 600Mbps networkwork link to a remote repository (NTFS with windows depulication). I'm wondering if I should change any of the settings of my backup and copy jobs which can be seen below.

Details are:

Backup Repository: Local storage (local to the vmware server) hosted on the same VM which is the B&R server. Filesystem is NTFS with deduplication formatted with FRS of 4096 and cluster size of 64Kb according to Veeam recommendations for NTFS dudup here: https://www.veeam.com/kb2023.

Backup Job config:
- all 6 VMs reside on the same vmware host (the one serving the repository)
- Forward incremental with weekly synthetic fulls
- inline data deduplication enabled
- Compression level set to "Dedupe-Friendly" (I am really not clear on if I should use "None" or "Dedupe-Friendly")
- Storage Optimization set to "Lan Target"

Copy job config (this is the copy job that fails):
- Copies to portable USB disk attached to the same VMware host and served through the B&R server. Data duplication not enabled on this disk so formatted with windows default settings (FRS of 1025 and cluster size of 4Kb)
- inline data deduplication enabled
- Compression level set to "Auto"

Archive copy job (this job does not fail like the above one does) - this is a second copy job where we retain Annual, Quarterly. Monthly and weekly backups
- Copies to repository on another vmware host on another LAN segment (with 600Mbps link connecting the 2 networks). This repository is identical to the backup repository: local to host, NTFS, FRS of 4096 and 64Kb clusters, MS dedup enabled.
- inline data deduplication enabled
- Compression level set to "Auto"

[HannesK]

Hello,
I did not find a "?", but let me give give you a few recommendations and explanations

1) keep the default settings. there are only very rare use cases where it makes sense to change the block size.
2) if you change the block size, then you need to to an active full to apply it to old backup chains
3) if you go with (Windows) deduplication (which I personally don't like because I have seen to many issues with 2012R2), then you can go with none or dedupe-friendly. You can also use the "decompress backup data" repository setting
4) obviously you are not doing active fulls (otherwise you would not have the block size issue). so I would not use Windows deduplication anymore. I would switch to REFS with Server 2016 /2019

In the end, it's not really relevant where you decompress or which block-size you use. From my point of view, it's not worth thinking about that (especially in small environments)

Best regards,
Hannes

[billeuze]

Hi HannesK

Thanks for your input

Sorry the question wasn't more obvious, It was" I'm wondering if I should change any of the settings of my backup and copy jobs which can be seen below."

And yes I have now learned from the help desk that I have to do an active full in order for the config changes to take effect.

When I originally set up this backup job, I had set it to weekly active fulls because I though that active fulls were a safer bet than synthetic. Then I read somewhere (I think in Gostev's weekly email notice) that almost no-one uses active full backup anymore and it is really not needed because the synthetic backups are just as good (but quicker to run). I am now questioning this. What do you (and others think) about active vs synthetic?

[foggy]

Hi Bill, provided you verify your backups and your target storage is capable of synthetic activity in terms of performance, you do not need active fulls. Here's a good reading on that.