在服务器运行过程中如果出现意外情况突然断电很容易引起服务器故障，服务器中的硬件设备损坏可以修复或者购买，但是服务器中的数据一旦发生故障丢失，对于企业来说将是不可估量的损失。那么服务器数据一旦丢失就除了痛哭之外别无他法了吗?不是的，下面我将引用一个真实案例为大家意外断电导致服务器数据丢失的数据恢复方法和过程。文中若有歧义之处欢迎探讨。
在案例中分析底层数据发现Xen Server服务器中虚拟机的磁盘均以以LVM的结构存放，即每个虚拟机的虚拟磁盘都是一个LV，并且虚拟磁盘的模式是精简模式的。LVM的相关信息在Xen Server中都有记载，查看下LVM的相关信息发现并没有存在损坏的虚拟磁盘信息，因此可以断定LVM的信息已经被更新了。接着分析底层看能否找到未被更新的LVM信息，果不其然在底层发现了还未更新的LVM信息。如下图:
根据未被更新的LVM信息找到了虚拟磁盘的数据区域，发现该区域的数据已被。分析后发现造成虚拟机不可用的最终原因是因为虚拟机的虚拟磁盘被，从而导致虚拟机中的操作系统和数据丢失。而导致这种情况的发生很有可能是虚拟机网络或hack入侵后留下恶意程序造成的。仔细核对这片区域后发现，虽然该区域有很多数据被了，但还是发现了很多数据库的页碎片。因此可以尝试将许多数据库的页碎片拼成一个可用的数据库。
根据RAR压缩包的结构可以找到很多压缩包的数据开始，而RAR压缩包文件的第一个扇区中会记录此RAR的文件名。因此根据从客户那里得知备份数据库的压缩包文件名和目前找到的压缩包的文件名相匹配，即可找到备份数据库压缩包的开始。找到压缩包的后仔细分析这片区域的数据，然后将此区域的数据恢复出来重命名为一个RAR格式的压缩文件。然后尝试解压此压缩包，发现解压报错。
仔细分析恢复出来的压缩包发现中有部分数据被了，因此解压的时候报错。尝试使用RAR的修复工具看能否忽略错误，解压部分数据。结果修复完成之后解压的数据库只有网站的部分代码，并没有数据库的备份文件。因此可以判断数据的备份文件在RAR压缩包中是损坏的。
由于方案一并没有将数据库恢复出来，因此采用方案二来恢复数据。根据SQL Server数据库的结构去底层分析数据库的开始，在数据库的结构中，第9个页会记录本数据库的数据库名。因此在客户那里获取数据库的名称之后，再分析底层找到此数据库的开始。因为在数据库的每个页中都会记录数据库页编号以及文件号，所以可以根据这些特征编写程序去底层扫描符合数据库页的数据。
由于数据库需要结合网站代码才能更好的验证数据库的完整性。客户从开发商里拿到了网站代码搭建好了，然后将恢复好的数据库发给用户。经用户验证后，数据库没问题，通过拼数据库碎片的方式成功将数据库恢复完成，整个数据恢复成功。返回，查看更多
网友评论 ()条 查看