<p id="34L28FKF"><strong>服务器数据恢复环境：</strong><br/>SAN光纤网络环境，存储由一组6块硬盘组建的RAID6阵列构成，划分为若干LUN，MAP到跑不同业务的SUN SOLARIS操作系统服务器上。<br/></p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F1029%2F28662aa7j00sm3lsr014dd000v900mqp.jpg&thumbnail=660x&quality=80&type=jpg"/><br/>北亚企安数据恢复—SAN数据恢复<br/></p><p id="34L28FKH"><br/><strong>服务器故障&分析：</strong><br/>因为业务需要，用户在该光纤存储环境中新增一台SUN SOLARIS操作系统服务器。将存储中的某个LUN映射到新增的服务器上，但是映射的这个卷之前已经MAP到SOLARIS生产系统上的某个LUN上了。因为未及时察觉这个问题，新增服务器已经对该LUN进行部分初始化操作。<br/>在SOLARIS操作系统层面磁盘报错，重启后卷无法挂载。联系SUN工程师检测后，执行了fsck操作。操作完成后虽然文件系统可以挂上，但是发现大量文件丢失或文件大小变为0，尤其是最新数据破坏严重。<br/>此类故障在SAN光纤网络环境下较为常见，大多数情况下是人为设置不当造成的，此故障也是如此。正常情况下，SAN分配出来的LUN是独占的。LUN如果同时被几个操作系统控制就会导致写操作不互斥，文件系统一致性出错。<br/>如果要恢复这类故障中的丢失/破坏的数据，需要深入文件系统观察各结构的破坏情况。本案例的文件系统是UFS，所以对任何一个需要恢复的文件来说，需要优先考虑目录信息、节点、数据区这几个结构是否正常。如果这3个结构均正常，数据可完整恢复。但多数情况下，执行fsck操作后INODE会被清除，即使留下目录信息，也无法与数据一一对应。这种情况下只能参考文件内部格式进行类型式的恢复。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F1029%2Fb5b487f4j00sm3ltw00lzd000i200i4p.jpg&thumbnail=660x&quality=80&type=jpg"/><br/>北亚企安数据恢复—SAN数据恢复<br/></p><p id="34L28FKK"><br/><strong>服务器数据恢复过程：</strong><br/>1、以只读方式将故障卷完整镜像。后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始数据造成二次破坏。<br/>2、基于镜像文件分析文件系统，分析发现需要恢复的文件的inode已经被全部清除，无法恢复，只能按照文件类型进行处理。<br/>3、分析需要恢复的特定文件，发现采用vfs公文系统的索引文件具有很强的类型特征，且文件中包含目录信息。<br/>4、按照vfs公文系统的索引结构特征，北亚企安数据恢复工程师编写程序提取数据，提取后根据特征重新命名。<br/>5、按照类型恢复数据文件。恢复完成后由用户方根据索引文件对数据文件进行重新整理。<br/>6、经过数据恢复工程师的努力，目录索引文件基本上全部恢复出来，大部分数据文件恢复成功。对于极小部分无法恢复的文件，用户根据目录索引文件重新向其他部门采集。用户认可数据恢复结果。<br/></p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F1029%2Fe8ff1ae8j00sm3lud00fqd000v900fmp.jpg&thumbnail=660x&quality=80&type=jpg"/><br/>北亚企安数据恢复—SAN数据恢复<br/></p> 讯享网
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/180513.html