About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Data Deduplication is one of the most effective storage features in Windows Server. On a file server full of similar documents, installation files or virtual disk images, it can reclaim a large share of the disk. Microsoft's Data Deduplication Overview notes that Datasets that have high duplication could see optimization rates of up to 95%, or a 20x reduction in storage utilization.
Users never see it. Backups and restores, however, depend on understanding what is actually stored on a deduplicated volume, because it is no longer simply a set of whole files. This article explains, from Microsoft's documentation, how deduplicated volumes are built, and what that means for protecting and recovering them.
How a deduplicated volume stores files
Microsoft's article Understanding Data Deduplication describes the design. Deduplication works after the fact: All data is written unoptimized to the disk and then optimized later by Data Deduplication. A scheduled job later examines files, splits them into variable-size portions called chunks, and keeps one copy of each unique chunk.
The same article describes where those chunks go: The chunk store is an organized series of container files in the System Volume Information folder that Data Deduplication uses to uniquely store chunks. The optimised file itself no longer holds its data. Its original contents are replaced by a reparse point, a marker that points into the chunk store.
When a user opens the file, a file system filter follows those pointers and assembles the file from its chunks. Microsoft explains that Users and applications that access data on an optimized volume are completely unaware that the files they are accessing have been deduplicated.
In our reading, that transparency is exactly why deduplication needs care in backup planning. To users, the volume looks like ordinary files. On disk, the files and the chunk store are a single structure. An optimised on-disk file representation without its required chunks is incomplete; the chunk store on its own is only a collection of anonymous pieces. Neither is useful without the other.
The jobs that keep it healthy
The Understanding article lists the background jobs that run on a deduplicated volume. Three matter for recovery planning:
- Optimisation, which chunks new and changed files and places their unique chunks in the chunk store.
- Garbage Collection, which reclaims disk space by removing unnecessary chunks that are no longer being referenced by files that have been recently modified or deleted.
- Integrity Scrubbing, which identifies corruption in the chunk store due to disk failures or bad sectors. Microsoft adds that deduplication keeps backup copies in a hotspot area for chunks referenced more than 100 times, and can use mirror or parity storage features to repair corrupted data where available.
In our reading, the scrubbing job is a reminder of a real risk in the design. On an ordinary volume, damage can affect file data or shared filesystem metadata. On a deduplicated volume, one damaged chunk may be shared by many files. Microsoft's mitigations reduce that risk, but they live on the same volume. They are not a substitute for a backup held elsewhere.
The article also carries a clear warning: Unless instructed by authorized Microsoft Support Personnel, do not attempt to manually modify the chunk store. It says doing so may result in data corruption or loss.
Backing up: whole volume, or file by file
There are, in our reading, two broad ways a backup tool can protect a deduplicated volume, and the difference matters.
Backing up the volume as it is stored
Microsoft's Data Deduplication interoperability article covers Windows Server Backup specifically: Windows Server Backup can back up an optimized volume as-is (that is, without removing deduplicated data). The article goes on to describe restoring either a whole volume or selected files from such a backup.
In our understanding, a backup taken this way captures the volume in its optimised form, chunk store included, so the backup itself benefits from the space savings. Restoring the whole volume brings back the files and the chunk store together, as a matching pair.
Backing up files as users see them
A backup tool that reads files through the normal file system path receives each file in full, reassembled from its chunks. In our understanding, that backup is larger, since the deduplication savings are lost, but every file in it is self-contained.
Neither approach is wrong. In our view, what matters is knowing which one a backup product uses on a given volume, because it decides how much backup storage is needed, how long backups take, and what a restore will need on the other side.
Microsoft's interoperability article is the right starting point. For third-party backup products, their own documentation on deduplicated volumes is the authority; in our view, support for "Windows Server" in general is not the same as documented support for deduplicated volumes.
Why copying files is a known hazard
The interoperability article lists Robocopy, Windows' standard file copy tool, under unsupported scenarios. It states: Running Robocopy with Data Deduplication isn't recommended because certain Robocopy commands can corrupt the Chunk Store. It goes on to describe the failure: if the System Volume Information folder is deleted, optimised files copied from the source become corrupted, because the data chunks aren't copied to the destination volume.
In our reading, this is the clearest illustration of the pointer-and-store design. A copy that carries the pointers without the store produces files that look present but cannot be read. Copy-based migrations, ad hoc "backups" to a spare disk, and moving restored files into place all deserve care on deduplicated volumes. Where a copy is needed, the safe assumption is that it must read files through the normal path so each arrives whole. This article does not give copy commands.
Restoring: plan for the full size
This is, in our view, the point most often missed. The space a deduplicated volume uses on disk is not the space its files need once they leave the chunk store.
Microsoft's figure of up to a 20-fold reduction cuts both ways. In our reading, a volume holding several terabytes of files may use only a fraction of that on disk. A restore that brings files back individually, rather than as an optimised volume, can need the full logical size at the destination, at least until deduplication runs there and optimises them again. If the destination is an ordinary volume without deduplication, it needs the full size permanently.
Some situations where, in our view, that difference bites:
| Restore situation | What to plan for |
|---|---|
| Whole volume restored as stored | Similar space to the original volume |
| Many files restored to the same deduplicated volume | Room for them unoptimised until the next optimisation job |
| Files restored to a different, non-deduplicated volume | Their full logical size |
| Recovery onto smaller standby storage | Check logical size, not used space |
The post-processing design explains the second row. Since data is written unoptimised first, restored files land at full size and are only optimised later by the scheduled job. In our reading, a large restore onto a nearly full deduplicated volume can therefore run out of space even though the same files fitted before.
Moving deduplicated volumes between servers
The interoperability article lists where deduplication is supported. It is fully supported with Failover Clustering when every node has the feature installed, and on ReFS volumes from Windows Server 2019. It is not supported on Windows 10; Microsoft notes that copying server binaries onto Windows 10, as some community posts describe, is not a supported method.
In our reading, this affects recovery more than it first appears. A deduplicated volume or virtual disk attached to a computer without the deduplication feature cannot be read normally, because nothing is there to follow the reparse points into the chunk store. Microsoft’s design page explains that reads of optimised files go through the Dedup.sys filter to the chunk store. A recovery plan that assumes "attach the data disk to any Windows machine" needs a server with deduplication installed, at a Windows Server version supported for that volume and recovery path, to read it.
Replicas are copies of the same structure
Deduplicated volumes are often also replicated, either file by file with DFS Replication or block by block with Storage Replica. The interoperability article covers both, and in our reading they behave differently.
For DFS Replication, Microsoft explains that Optimizing or unoptimizing a file doesn't trigger a replication because the file doesn't change. DFS Replication uses Remote Differential Compression (RDC) for network savings, not the chunks in the chunk store, and the replica can be deduplicated independently if it has the feature turned on. In our understanding, each DFS Replication member therefore holds its own self-contained copy of the files and its own chunk store.
For Storage Replica, which copies the volume itself, Microsoft says it is fully supported, and that Data Deduplication should be configured to not run on the secondary copy. In our reading, the secondary is a block copy of the primary, chunk store included, so its state follows the primary's.
In our view, neither kind of replica replaces a backup. Both carry deletions and, in the case of block replication, any damage to the chunk store, across to the other side. They are availability tools; a backup is the copy that is kept apart and can be wound back in time.
The article also lists unsupported cases. Deduplication isn't supported inside a virtual machine on a Hyper-V host with nested virtualization enabled, or on volumes with multiple storage tiers. In our view, it is worth checking both before relying on a recovery environment that differs from production.
Turning deduplication off is not instant
The Understanding article describes an Unoptimization job, which undoes the optimization done by deduplication and disables Data Deduplication for that volume. Microsoft notes that it is a special job that should only be run manually.
In our reading, the job writes every file back out at full size, so the volume needs room for all of it. It is not a quick way out during an incident. If there is any doubt about whether a volume should stay deduplicated, that decision belongs in calm planning, not during a recovery.
What we recommend
- Know which volumes are deduplicated, and record it in the recovery plan.
- Confirm how the backup product protects them: as stored, or file by file.
- Record both used and logical size for each deduplicated volume, and check restore destinations against the logical size.
- Keep a recovery server with deduplication installed wherever restored volumes or virtual disks may need to be read.
- Avoid ad hoc file copies of deduplicated volumes; follow Microsoft's interoperability guidance.
- Never touch the chunk store or the System Volume Information folder by hand.
- Test a large restore, not just a single file, onto realistic storage.
Distinguish backup size from restore capacity
The planning figures should identify logical file size, current allocated storage, free space and the backup product’s restore mode. Sparse files, compression and product-specific rehydration can affect those figures, so a deduplication percentage alone is not a capacity calculation. A whole-volume restore also has destination layout and size requirements that differ from restoring selected files. Microsoft’s interoperability page says a hard quota at a deduplicated volume’s root is unsupported: quota-limited space differs from actual free space and can cause optimisation jobs to fail. Account for actual quota and capacity limits when planning a restore.
Choose a representative large restore for the rehearsal, including files that share many chunks and files changed recently. Confirm that the restored files can actually be read through the supported server filter, and check their content and permissions. A directory listing proves neither chunk availability nor successful rehydration. Preserve the original backup and avoid manual changes inside the chunk store while investigating failures. If a product claims optimised backup support, obtain its documented Windows version and restore limitations and test that specific path rather than extrapolating from generic file backup support.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026.
- How individual third-party backup products handle deduplicated volumes is outside this article.
- Space planning examples are our reading of Microsoft's design description, not measurements.
- No volumes were deduplicated, backed up or restored for this article, and no commands are given.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Data Deduplication Overview
- Microsoft Learn: Understanding Data Deduplication
- Microsoft Learn: Data Deduplication interoperability
This article was originally published on .