共计 1080 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
服务器：SUN 光纤存储系统；
6 枚 300G 硬盘组成 RAID6，划分若干 LUN，MAP 到不同业务的服务器上；
服务器操作系统 SUN SOLARIS。
故障：
业务新增利用，须要减少一台服务器。服务器管理员在原服务器在线状态下将其中一个 lun 映射到一台新服务器上。服务器管理员在执行操作之前没有留神到这个刚刚映射过来的卷曾经 map 到了 solaris 生产零碎上的某个 lun 上了。将这个 lun 映射到新的服务器后，服务器对这个卷开始进行初始化，solaris 生产零碎上的磁盘呈现报错，于是服务器管理员重启服务器，重启服务器之后这个卷曾经无奈挂载了。
服务器管理员分割 SUN 原厂工程师进行修复。SUN 工程师检测故障状况后执行了 fsck 操作并胜利挂载文件系统，然而少数数据失落或文件大小为 0，而最新的数据全副失落。服务器管理员分割北亚数据恢复核心进行服务器数据恢复。
服务器数据恢复故障剖析：
本案例中的故障在 san 环境下比拟常见，少数状况是服务器管理员在没有具体理解服务器的具体情况而执行操作导致的数据失落。
在失常的工作模式下，san 调配的卷为独立占用模式，如果服务器管理员将其映射给两个或多个操作系统将会导致文件系统一致性出错。
在这种状况下要进行数据恢复，首先要剖析文件系统各个构造的损坏状态。在本次服务器数据恢复案例中，采纳的是 UFS 文件系统。在 UFS 文件系统下，复原任何一个文件都要先确认目录信息、节点、数据区是否失常，这 3 个参数都失常则数据可复原。但执行 fsck 操作后节点会被革除，即便留下目录信息也无奈与数据一一对应，如果呈现这种状况就只能参考文件外部格局进行类型式的数据恢复了。
服务器数据恢复过程：
北亚数据恢复工程师查看硬件之后确认服务器无物理故障。
- 对呈现故障的 lun 进行残缺备份，在本次数据恢复案例中无任何硬件故障，失常备份即可。
- 在备份文件中对文件系统进行解析，发现元文件中的 iNode 的确曾经被革除了，无奈通过还原节点（iNode）复原数据，只能通过文件类型进行数据恢复。
- 数据恢复工程师对用户须要复原的特定文件进行剖析，发现采纳 vfs 公文零碎的索引文件具备强的类型特色，同时文件中蕴含目录信息。
- 依照公文零碎的索引结构特征，北亚数据恢复工程师编写程序进行数据提取，提取数据后依据特色重新命名。
- 按类型复原数据文件，而后依据索引文件对数据文件进行重新整理。
服务器复原数据验证：
通过 2 个工作日的数据分析和复原操作，服务器数据恢复工程师最终提取了原服务器内 99% 的数据和目录索引文件，通过服务器管理员对复原进去数据进行验证，最终确认所须要的重要数据曾经全副复原。
