Windows Server 2012 – Deduplication on Hyper-V Host or Guest VM?

I suspect your replica VHDs are either constantly open with a write lock or too frequently written to be covered by the MinimumFileAgeDays setting (5 days by default, can be set as low as 0 with Set-Dedupvolume <Drive>: -MinimumFileAgeDays 0).

By the way, the documentation clearly declares such a configuration "unsupported":

Unsupported configurations

Constantly open or changing files

Deduplication is not supported for files that are open and constantly changing for extended periods of time or that have high I/O requirements, for example, running virtual machines on a Hyper-V host, live SQL Server databases, or active VDI sessions.

Deduplication can be set to process files that are 0 days old and the system will continue to function as expected, but it will not process files that are exclusively open. It is not a good use of server resources to deduplicate a file that is constantly being written to, or will be written to in the near future. If you adjust the default minimum file age setting to 0, test that deduplication is not constantly being undone by changes to the data.

Deduplication will not process files that are constantly and exclusively open for write operations. This means that you will not get any deduplication savings unless the file is closed when an optimization job attempts to process a file that meets your selected deduplication policy settings.

And thus also contains the following recommendation:

Not good candidates for deduplication:

• Hyper-V hosts
• VDI VHDs
• WSUS
• Servers running SQL Server or Exchange Server
• Files approaching or larger than, 1 TB in size

It looks a bit like what you are seeking for is online deduplication which dedupes data as it is being written to disk. This is a feature of some more sophisticated SAN solutions (including Nexenta's SMB-targeted offerings), but comes at a rather high cost for the silicon - you would need a powerful machine with a lot of RAM to have online dedup run smoothly.

You are right in your assumption that WSB has created shadow copies. It uses these copies to maintain a backup history.

If you still have backup versions (and thus shadow copies) of points in time before your dedup optimization job has run, you would not see any savings at all since the deduplicated blocks have not been freed - they are needed for an older, non-deduped version of the data which is still referenced by one of the shadow copies.

So the bottom line is that if you need deduplication savings to show, you need to remove all older shadow copies.

The increase you are seeing is probably not due to deduplication activity but simply due to the fact that additional backup jobs were run in the meantime and older shadow copies are not deleted unless necessary (i.e. the volume would not have enough space for the new backup otherwise)