Server 2019 ReFS and Windows Deduplication

[DonZoomik]

Veeam dedupe doesn't realistically matter that much as it uses much larger blocks than Windows dedupe (eg it doesn't disturb Windows dedupe). It may help to squeeze file size down a bit to fit in 4TB limit so you may keep it enabled. However you should definitely disable Veeam compression. See here for comparison: https://www.craigrodgers.co.uk/index.ph ... on-part-3/

This registry key enables block clones for deduplicated ReFS volumes. Again, it doesn't realistically matter in most cases as deduplicated data is not actually block cloned. You can find it in some release notes and searching the forum for previous threads about deduplication and ReFS, I'm going to leave that task to you.

There are a million ways to create unsupported/non-recommended scenarios. That's why pretty much any vendor will publish recommendations and best practices - simply because there are a whole lot less of them. If you don't find your scenario in one of recommended or explicitly documented ones, you should really take a hard look at your design (any maybe ask for external help).

You can also treat this repository as a dedupe appliance. For that scenario there's recommendations (3rd party though): https://bp.veeam.com/vbr/VBP/3_Build_st ... ation.html Just make sure you understand the how Veeam's components interact in this scenario, before blindly editing configurations.

Edit: Old version also has some Windows dedupe information: https://old.veeambp.com/repository_serv ... pe_windows Some of it is specific to NTFS though and some are 2012 specific.

[matt.burnette]

Has anyone had any issues with corruption occurring on their ReFS deduplicated volumes?
We are a cloud connect provider and we recently had a couple chunks go corrupt on one of our 2019 repositories, though those chunks where referenced by about 95% of the backup files on that volume.
This was about 170TBs and years of backup data gone overnight as ReFS, Storage Spaces, Dedup Scrubbing, Integrity checks etc were unable to repair the corrupt chunks.

I just opened a Microsoft case for root cause to see what happened, though wanted to see if anyone else had seen this issue.

[PM_ME_UR_MANPAGES]

Currently remaking our backup jobs and I have a requirement from mgmt to keep archival backups available for years.

Looking to do one month of daily forward incremental restore points with weekly synthetic fulls. Then monthly active fulls for a year and yearly active fulls for 7 years.

Can I enable Dedup on the ReFS volume for files older than 30 days without impacting fast clone for synthetic fulls for my daily backups?

Can/should I do an in-place upgrade server 2019?

Not a high change rate on the data, ~30 vms. 64gb RAM, 2x 6/12 cpu.

[Gostev]

You can with Server 2019, but it's not recommended. You can read the previous page (btw, please use forum search before creating new topics in the future).

[PM_ME_UR_MANPAGES]

Thank you, sorry!

[MaxDes]

Possible or not?

[MaxDes]

Does ReFS work across backups? For instance, if I have 10 similar physical servers or VMs on an ReFS volume will the space savings happen cross all of those or is it each server's backup only? Does that make sense?