故障描述
1、硬件架构概述
服务器:Dell 720服务器配戴一张H710P的RAID卡。
存储阵列:由4块希捷2T STAT硬盘组成的RAID 10。
操作系统:Xen Server 6.2版本。
2、故障虚拟机概述
操作系统:Windows Server 2003。
应用:Web服务器(ASP + SQL 2005的网站架构)。
虚拟磁盘:10G系统盘 + 5G数据盘。
故障描述:因特殊原因导致Xen Server服务器中一台VPS(即Xen Server虚拟机)不可用,虚拟磁盘中数据丢失。
故障分析
1、备份数据;先将客户的数据盘连接到恢复环境服务器上,然后准备比客户数据总容量还要大的空间。将客户数据盘以磁盘底层扇区的方式镜像到准备的空间上,以确保客户的数据安全。
2、分析故障原因;仔细分析底层数据发现Xen Server服务器中虚拟机的磁盘都是以LVM的结构存放的,即每个虚拟机的虚拟磁盘都是一个LV,并且虚拟磁盘的模式是精简模式的。LVM的相关信息在Xen Server中都有记载,查看“/etc/lvm/backup/ “下LVM的相关信息发现并没有存在损坏的虚拟磁盘信息,因此可以断定LVM的信息已经被更新了。接着分析底层看能否找到未被更新的LVM信息,果不其然在底层发现了还未更新的LVM信息。如下图:
图一:
根据未被更新的LVM信息找到了虚拟磁盘的数据区域,发现该区域的数据已被破坏。分析后发现造成虚拟机不可用的最终原因是因为虚拟机的虚拟磁盘被破坏,从而导致虚拟机中的操作系统和数据丢失。而导致这种情况的发生很有可能是虚拟机遭遇网络攻击或hack入侵后留下恶意程序造成的。仔细核对这片区域后发现,虽然该区域有很多数据被破坏了,但还是发现了很多数据库的页碎片。因此可以尝试将许多数据库的页碎片拼成一个可用的数据库。
解决方案
1、方案一:恢复数据库备份;根据客户描述,数据库在4月份做过一次备份,并将这个数据库备份文件和网站代码一起压缩到一个RAR的压缩包中。因此只需要恢复这个压缩包即可恢复这个备份的数据库和网站的源代码。
2、方案二:拼数据库碎片;由于数据区被破坏,因此只能在底层根据数据库的结构将将数据库的碎片按照原有的顺序都拼接起来,然后做数据库的修复以及数据库的校验即可恢复此数据库。
恢复数据
1、实施方案一;按照方案一的思路进行底层分析,根据RAR压缩包的结构可以找到很多压缩包的数据开始位置,而RAR压缩包文件的第一个扇区中会记录此RAR的文件名。因此根据从客户那里得知备份数据库的压缩包文件名和目前找到的压缩包位置的文件名相匹配,即可找到备份数据库压缩包的开始位置。找到压缩包的位置后仔细分析这片区域的数据,然后将此区域的数据恢复出来重命名为一个RAR格式的压缩文件。然后尝试解压此压缩包,发现解压报错。
图二:
仔细分析恢复出来的压缩包发现中有部分数据被破坏了,因此解压的时候报错。尝试使用RAR的修复工具看能否忽略错误,解压部分数据。结果修复完成之后解压的数据库只有网站的部分代码,并没有数据库的备份文件。因此可以判断数据的备份文件在RAR压缩包中是损坏的。
图三:如下是解压出来的部分网站代码。
2、实施方案二:由于方案一并没有将数据库恢复出来,因此采用方案二来恢复数据。根据SQL Server数据库的结构去底层分析数据库的开始位置,在数据库的结构中,第9个页会记录本数据库的数据库名。因此在客户那里获取数据库的名称之后,再分析底层找到此数据库的开始位置。因为在数据库的每个页中都会记录数据库页编号以及文件号,所以可以根据这些特征编写程序去底层扫描符合数据库页的数据。
然后将扫描出来的碎片按顺序重组成一个完整MDF文件,再通过MDF校验程序检测整个MDF文件是否完整。重建的MDF文件如下:
图四:
3、搭建环境验证数据
检测没问题之后再由我们的数据库工程师搭建数据库环境,将重组后的数据库附加到搭建好的数据库环境中。然后查询相关表数据是否正常,查询最新数据是否存在。截图如下:
图五:
验证数据
由于数据库需要结合网站代码才能更好的验证数据库的完整性,而网站源代码大部分都被破坏了,备份中的源代码也只有部分才可以用。客户从开发商里拿到了网站代码搭建好了环境,然后将恢复好的数据库发给用户。经用户验证后,数据库没问题。
恢复总结
由于客户数据被非法破坏,因此恢复难度很大。底层大量的数据都被破坏了,但是客户重要的是SQL Server数据库,因此只需要恢复数据库文件即可。因此通过拼数据库碎片的方式成功将数据库恢复完成,整个数据恢复成功。
1、硬件架构概述
服务器:Dell 720服务器配戴一张H710P的RAID卡。
存储阵列:由4块希捷2T STAT硬盘组成的RAID 10。
操作系统:Xen Server 6.2版本。
2、故障虚拟机概述
操作系统:Windows Server 2003。
应用:Web服务器(ASP + SQL 2005的网站架构)。
虚拟磁盘:10G系统盘 + 5G数据盘。
故障描述:因特殊原因导致Xen Server服务器中一台VPS(即Xen Server虚拟机)不可用,虚拟磁盘中数据丢失。
故障分析
1、备份数据;先将客户的数据盘连接到恢复环境服务器上,然后准备比客户数据总容量还要大的空间。将客户数据盘以磁盘底层扇区的方式镜像到准备的空间上,以确保客户的数据安全。
2、分析故障原因;仔细分析底层数据发现Xen Server服务器中虚拟机的磁盘都是以LVM的结构存放的,即每个虚拟机的虚拟磁盘都是一个LV,并且虚拟磁盘的模式是精简模式的。LVM的相关信息在Xen Server中都有记载,查看“/etc/lvm/backup/ “下LVM的相关信息发现并没有存在损坏的虚拟磁盘信息,因此可以断定LVM的信息已经被更新了。接着分析底层看能否找到未被更新的LVM信息,果不其然在底层发现了还未更新的LVM信息。如下图:
图一:
根据未被更新的LVM信息找到了虚拟磁盘的数据区域,发现该区域的数据已被破坏。分析后发现造成虚拟机不可用的最终原因是因为虚拟机的虚拟磁盘被破坏,从而导致虚拟机中的操作系统和数据丢失。而导致这种情况的发生很有可能是虚拟机遭遇网络攻击或hack入侵后留下恶意程序造成的。仔细核对这片区域后发现,虽然该区域有很多数据被破坏了,但还是发现了很多数据库的页碎片。因此可以尝试将许多数据库的页碎片拼成一个可用的数据库。
解决方案
1、方案一:恢复数据库备份;根据客户描述,数据库在4月份做过一次备份,并将这个数据库备份文件和网站代码一起压缩到一个RAR的压缩包中。因此只需要恢复这个压缩包即可恢复这个备份的数据库和网站的源代码。
2、方案二:拼数据库碎片;由于数据区被破坏,因此只能在底层根据数据库的结构将将数据库的碎片按照原有的顺序都拼接起来,然后做数据库的修复以及数据库的校验即可恢复此数据库。
恢复数据
1、实施方案一;按照方案一的思路进行底层分析,根据RAR压缩包的结构可以找到很多压缩包的数据开始位置,而RAR压缩包文件的第一个扇区中会记录此RAR的文件名。因此根据从客户那里得知备份数据库的压缩包文件名和目前找到的压缩包位置的文件名相匹配,即可找到备份数据库压缩包的开始位置。找到压缩包的位置后仔细分析这片区域的数据,然后将此区域的数据恢复出来重命名为一个RAR格式的压缩文件。然后尝试解压此压缩包,发现解压报错。
图二:
仔细分析恢复出来的压缩包发现中有部分数据被破坏了,因此解压的时候报错。尝试使用RAR的修复工具看能否忽略错误,解压部分数据。结果修复完成之后解压的数据库只有网站的部分代码,并没有数据库的备份文件。因此可以判断数据的备份文件在RAR压缩包中是损坏的。
图三:如下是解压出来的部分网站代码。
2、实施方案二:由于方案一并没有将数据库恢复出来,因此采用方案二来恢复数据。根据SQL Server数据库的结构去底层分析数据库的开始位置,在数据库的结构中,第9个页会记录本数据库的数据库名。因此在客户那里获取数据库的名称之后,再分析底层找到此数据库的开始位置。因为在数据库的每个页中都会记录数据库页编号以及文件号,所以可以根据这些特征编写程序去底层扫描符合数据库页的数据。
然后将扫描出来的碎片按顺序重组成一个完整MDF文件,再通过MDF校验程序检测整个MDF文件是否完整。重建的MDF文件如下:
图四:
3、搭建环境验证数据
检测没问题之后再由我们的数据库工程师搭建数据库环境,将重组后的数据库附加到搭建好的数据库环境中。然后查询相关表数据是否正常,查询最新数据是否存在。截图如下:
图五:
验证数据
由于数据库需要结合网站代码才能更好的验证数据库的完整性,而网站源代码大部分都被破坏了,备份中的源代码也只有部分才可以用。客户从开发商里拿到了网站代码搭建好了环境,然后将恢复好的数据库发给用户。经用户验证后,数据库没问题。
恢复总结
由于客户数据被非法破坏,因此恢复难度很大。底层大量的数据都被破坏了,但是客户重要的是SQL Server数据库,因此只需要恢复数据库文件即可。因此通过拼数据库碎片的方式成功将数据库恢复完成,整个数据恢复成功。