共计 1118 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
某公司一台 DELL 服务器，作为 WEB 服务器应用，装置的 Windows Server 操作系统，配置了 SQL Server 数据库；
采纳了 Xen Server 虚拟化零碎；
底层是通过 raid 卡，用 4 块 STAT 硬盘搭建的 RAID10。
服务器故障：
服务器意外断电导致虚拟机磁盘失落，虚拟机不可用。须要复原 SQL Server 数据库。
服务器数据恢复过程：
1、将故障服务器中所有硬盘以只读形式进行镜像备份，后续的数据恢复剖析和数据恢复操作都基于镜像文件进行，不会对原服务器做任何操作，保障原服务器初始状态，防止对原始数据造成可能的二次毁坏。
2、基于镜像文件对底层数据进行剖析，发现故障服务器中失落的虚拟机磁盘都采纳了 LVM 的构造。进入到“/etc/lvm/backup/”目录下查问看是否有损坏的虚构磁盘信息，如果有就意味着 LVM 信息尚有保留；如果没有就意味着虚构磁盘信息曾经被更新，只能通过底层数据查找没有更新的 lvm 信息。本案例中北亚企安数据恢复工程师从底层数据中查问到了尚未更新的 lvm 信息，见下图：
3、找到 lvm 信息就意味着数据还在。基于 lvm 信息剖析 & 查找虚构磁盘的分区数据，然而数据恢复工程师通过剖析后居然发现虚构磁盘被毁坏了，这种景象十分少见。通过进一步查找和剖析后确认该区域的数据的确被毁坏了，只能找到一些数据库页碎片，能够通过数据库碎片拼接的伎俩来复原数据，即依据数据库构造，将底层找到的数据库的页碎片依照原先的程序拼接起来，而后对数据库进行修复和校检后即可复原数据库。
4、试图通过数据库备份来复原数据库。因为之前数据库做过一次备份，数据库备份文件和网站代码被一起压缩到一个 RAR 压缩包文件中。失常状况下 rar 压缩包的第一个扇区记录的是文件名，所以能够依据文件名反向查找压缩包的数据起始地位，把相应的压缩包底层数据提取进去并重命名。然而在理论的复原过程中却呈现了意外，提取进去的压缩包解压时报错，报错信息见下图：
5、尝试应用 rar 修复工具（设置为“疏忽谬误”）持续解压数据，依然解压失败。惯例的数据恢复办法行不通。只能通过数据库碎片拼接来复原数据库数据。
6、在数据库层面剖析数据库开始地位，剖析出数据库开始地位后依据每个数据库页的编号和文件号去底层扫描合乎这个数据库页的所有数据，最初由北亚企安数据恢复工程师将所有扫描进去的数据重组为一个 mdf 文件。通过校验程序检测合格后提取数据。重组后的 mdf 文件见下图：
数据验证：
通过北亚企安数据恢复工程师团队的不懈努力，最终将服务器内的数据全副提取进去并通过初步验证。搭建了数据库环境，将复原进去的数据库数据附加下来进行查问，最新数据都查问失常。本次数据恢复实现。复原后果见下图：