2019 + ReFS + Deduplication = Lost ReFS Benefits?

[JeremyC]

I have a 2019 ReFS repository with dedup enabled and am seeing get results. We have about 1000 servers we backup up, 50% physical and 50% virtual spread out between 200 sites over 1 gig fiber to each site from our data center. Currently, we are consuming 600 TB space with ReFS (no dedup). In my ReFS + dedup production/test environment (below) I'm getting a 94% dedup rate [Raw Size: 186 TB | Dedup Size: 10.3 TB]. However, when I run a synthetic full the backup job shows it is using fast clone but the VBK it creates consumes a ton of space. It appears all ReFS fast clone benefits are lost i.e. no "spaceless full". The only way to recover the space is to let deduplication run its course. All of the space is recovered over the next 24 to 48 hours which is great but the drive nearly runs out of space with all of the new synthetic fulls. All of the testing I've done has been on backups of physical windows servers. On our production repositories, we run ReFS 64K with no dedup and ReFS functions as I would expect it to. Synthetic fulls take up little to no space. Any idea how to resolve this?

Environment configured as follows

Console Server: 9.5.4.2866 u4 b | OS: 2016
Registry: ReFSDedupeBlockClone=1

Repository:
OS: 2019 | V: 1809 | Build: 17763.1158
RAM: 384
NIC: 10G
Drives: 2 x 50 TB LUNs
Format: ReFS 64K
Align backup file data block: Checked
Decompress backup data blocks before storing: Checked
Use per-VM backup files: Checked
Data Deduplication: Virtualized Backup Server
Deduplicate files older than: 0 Days

Backup Jobs:
Backup > Create synthetic full backups periodically: Checked
Storage > Compression Level: None
Storage > Storage optimization: LAN target

Case # 04102124

Thanks,
Jeremy

[tsightler]

To me it sounds like this is just ReFS + Dedupe + Block Clone working the way it is designed. When you call the ReFS block clone API to clone a block from a deduped file, the data is rehydrated inline prior to being passed to the ReFS clone function. This is described more completely in this post.

Unfortunately there's not much that can be done about it since this is simply the way ReFS works with block clone when the underlying files are deduped.

[DonZoomik]

It works as it should. Also see older threads:
veeam-backup-replication-f2/refs-3-0-an ... 56658.html
veeam-backup-replication-f2/server-2019 ... 57184.html