Hello,
I am writing here to find answer and solve the issue which did cause our new moved File Server to have lost the data of a whole day.
The setup:
* Two Node Storage Spaces Direct Cluster with Full SSD Storage, is the base for the VMs of a General Use File Server Cluster
Two VMs in a Cluster with the File Server Role deployed as General Use (according to my reading and understanding of the wonderful article "To scale out or not to scale out, that is the question" https://techcommunity.microsoft.com/t5/storage-at-microsoft/to-scale-out-or-not-to-scale-out-that-is-the-question/ba-p/425080 )
The VMs got four VHD Set shared drives.
On the File Server, I enabled Data Deduplication
The issue:
Firstly, Dedup seems to run fine. Data was deduplicated and reported.
Then suddenly files where inaccessible. Trying to
Start-DedupJob -Type Unoptimizationdid not helped and was terminated. Or this task reported that 56k files where inaccessible.The evenlog is full with different errors.
Event ID:
6144 - File inaccessible
4137 - Volume not enabled for data deduplication - Well
Get-DedupVolumeandGet-DedupStatusreport it differently at that time-
This one made me courious. For me ti means in the beginning everything is fine. Dedup is running and the filter driver applied to the NTFS volume. But then something happens and this filter is removed or something happens to the System Volume Information and Dedup cannot read anything anymore. There was nothing touched in that area. All folders on the file share are accessible for SYSTEM.0x80565309, A required filter driver is either not installed, not loaded, or not ready for service
I tried to stop dedup via unoptimization. It did work if:
I have a volume without any dedup files
Remove it from the file server role
Enabled it as CSV
Run unoptimization task
All other volumes are not recoverable. Every Dedup tasks simply fails with an error.
We have other files servers on different hardware platforms where we use DFS-R. On these servers Dedup is enabled too and is working fine.
The difference is that those servers (two of them are served via an SOFS role) use VHDX files for the data. Only this Cluster with the main data on top of the S2D Cluster used the VHD Set disk types.
I searched now already for a lot for information and did not found any. So therefor, I start asking here if this is a known issue between dedup a volume which is a VHD set or if I do oversea any other issue?
For now the cluster is offline, so I could together with Microsoft take a deeper look on this issue. For me this looks critical as even if this is an known not-supported configuration, the MS documentation does not mention it. Neither in VHD sets nor in Data Dedup, or I have a blind spot on that sentence.
Hopefully, I just faced a rare bug and can help to avoid others having the same issue.
Kind regards
Felix