FIXED: Windows Server 2016 VDI Deduplication caused data corruption; Please Fix!
If you have Windows 2012 R2 with a nicely dedup'ed volume in VDI mode, then after upgrading to Windows 2016, all of a sudden VHDX files of VMs will be corrupted on by one! This is a serious regression and needs immediate attentions!
NOTE FROM SITE ADMIN:
1. This bug was fixed in the following KB: https://support.microsoft.com/en-us/help/4011347/windows-10-update-kb3216755
2. More information about this fix can be found here: https://blogs.technet.microsoft.com/filecab/2017/01/30/windows-server-2016-data-deduplication-users-please-install-kb3216755/
Thanks for this item. Even though it was not feedback, it was in fact a bug, which has been resolved offline.
Will Gries [MSFT] commented
Hey everyone, Microsoft Data Deduplication PM here. There are two issues being talked about in this thread. The original UserVoice suggestion from Windows Server 2016 Technical Preview was fixed as part of Server 2016 development. The issue mentioned by Martin, and in fact reported to us by Martin first (thanks Martin!), was fixed in the following KB: https://support.microsoft.com/en-us/help/4011347/windows-10-update-kb3216755
More information about this fix can be found here: https://blogs.technet.microsoft.com/filecab/2017/01/30/windows-server-2016-data-deduplication-users-please-install-kb3216755/
We appreciate, and take seriously, all UserVoice feedback - thank you! Please also feel free to reach out to us directly with questions, comments, or concerns at email@example.com! :)
Program Manager, Data Deduplication
Martin Damgaard commented
I got a test patch to this bug directly from Microsoft deduplication team. So far it seems to have fixed the issue...
Martin Damgaard commented
Very interesting read!
I have the EXCACT same problem on a test setup planned for use as a Veeam Backup Copy repository.
The setup is an older HP Proliant G6 server with 32 GB ECC RAM, connected to a SAS enclosure with 12x6GB SATA disks. Windows is Server 2016 TP5, and was updated this week with all the latest windows updates (still waiting to see if this fixes the issue).
The disks is split in 6 disk mirror without dedupe for main Veeam backup jobs, and another 6 disks in mirror – with dedupe enabled – for Veeam Backup Copy repository.
These are my findings until now:
– No issues with the volume running without dedupe.
– Have not seen any scrubbing errors or Veeam health check errors on backup files below 1 TB so far.
– Veeam backup copy files from our main fileserver is 2.8 TB in size (single file) for full backups. These gets corrupted, over and over. It seems to happen after the files have been processed by the dedupe engine. Or after some time – i am not quite sure, when the corruption happens.
– Also, i have noticed, that read performance from the deduped data files is all over the place. Often they have really low read speeds (tested by copying from dedupe volume to non-dedupe volume) in the 50-60 MB/s, other times up to 150-200 MB/s. (Files that have not yet been deduped screams ahead around 350-400 MB/s from that same volume to volume testing). I dont know if this is normal behaviour with Windows dedupe, as i have never tried with windows dedupe setup before.
– I have run HDD Guardian SMART extended tests on all 12 disks, and none of them return any errors.
To me, it seems something is broken in 2016 dedupe engine for very large files!
I have just deleted yet another Veeam weekly full backup file with corruptions. And now i have my fingers crossed for what will happen during this week after i have installed all the latest Windows updates… (Installed around sept. 3rd 2016).
Your are more than welcome to contact me directly if you would like to discuss more about this…
(Write to md at syddjursspildevand dot dk)
If anyone else is seeing this issue, please contact us here or by emailing me directly (firstname.lastname@example.org). The customer here no longer has a repro, so we don't know if it was a one off of that environment, and no one else has reported the behavior.
Hi Chris - we are unaware of this issue and are emailing you offline (at the address you used to submit this feedback) to see what's going on.