We have a deduplicated volume on a Windows Server 2012 machine that is approaching it's limits. It is a 1.3TB drive with ~10TB of duplicated data. We want to copy all of this data onto a larger 4TB drive.

What is the best way to perform this copy such that we only copy the 1.3TB of deduplicated data instead of unpacking the entire 10TB and repacking it on the other end?

edit: I attempted a standard explorer file copy and a Copy-Item but neither appeared to be dedup-aware. I didn't run either to completion however so I can't say this is the case for sure.

  • You can also use BitTorrent Sync. – user1598202 Jun 30 '13 at 5:09

I ended up making the copy using windows server backup which is dedup-aware. I followed the instructions on this page: http://technet.microsoft.com/en-us/library/hh831600.aspx

In our case we were moving the data from the T: drive to the Y: drive. I used the X: drive as the intermediate backup storage drive. The backup storage drive does not need to have deduplication enabled and only needs to be as large as the optimized deduplicated data.

Make the backup:

C:\> wbadmin start backup –include:T: -backuptarget:X:

Get the backup version:

C:\> wbadmin get versions

Restore the backup to the new drive:

C:\> Wbadmin start recovery –version:02/16/2012-06:22 -itemtype:Volume  -items:T: -recoveryTarget:Y:

Standard copy commands did not appear to be dedup-aware, though I didn't attempt to run any of them to completion so I could be wrong. If anyone has a better solution I will update the accepted answer.


Forgive me for doing Google research on this, but I like the question as it could pertain to me someday.

Here's what I've found:

Introduction to Data Deduplication in Windows Server 2012

Portability: A volume that is under deduplication control is an atomic unit. You can back up the volume and restore it to another server. You can rip it out of one Windows 2012 server and move it to another. Everything that is required to access your data is located on the drive. All of the deduplication settings are maintained on the volume and will be picked up by the deduplication filter when the volume is mounted. The only thing that is not retained on the volume are the schedule settings that are part of the task-scheduler engine. If you move the volume to a server that is not running the Data Deduplication feature, you will only be able to access the files that have not been deduplicated.

Which sounds to me like if you tried to move the deduped data it would only copy the 1.3TB.

The same info, roughly, can be found here: Seven Things to know about Windows 2012 Deduplication

'Atomic units' mean that all of the deduplication information about a given volume is kept on that volume, so it can be moved without injury to another system that supports deduplication. If you move it to a system that doesn't have deduplication, you'll only be able to see the nondeduplicated files. The best rule is not to move a deduplicated volume unless it's to another Windows Server 2012 machine.

and since in order to "un-dedupe" them you have to run something like:

Start-DedupJob -Type Unoptimization

Finally: http://msmvps.com/blogs/ivansanders/archive/2013/03/03/windows-server-2012-new-features-data-deduplication.aspx

Requirements for Drive removal for use in other systems, if keeping the data on the drive
1. The OS is Windows server 2012 
2. You have configured Data deduplication on the new system.
3. OR, You have removed data deduplication from the drive prior to moving the drive >to a platform that does not support Data deduplication

Note: as mentioned above to get the drives to work without the documents / files having the appearance of corruption when you attempt to open them on the new system, you will to install and configure data duplication on the new system .prior to moving the drives to the new systems What this means is that you would need to remove data deduplication from the volume prior to installing the drive in ANY Operating System that is NOT Windows Server 2012

All that said , since I don't have the means to test it myself...I can't confirm for certain this means it will not re-hydrate the data as it moves, but it appears it won't. I'm sorry I can't confirm 100%. I'd post this is a comment but there's too much to share.


You could clone the source disk to a larger target disk. Then placing the Target disk in the system, you expand the volume to the full 4tb of available space. The clone process would be a block level transfer, so it wouldn't take any longer than a 1.3tb disk.


You will need to copy the data at the block-level. If you use a utility that copies at the file level then you will get every file in the expanded logical volume. There are some different utilities that can do this. Easeus Disk Copy is one.


Another idea may be using a VHD(X) container for your deduped volume. You will then be able to move the VHDX around to whatever disk you want, and all deduplicated files and metadata will contained in the VHD file.

Obviously this does incur some overheads... but flexibility advantages might outweigh the disadvantages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.