问题发现

此前部署在服务器上的某个磁盘存在磁盘重复删除业务会不定期标注为禁用。起初以为是剩余的磁盘空间不足所致，添加1T容量后问题继续存在。

于是开始关注Data Deduplication的日志，发现存在 8200 的提示，如下图所示。

WINDOWS的日志比较坑的一点在于信息太少，提示了数据无效但是没有给出影响面，哪些文件会有影响不知道。

寻找处理材料

盘点了线上的数据，总共5T的数据，进行压缩的数据有2T。查阅了MSDN和google，似乎没有人遇到类似问题。

关于Data Deduplication的业务处理逻辑总共分3个阶段。

第一阶段：Optimization

优化作业通过根据卷策略设置对卷上的数据进行分块、（可选）压缩这些块以及将块唯一存储在块存储中来进行重复数据删除。

系统会盘点磁盘上的文件内容，以块的形式进行核对。如果发现重复的部分就进行标注，并且在 \System Volume Information\Dedup\ChunkStore{随机数}.ddp\Data\ 下将重复部分的数据块写入到 .CCC为结尾的内容中，.CD为结尾的是配套的列表文件，内容一致互为备份，.delete.log 看名字是删除记录日志。

第二阶段 GarbageCollection

垃圾回收作业通过删除最近修改或删除的文件不再引用的不必要块来回收磁盘空间。

第三阶段 Scrubbing

可识别由于磁盘故障或坏扇区而导致的块存储中的损坏。如果可能，重复数据删除可以自动使用卷功能（如存储空间卷上的镜像或奇偶校验）来重建损坏的数据。此外，当常用块在称为热点的区域中引用超过 100 次时，重复数据删除会保留这些块的备份副本。

尝试独立处理

从MS的文档看，Scrubbing 是可以解决此类故障的。我执行了强制的全盘Scrubbing，等待了24小时发现效果并不理解，问题依然存在。

继续基于日志里的文件进行核对，发现提到的故障文件一共有4个文件，存储位置都在 \?\Volume{2fb67e29-e604-4b60-9d02-93c9732e10fd}\System Volume Information\Dedup\ChunkStore{CCDAF01C-8451-4450-9AA6-B72FFF641C98}.ddp\Data\ 目录下，文件尺寸均为0。

看来对于0字节的CCC重复块问题，Scrubbing显然是没有解决方案。

这时候基本心里有底了，前段时间因为内存过热问题，一条32G的内存不稳定存过中途断电，依据Data Deduplication的业务处理逻辑，*.CCC文件是压缩后的重复数据块。

这时候提出一个假设，如果系统在执行GarbageCollection的阶段，强行断电，是否就可以产生此类故障，实际上数据没有丢失？

开始实验

启动一台VM，安装 Data Deduplication 模块

然后构建故障环境

## 设置0天前的文件 进行压缩，保证100%文件命中压缩
Set-DedupVolume -Volume r: -MinimumFileAgeDays 0
## 这时候复制 100MB的单个文件，并且反复复制10次，并且对其中个别文件进行修改，保证磁盘里一定是有重复内容，但又存在不同。
## 手工启动优化
Start-DedupJob -Volume r: -Type Optimization
## 观察VM磁盘里，是否建立了 \Data\ *.CCC 文件并且尺寸都大于0
## 删除部分文件
## 启动垃圾回收
Start-DedupJob -Volume r: -Type GarbageCollection
## 这时候观察 \Data\ 下的文件，可以看到 *.CCC文件在尺寸减少，并且逐步删除。
### 这时候 打一个快照，然后开始不断强行关机，找到一个 保存 *.CCC文件 为0 ，但是未来得及删除的时间点。如果不是，就返回快照。
## 然后开始进行恢复
Start-DedupJob -Volume r: -Type Unoptimization
## 最终发现文件内容都正常。

解决方案

经过这次测试，基本上心里有谱了，数据很大概率是没有故障。剩下的操作就是等待72小时。先Unoptimization 然后再Optimization 重建即可。