随着千兆网络普及小型存储也开始越来越多，特别是在专业级影视领域，存储数据要的就是快速和稳定，所以小存储很适合专业级影视这个行业。下面我们来看一个36T的小存储恢复R3D文件的案例。
故障存储: 36T，Exfat文件系统
故障现象:
原始故障为正常使用时发现很多R3D文件长度为0字节，但是后续重启设备时发现有提示修复损坏，所以进行了经典的chkdsk"蹂躏"。
图1：变成0字节的R3D文件
图2：CHKDSK生成了大量的FILE****.CHK文件
故障分析:
近期处理了很多exfat变0字节的案例，下边把exfat变0字节的原理和chkdsk原理再次"复制粘贴"下：
- exfat文件系统出错导致文件全部0字节。
关于exfat之前说过很多次，但是近期使用此文件系统出问题的机率如此频繁，所以我再赘述下。exfat 全称是Extended File Allocation Table File System，扩展FAT文件系统，FAT就是之前FAT32中的"FAT"即文件分配表，这个表研究数据结构的人不算陌生，从字面意思就能看出，exfat并非全新的文件系统。微软开发此文件系统的目的是为了应对FAT32无法管理单个超过4G的文件，也是为了弥补NTFS日志型文件系统在闪存等小型存储设备中的不足（一个是默认的簇大小过小，一个是不断的读写日志对闪存是一种损耗）。
exfat在存储时使用两种方式，对文件进行分类：
- 无碎片文件，即连续存放的，通过在exfat目录项中记录首簇指针和长度来获取文件的链表。减少文件系统额外的IO时间，这个算是针对FAT32的升级。
- 存在碎片的文件，即不连续存放的。因为1是一种理想状态，需要各种条件满足才能达到，但是更多情况下是文件不得不以碎片的形式存在（比如经常删除或者使用空间快要达到上限），这种情况下仍然使用FAT32的FAT表进行文件的表链记录。目录项中只记录首簇指针和文件大小，通过首簇指针进行FAT表跳转，很熟悉的味道，和FAT32一毛一样。
这里不讨论exfat的优劣和传输速度，仅仅一点微软开发exfat初衷是为了解决闪存类的文件系统存储问题，为了弥补NTFS的不足，当然不能说exfat就不能用在非闪存上而是其适用最优对象是闪存类小型存储身设备（如SD卡），
很显然36T存储不在这个最优对象之内。
另外技术分析当文件长度变为0后，首簇指针也清0，通过文件头获取首簇指针跳转FAT表发现其FAT表链也清0了。也就是目录项->FAT表所有环节通通出错，目前尚不清楚这是个例还是仅在大型存储上存在，因为目前以我的经验至少没有发现在闪存类存在此问题，所以不好下结论，只能以"exfat的文件系统结构不适合管理大型存储"来做总结，在这里我们强烈建议如果您是视频从业者，在存储文件要用到微软文件系统时强烈建议"非闪存类的存储设备慎用exfat文件系统"避免因此导致数据出问题。
好了，下边来介绍下R3D文件，此文件是RED影视公司自行开发的高清视频文件，属于是特殊格式。目前暂时没有程序支持，更何况被chkdsk"分割"成各种小碎片的情况。
经过CHS工程师的分析，成功获取R3D的文件结构，并且对其视音频帧进行了深入解析。根据获取的信息进行分析，然后得出结论----R3D文件碎片可以定位也可以重组，剩下的就是根据方案进行程序编写，经过几天的奋战CHS零壹视频恢复程序影视版的程序的内测程序开发成功，剩下的就是直接扫描了。
故障处理:
STEP1: 运行CHS零壹视频恢复程序影视版，选择逻辑盘点击右键，点击扫描，大类选择->RED Digtal Cinema，扫描小类->R3D,然后点击"扫描"。
STEP2:等待扫描完成，由于盘比较大，所以可能时间略长。
STEP3:经过11小时扫描，开始重组，等待重组完成。
STEP4:查看扫描结果，经过扫描发现有大约14T数据，通过对比文件名发现0字节的数据有大约1.3T，然后保存文件，经过核对文件就是客户所需要的。
R3D使用是专门的RED PLAYER播放器，恢复后的文件可以正常播放、编辑，下图中的画面进行了马赛克处理，至次数据恢复工作完美完成！
这就是RED专业级影视文件R3D文件的恢复方法，大家遇到此类问题可以参考引案例。