CN112199166B - 一种业务应急接管演练系统及其方法 - Google Patents

Abstract

本发明涉及一种业务应急接管演练系统及其方法，该系统包括生产机和容灾平台，生产机内设置有客户端及生产存储单元，容灾平台内设置有容灾服务器端和容灾存储单元，容灾服务器端和容灾存储单元分别与KVM虚拟化平台相连接，KVM虚拟化平台包括修复虚拟机和接管演练虚拟机，修复虚拟机用于对待修复磁盘中的系统进行自动修复；接管演练虚拟机用于执行顶替业务操作或预演操作。与现有技术相比，本发明能够对接管演练虚拟机进行自动化配置，通过内置修复虚拟机能自动修复常见的导致系统无法正常启动的问题，接管演练虚拟机启动之后，利用内置的服务来修改网络，检查并修复指定的应用，以此实现方便快捷地对业务进行接管演练的目的。

Description

一种业务应急接管演练系统及其方法

技术领域

本发明涉及容灾备份技术领域，尤其是涉及一种业务应急接管演练系统及其方法。

背景技术

近年来，随着信息科技的不断发展，企业或组织信息化建设也在快速发展，其对信息系统的依赖也越来越强，由此对业务连续性管理(Business Continuity Management，BCM)也有越来越高的要求，这就需要在信息系统发生故障之后，能够可靠保证业务不中断、数据不丢失，即使出现故障，也能够在最短的时间内应急接管，实现业务的持续运行。

为此需要进行业务应急接管演练，但目前大多应急接管演练平台存在配置繁琐、操作复杂的问题，往往需要配置或者选择各种参数才能完成一次接管演练任务；除此之外，由于应急接管演练的虚拟机容易发生无法正常启动的现象，只能频繁地通过人工手动进行修复，不但费时费力，而且对运维的工作也带来了更大的挑战，导致用户使用体验不佳，同时使得恢复时间目标(Recovery Time Object，RTO)增加。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种业务应急接管演练系统及其方法，能够自动进行系统修复，且能方便快速地进行业务应急接管或演练。

本发明的目的可以通过以下技术方案来实现：一种业务应急接管演练系统，包括相互连接的生产机和容灾平台，所述生产机内设置有相互连接的客户端及生产存储单元，所述容灾平台内设置有相互连接的容灾服务器端和容灾存储单元，所述容灾服务器端和容灾存储单元还分别与KVM(Kernel-based Virtual Machine，基于内核的虚拟机)虚拟化平台相互连接，所述KVM虚拟化平台包括修复虚拟机和接管演练虚拟机，所述客户端用于将生产机的初始化信息以及待备份数据传输给容灾服务器端、发送打快照信息给容灾服务器端，以及对接管演练虚拟机进行网络配置和应用修复；

所述容灾服务器端用于将初始化信息以及待备份数据对应写入容灾存储单元中，以及对待备份数据、容灾存储单元生成的快照进行管理；

所述容灾存储单元用于存储待备份数据、执行打快照操作，以及生成克隆磁盘；

所述修复虚拟机用于对待修复磁盘中的系统进行自动修复；

所述接管演练虚拟机用于执行顶替业务操作或预演操作。

进一步地，所述客户端包括任务调度模块、CDP驱动模块、卷磁盘解析读写模块、数据发送模块、应用一致性处理模块、自修复配置模块以及数据库，所述任务调度模块用于调度管理CDP驱动模块、数据发送模块、卷磁盘解析读写模块、应用一致性处理模块以及自修复配置模块的工作状态；

所述CDP驱动模块用于监控待备份的卷集合以及IO数据；

所述卷磁盘解析读写模块用于从待备份的卷集合中解析得到待备份卷的有效数据；

所述数据发送模块用于将待备份卷的有效数据和IO数据传输给容灾服务器端；

所述应用一致性处理模块用于对应用进行一致性处理，以及发送打快照信息给容灾服务器端；

所述自修复配置模块用于对接管演练虚拟机进行网络配置和应用修复；

所述数据库内存储有应用修复方案。

进一步地，所述容灾服务器端包括容灾控制模块，数据接收模块，存储管理模块，IO处理模块，接管演练模块和虚拟机通讯模块，所述容灾控制模块用于分别控制数据接收模块，存储管理模块，IO处理模块，接管演练模块和虚拟机通讯模块的工作状态；

所述数据接收模块与数据发送模块连接，用于接收数据发送模块传输的数据信息；

所述存储管理模块用于对待备份的IO数据、容灾存储单元生成的快照进行管理；

所述IO处理模块用于对客户端传输过来的IO数据进行解析以及合并处理，并将处理后的IO数据写入对应的逻辑磁盘中；

所述接管演练模块用于查找快照，以及根据克隆磁盘和初始化信息创建接管演练虚拟机；

所述虚拟机通讯模块用于与修复虚拟机建立通信连接。

进一步地，所述数据接收模块通过TCP/IP与数据发送模块相互连接。

进一步地，所述修复虚拟机内设置有与虚拟机通讯模块连接的通信模块以及用于修复接管演练虚拟机系统的系统修复模块。

进一步地，所述修复虚拟机包括用于修复类UNIX操作系统的第一修复虚拟机以及用于修复Windows操作系统的第二修复虚拟机。

一种业务应急接管演练方法，包括以下步骤：

S1、根据用户选择的卷集合，客户端从生产存储单元获取各卷的相关信息以及初始化信息，并将获取的信息传输给容灾服务器端；

S2、容灾服务器端根据初始化信息，基于容灾存储单元创建镜像卷和IO存储卷，其中，镜像卷用于存放生产机的卷有效数据，IO存储卷用于存放增量IO数据；

S3、客户端将生产机的卷有效数据以及监控的IO数据传输给容灾服务器端进行备份；

S4、当生产机中卷集合的有效数据都传输并写入对应的镜像卷之后，客户端执行应用一致性处理，之后发送打快照信息给容灾服务器端；

S5、容灾服务器端将打快照时间点之间的IO数据写入对应的镜像磁盘，之后基于容灾存储单元对镜像磁盘打快照；

S6、客户端持续将监控的IO数据传输给容灾服务器端进行备份，容灾服务器端则对应将IO数据写入对应的镜像磁盘，直至到达下一个打快照时间点，则返回步骤S4，以此完成备份流程；

S7、发起接管演练任务，对待创建的接管演练虚拟机进行配置；

S8、容灾服务器端根据用户选择的快照时间点，基于容灾存储单元生成接管演练虚拟机中的磁盘设备，即克隆磁盘，容灾服务器端根据用户选择的IO时间点，将IO数据写入克隆磁盘中；

S9、容灾服务器端将克隆磁盘热添加到修复虚拟机中，即得到待修复磁盘；

S10、容灾服务器端与修复虚拟机建立通信，将初始化信息以及待修复选项发送给修复虚拟机；

S11、修复虚拟机根据接收到的初始化信息和待修复选项，对待修复磁盘中的系统进行修复；

S12、修复完成后，修复虚拟机发送修复结束的信息给容灾服务器端；

S13、容灾服务器端热卸载克隆磁盘；

S14、容灾服务器端根据用户配置选型，基于KVM虚拟机平台创建并启动接管演练虚拟机；

S15、判断启动的接管演练虚拟机是否为接管虚拟机，若判断为是，则执行步骤S16，否则执行步骤S17；

S16、客户端根据IP配置文件信息来配置虚拟机的网络，之后执行步骤S17；

S17、客户端检测应用是否启动，若没有启动，则启动应用，若在启动中遇到问题，则根据错误描述对应用进行相应的修复，以此完成接管演练任务。

进一步地，所述步骤S7中对待创建的接管演练虚拟机进行配置的选项具体为：

快照时间点默认采用最新快照时间点；

IO时间点默认为IO存储卷中IO最新数据所对应的时间；

CPU、内存及网络配置默认与生产机保持一致；

各类修复选项默认开启；

上述各选项均支持用户进行相应修改。

进一步地，所述步骤S11中待修复磁盘中的系统包括类UNIX操作系统和Windows操作系统，对类UNIX操作系统进行修复的具体过程为：

1)根据初始化信息中记录的卷信息和磁盘信息找到对应的待修复磁盘，如果生产机中含有LVM卷，且用户选择了修复LVM卷，则对LVM进行激活操作，如果用户选择了删除卷组中丢失的物理卷，则将丢失的物理卷进行删除；

2)根据初始化信息中记录的卷信息和文件系统等信息，找到对应的待修复卷集合，将待修复卷集合分别进行挂载操作，简称修复挂载点集合，如果用户选择了修复文件系统，则通过系统命令对文件系统进行检测并修复；

3)如果用户选择了对fstab进行修复，则检测待修复卷中的fstab文件中的“filesystem”列是否为UUID的标识方式，若不是，则更改为对应卷或分区的UUID的表示方式，以免由于设备名称的变更导致系统无法正常启动，并将未被用户选中的作为待备份的卷或分区，在fstab中将其注释，以免系统由于无法找到该对应设备而导致系统无法正常启动；

4)如果用户选择了修复“grub.cfg”等相关系统启动文件，则将相关文件中用设备名来辨识启动设备的，统一改为设备的UUID的形式，以免由于设备名称的变更导致系统无法正常启动；

5)如果用户选择了修复grub，则重新安装grub；

6)如果用户选择了修复“initramfs”，则重建initramfs文件，从而解决因为生产机中因为一些不兼容的组件或驱动导致接管演练虚拟机无法正常启动的问题；

7)如果生产机为EFI启动方式且选择了添加开机自启动脚本的选项，则在修复磁盘中的EFI分区下的特定的文件夹下添加startup.nsh启动脚本文件，脚本文件中添加了grub文件的路径信息；

8)如果用户选择了删除指定的驱动，则查找到驱动相关的文件，将其全部移动到修复挂载点下的指定的备份文件夹中；如果用户选择其他支持安装的驱动，则从驱动库中将与生产机相匹配的驱动文件放置对应修复挂载点下的相应的文件夹下；修复虚拟机中存在一个驱动库，预先将各个系统版本常见的驱动文件编译好放到该驱动库中，根据系统版本可以查找到相应的驱动文件；

9)如果用户选择的是接管虚拟机，则将用户填写的相关IP等信息写入到修复挂载点下的指定的文件中；

10)如果用户指定了自定义脚本修复选项，则根据用户的自定义脚本来执行相应的修复；

对Windows操作系统进行修复的具体过程为：

1)根据初始化信息中记录的卷信息和磁盘信息找到对应的待修复对应的卷和磁盘；

2)如果用户选择了修改指定的注册表，则首先将对待修复卷中的注册表进行加载，然后根据指定的注册表的键值等信息，对注册表进行更改并保存；

3)如果用户选择了支持的驱动程序的注入，则将相应的驱动文件放置到待修复卷的相应文件夹中，并对修复卷中的注册表进行相应的更改；修复虚拟机中存在一个驱动库，预先将各个系统版本常见的驱动文件编译好放到该驱动库中，根据系统版本可以查找到相应的驱动文件；

4)如果用户选择了引导修复，则通过“bcdedit”、“bootsect”相关工具来对待修复的系统卷进行引导修复；

5)如果用户选择对非通用磁盘物理结构导致虚拟机无法正常启动的情况进行修复，则系统修复模块首先通过解析磁盘引导扇区MBR和活动分区的引导扇区来检测待修复的磁盘是否为通用磁盘物理结构，如果检测出该修复磁盘为非通用磁盘结构物理结构，则将其转换为通用的物理磁盘结构；

6)如果用户选择的是接管，则将用户填写的相关IP等信息写入到修复卷下的指定的文件中；

7)如果用户添加了自定义修复脚本，则运行该自定义修复脚本。

与现有技术相比，本发明具有以下优点：

一、本发明首先通过自动化配置实现快速地接管演练一台虚拟机，并通过在应急接管演练平台中内置的一台修复虚拟机来修复常见的导致系统无法正常启动的问题，接管演练虚拟机启动之后，利用内置的服务来修改网络，检查并修复指定的应用，从而最终达到方便快捷地对业务进行接管演练的目的。

二、本发明默认基于最新快照和IO时间点来运行接管演练任务，接管演练虚拟机默认采用原生产机的CPU、内存、网络等配置，并默认开启修复选项来对接管演练虚拟机系统进行自动修复操作，因此用户不需要复杂配置，即可完成接管演练任务，从而大大降低了操作难度。

三、本发明通过内置的修复虚拟机来对接管演练虚拟机系统进行自动修复，减少了用户对无法正常启动的虚拟机需要进行手动修复的情况的发生，效率更高，操作更简单，并能在短时间能快速接管业务系统，保证业务系统的连续性。

四、本发明在接管演练虚拟机启动之后，会自动配置网络，并能对常见的应用无法启动的问题进行修复，从而保证业务系统更快地运行起来，减少人为干预带来的不良影响。

附图说明

图1为业务应急接管演练系统的备份结构示意图；

图2为业务应急接管演练系统的接管演练结构示意图；

图3为本发明的备份流程示意图；

图4为本发明的接管演练流程示意图；

图中标记说明：1、生产机，2、容灾平台，3、KVM虚拟化平台，11、客户端，12、生产存储单元，21、容灾服务器端，22、容灾存储单元，31、修复虚拟机，32、接管演练虚拟机，110、任务调度模块，111、CDP驱动模块，112、卷磁盘解析读写模块，113、数据发送模块，114、应用一致性处理模块，115、自修复配置模块，116、数据库，210、容灾控制模块，211、数据接收模块，212、存储管理模块，213、IO处理模块，214、接管演练模块，215、虚拟机通讯模块，310、通信模块，311、系统修复模块。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。

实施例

如图1和图2所示，一种业务应急接管演练系统，包括相互连接的生产机1和容灾平台2，生产机1内设置有相互连接的客户端11及生产存储单元12，容灾平台2内设置有相互连接的容灾服务器端21和容灾存储单元22，容灾服务器端21和容灾存储单元22还分别与KVM虚拟化平台3相互连接，KVM虚拟化平台3包括修复虚拟机31和接管演练虚拟机32，客户端11用于将生产机1的初始化信息以及待备份数据传输给容灾服务器端21、发送打快照信息给容灾服务器端21，以及对接管演练虚拟机32进行网络配置和应用修复；

容灾服务器端21用于将初始化信息以及待备份数据对应写入容灾存储单元22中，以及对待备份数据、容灾存储单元22生成的快照进行管理；

容灾存储单元22用于存储待备份数据、执行打快照操作，以及生成克隆磁盘；

修复虚拟机31用于对待修复磁盘中的系统进行自动修复；

接管演练虚拟机32用于执行顶替业务操作或预演操作。

其中，客户端11包括任务调度模块110、CDP驱动模块111、卷磁盘解析读写模块112、数据发送模块113、应用一致性处理模块114、自修复配置模块115以及数据库116，任务调度模块110用于调度管理CDP驱动模块111、数据发送模块113、卷磁盘解析读写模块112、应用一致性处理模块114以及自修复配置模块115的工作状态；

CDP驱动模块111用于监控待备份的卷集合以及IO数据；

卷磁盘解析读写模块112用于从待备份的卷集合中解析得到待备份卷的有效数据；

数据发送模块113用于将待备份卷的有效数据和IO数据传输给容灾服务器端21；

应用一致性处理模块114用于对应用进行一致性处理，以及发送打快照信息给容灾服务器端21；

自修复配置模块115用于对接管演练虚拟机32进行网络配置和应用修复；

数据库116内存储有应用修复方案；

容灾服务器端21包括容灾控制模块210，数据接收模块211，存储管理模块212，IO处理模块213，接管演练模块214和虚拟机通讯模块215，容灾控制模块210用于分别控制数据接收模块211，存储管理模块212，IO处理模块213，接管演练模块214和虚拟机通讯模块215的工作状态；

数据接收模块211通过TCP/IP与数据发送模块113连接，用于接收数据发送模块113传输的数据信息；

存储管理模块212用于对待备份的IO数据、容灾存储单元22生成的快照进行管理；

IO处理模块213用于对客户端11传输过来的IO数据进行解析以及合并处理，并将处理后的IO数据写入对应的逻辑磁盘中，客户端发过来的IO数据是一个IO信息的集合，含有很多条IO信息，每条IO信息会含有时间戳、对应的是哪个卷的IO、这条IO在该卷上的偏移，以及这条IO的数据长度是多少，容灾服务端接收到这些IO信息之后，首先以文件的方式将IO信息存放到IO存储卷中，然后由独立的线程从文件里把这些IO再读出来，解析IO，再根据这些IO对应的卷、偏移，对这些IO进行合并，将同一个卷的IO写到对应的存储里的逻辑磁盘中；

接管演练模块214用于查找快照，以及根据克隆磁盘和初始化信息创建接管演练虚拟机32；

虚拟机通讯模块215用于与修复虚拟机31建立通信连接；

修复虚拟机31内设置有与虚拟机通讯模块215连接的通信模块310以及用于修复接管演练虚拟机32系统的系统修复模块311，且修复虚拟机31包括用于修复类UNIX操作系统的第一修复虚拟机以及用于修复Windows操作系统的第二修复虚拟机，使得修复虚拟机31能够与生产机相兼容地进行系统修复，比如类Unix操作系统对应的第一修复虚拟机只含有一个磁盘，在虚拟机中显示为/dev/sda，CPU为2核心，内存为512M，在其对应的xml文件中，添加了通道配置选项，如下所示：

“<channel type＝'unix'>

<source mode＝'bind'path＝'/var/lib/libvirt/qemu/linux.repair.x86_64.0.agent'/>

<target type＝'virtio'name＝'linux.repair.x86_64.0'/>

<address type＝'virtio-serial'controller＝'0'bus＝'0'port＝'1'/>

</channel>”

容灾服务器端会在“/var/lib/libvirt/qemu/”下生成“linux.repair.x86_64.0.agent”socket文件，在第一修复虚拟机中的“/dev/virtio-ports”目录下存在名为“linux.repair.x86_64.0”字符设备。

Windows操作系统对应的第二修复虚拟机，也只含有一个磁盘，在虚拟机中显示为磁盘0，对应只有一个卷，即C卷，同样的，CPU为2核心，内存为512M，在其对应的xml文件中，添加了通道配置选项，如下所示：

“<channel type＝'unix'>

<source mode＝'bind'path＝'/var/lib/libvirt/qemu/windows.repair.x86_64.0.agent'/>

<target type＝'virtio'name＝'linux.repair.x86_64.0'/>

<address type＝'virtio-serial'controller＝'0'bus＝'0'port＝'1'/>

</channel>”

容灾服务器端会在“/var/lib/libvirt/qemu/”下生成“linux.repair.x86_64.0.agent”socket文件，在修复虚拟机中的存在名为“\\\\.\\Global\\windows.repair.x86_64.0”字符设备。

虚拟机中的系统修复模块311为常驻进程，会一直监控着字符设备，直到有连接请求达到之后，再根据请求消息进行相应的操作。

将上述系统应用于实际，其具体工作过程包括以下步骤：

S1、根据用户选择的卷集合，客户端11从生产存储单元12获取各卷的相关信息以及初始化信息，并将获取的信息传输给容灾服务器端21；

S2、容灾服务器端21根据初始化信息，基于容灾存储单元22创建镜像卷和IO存储卷，其中，镜像卷用于存放生产机1的卷有效数据，IO存储卷用于存放增量IO数据；

S3、客户端11将生产机1的卷有效数据以及监控的IO数据传输给容灾服务器端21进行备份；

S4、当生产机1中卷集合的有效数据都传输并写入对应的镜像卷之后，客户端11执行应用一致性处理，之后发送打快照信息给容灾服务器端21；

S5、容灾服务器端21将打快照时间点之间的IO数据写入对应的镜像磁盘，之后基于容灾存储单元22对镜像磁盘打快照；

S6、客户端11持续将监控的IO数据传输给容灾服务器端21进行备份，容灾服务器端21则对应将IO数据写入对应的镜像磁盘，直至到达下一个打快照时间点，则返回步骤S4，以此完成备份流程；

S7、发起接管演练任务，对待创建的接管演练虚拟机32进行配置；

S8、容灾服务器端21根据用户选择的快照时间点，基于容灾存储单元22生成接管演练虚拟机32中的磁盘设备，即克隆磁盘，容灾服务器端21根据用户选择的IO时间点，将IO数据写入克隆磁盘中；

S9、容灾服务器端21将克隆磁盘热添加到修复虚拟机31中，即得到待修复磁盘；

S10、容灾服务器端21与修复虚拟机31建立通信，将初始化信息以及待修复选项发送给修复虚拟机31；

S11、修复虚拟机31根据接收到的初始化信息和待修复选项，对待修复磁盘中的系统进行修复；

S12、修复完成后，修复虚拟机31发送修复结束的信息给容灾服务器端21；

S13、容灾服务器端21热卸载克隆磁盘；

S14、容灾服务器端21根据用户配置选型，基于KVM虚拟机平台创建并启动接管演练虚拟机32；

S15、判断启动的接管演练虚拟机32是否为接管虚拟机，若判断为是，则执行步骤S16，否则执行步骤S17；

S16、客户端11根据IP配置文件信息来配置虚拟机的网络，之后执行步骤S17；

S17、客户端11检测应用是否启动，若没有启动，则启动应用，若在启动中遇到问题，则根据错误描述对应用进行相应的修复，以此完成接管演练任务。

具体的，在执行备份工作流程时，如图3所示，包括以下步骤：

(1)根据用户选择的卷集合，从生产系统中分别获取各卷的相关信息(卷信息，卷所属磁盘信息，文件系统信息等)以及操作系统、CPU、内存、网卡等信息，简称初始化信息，然后将初始化信息发送给容灾服务器端，容灾服务器端则根据生产机的卷集合所对应的磁盘列表[disk0，disk1，…，diskM]，最后利用容灾存储单元创建与之对应的逻辑磁盘集合，用于存放生成系统中的卷数据，简称镜像磁盘集合[mirrorDisk0，mirrorDisk1，…mirrorDiskM]；另外通过容灾存储单元创建一个逻辑磁盘，并格式化成卷，用于存放增量IO数据，简称IO存储卷；

(2)生产系统通过客户端中的任务调度模块，利用卷磁盘解析读写模块和数据发送模块，将卷中的有效数据块(簇)发送到容灾服务器端，即进行完备备份；同时将CDP驱动模块监控的IO数据也通过数据发送模块发送到容灾服务器端。容灾服务器端的数据接收模块在接收到数据之后，将卷数据写入到相应的镜像磁盘中，IO数据以IO数据文件的形式存放到IO存储卷中；

(3)当生产系统中卷集合中的有效数据都发送并写入到对应镜像磁盘后，即完备备份完成后，立刻通过客户端中的应用一致性处理模块，进行应用一致性处理，然后发送消息给容灾服务器端执行打快照操作，容灾服务器端收到打快照的操作后，首先将IO存储卷中记录的IO数据写入到对应的镜像磁盘中，然后直到IO数据中记录的时间戳大于等于打快照的时间点对应的时间戳时结束IO数据的处理，最后通过容灾服务器端中的容灾存储单元给镜像磁盘打快照，从而为镜像磁盘生成快照，生成的快照简称镜像磁盘快照；

(4)客户端不断将CDP驱动模块监控到的生产系统的IO数据发送给容灾服务器端并存放到日志卷中，容灾服务器端也不断根据IO存储卷存放的IO数据，将IO数据写入到相应的镜像磁盘中；

(6)根据打快照间隔，客户端周期性地对应用进行一致性处理，并将打快照信息发送给容灾服务器端，容灾服务端收到消息之后，根据快照信息以及IO的处理进度对镜像磁盘打快照；

在执行接管演练工作流程时，如图4所示，包括以下步骤：

(7)当发起接管演练任务时，用户不需要手动配置各种选项，直接采用默认配置进行接管演练任务即可，另外也支持用户对各种选项进行相应更改，如下描述各种选项的情况：

1)用户可以选择快照时间点和IO时间点，默认采用最新快照和最新的IO时间；

2)用户可以设置待创建的接管演练虚拟机的CPU、内存等配置，默认与生产系统保持一致，其中若待创建的为接管虚拟机，则接管虚拟机的网络信息，默认与生产系统的网络配置保持一致(用户可以更改网络配置信息)；

3)对于类Unix系统的待修复选项，例如LVM修复、fstab修复、文件系统修复、驱动修复(删除驱动、添加驱动)、grub修复、initramfs修复、开机自启动脚本添加，自定义脚本修复等都可以自由地开启或关闭，默认为开启状态；

4)对于Windows操作系统，例如修改注册表、驱动注入、引导修复、非标准磁盘导致虚拟机无法正常启动的修复等也可以自由地开启或关闭，默认为开启状态；

(8)容灾服务器端中的接管演练模块根据用户所选的快照时间点查找到对应的镜像磁盘快照，然后通过容灾存储单元对镜像磁盘快照再次执行快照操作，从而生成接管演练虚拟机中的磁盘设备，简称克隆磁盘，根据用户选择的IO时间点将快照时间点与IO时间点之间的IO数据写入到对应的克隆磁盘中，然后将克隆磁盘通过scsi挂载方式热添加到修复虚拟机中，在修复虚拟中，该磁盘简称为修复磁盘；

(9)容灾服务器端中的虚拟机通讯模块与修复虚拟机中的通讯模块建立通信链接，将生产系统中的初始化信息以及待修复选项发送到修复虚拟机中，其中虚拟机通讯模块是基于virtio来实现的，virtio是一种I/O半虚拟化解决方案，是一套通用I/O设备虚拟化的程序，可用于实现guest和host之间的通信。在修复虚拟机的启动配置xml文件中已经添加了virtio通道配置信息，相应的在容灾服务器中会产生相应的socket文件，在修复虚拟机中会产生相应的字符设备，在容灾服务器中通过域套接字和对应的字符设备实现与修复虚拟机的通讯；

(10)修复虚拟机中的修复模块，根据接收到的初始化信息和待修复选项对待修复磁盘中的系统进行修复。如果生产系统为类UNIX操作系统，则进行如下相关修复:

1)根据初始化信息中记录的卷信息和磁盘信息找到对应的待修复磁盘，如果生产系统中含有LVM卷，且用户选择了修复LVM卷，则利用“vgchange”命令对LVM进行激活操作，如果用户选择了删除卷组中丢失的物理卷，则利用“vgreduce”命令将丢失的物理卷进行删除；

2)根据初始化信息中记录的卷信息和文件系统等信息，找到对应的待修复卷集合，将待修复卷集合分别进行挂载操作，简称修复挂载点集合，如果用户选择了修复文件系统，则通过系统命令对文件系统进行检测并修复，例如xfs文件系统，通过“xfs_repair”等相关命令对文件系统进行检测并修复，EXT系列文件系统，则通过“e2fsck”等相关命令对文件系统进行检测并修复；

3)如果用户选择了对fstab进行修复，则检测待修复卷中的fstab文件中的“filesystem”列是否为UUID的标识方式，若不是，则更改为对应卷(分区)的UUID的表示方式，以免由于设备名称的变更导致系统无法正常启动，并将未被用户选中的作为待备份的卷(分区)，在fstab中将其注释，以免系统由于无法找到该对应设备而导致系统无法正常启动；

4)如果用户选择了修复“grub.cfg”等相关系统启动文件，则将相关文件中用设备名来辨识启动设备的，统一改为设备的UUID的形式，以免由于设备名称的变更导致系统无法正常启动；

5)如果用户选择了修复grub，则通过“grub-install”或“grub2-install”等相关命令对其进行重新安装grub；

6)如果用户选择了修复”initramfs”，则通过“dracut”等相关命令来重建initramfs文件，从而解决因为生产系统中因为一些不兼容的组件或驱动导致接管演练虚拟机无法正常启动的问题；

7)如果生产系统为EFI启动方式且选择了添加开机自启动脚本的选项，则在修复磁盘中的EFI分区下的特定的文件夹下添加startup.nsh启动脚本文件，脚本文件中添加了grub文件的路径信息；

8)如果用户选择了删除指定的驱动，则查找到驱动相关的文件，将其全部移动到修复挂载点下的指定的备份文件夹中。如果用户选择了其他支持安装的驱动，则从驱动库中将与生产系统相匹配的驱动文件放置对应修复挂载点下的相应的文件夹下；修复虚拟机中存在一个驱动库，我们将各个系统版本常见的驱动文件编译好放到该驱动库中，根据系统版本可以查找到相应的驱动文件；

9)如果用户选择的是接管，则将用户填写的相关IP等信息写入到修复挂载点下的指定的文件中；

10)如果用户指定了自定义脚本修复选项，则根据用户的自定义脚本来执行相应的修复；

如果生产机时Windows操作系统，则进行如下修复：

1)根据初始化信息中记录的卷信息和磁盘信息找到对应的待修复对应的卷和磁盘；

2)如果用户选择了修改指定的注册表，则首先将对待修复卷中的注册表进行加载，然后根据指定的注册表的键值等信息，对注册表进行更改并保存；

3)如果用户选择了支持的驱动程序的注入，则将相应的驱动文件放置到待修复卷的相应文件夹中，并对修复卷中的注册表进行相应的更改；修复虚拟机中存在一个驱动库，我们将各个系统版本常见的驱动文件编译好放到该驱动库中，根据系统版本可以查找到相应的驱动文件；

4)如果用户选择了引导修复，则通过“bcdedit”、“bootsect”相关工具来对待修复的系统卷进行引导修复；

5)如果用户选择对非通用磁盘物理结构导致虚拟机无法正常启动的情况进行修复，则系统修复模块首先通过解析磁盘引导扇区MBR和活动分区的引导扇区来检测待修复的磁盘是否为通用磁盘物理结构，所谓通用磁盘物理结构，磁盘的每磁道扇区数(PS)，每柱面磁头数(PH)为业界通用值，如果检测出该修复磁盘为非通用磁盘结构物理结构，则将其转换为通用的物理磁盘结构；

6)如果用户选择的是接管，则将用户填写的相关IP等信息写入到修复卷下的指定的文件中；

7)如果用户添加了自定义修复脚本，则运行该自定义修复脚本；

(11)修复虚拟机中的修复模块完成修复之后，发送消息给容灾服务器端的接管演练模块，接管演练模块收到修复完成的消息之后，热卸载挂载在修复虚拟机中的克隆磁盘，然后通知用户修复结果，接管演练模块根据克隆磁盘、CPU、内存等信息利用KVM虚拟机平台来创建接管演练虚拟机；

(12)接管演练虚拟机启动后，客户端会随机启动，客户端中的网络配置和应用的自修复配置模块根据记录了IP等信息的配置文件对虚拟机进行网络配置，然后检测应用软件的运行状态，若没有启动则启动应用，若在启动中遇到问题，则检索记录了问题及对应解决方法的数据库，根据数据库中记录的修复方案对应用进行修复，最终完成接管演练任务，如果是接管则可以顶替生产机来运行业务，其中，数据库位于客户端内，占用空间很小，数据库内存放有键值对，key对应问题的描述或者错误号，value值对应具体的解决方法。

本实施例基于上述系统及对应的方法，首先在需要容灾的生产系统(即生产机)中安装容灾客户端，同时在另外一台主机上安装容灾服务，并作为容灾服务器端。

之后执行备份工作流程：

第一步、容灾任务创建过程——从容灾服务器端选择某个连接到容灾服务器端的客户端作为备份对象，创建基于该客户端主机的容灾任务，待备份的卷为[volume0，..，volumeN]。

第二步、任务初始化阶段——发起容灾任务，客户端将根据待备份卷[volume0，..，volumeN]，获取到其对应的磁盘[disk0，…，diskM]，分别获取卷名称，卷大小，所属磁盘及大小，卷在磁盘上的偏移，文件系统、卷UUID等信息，简称初始化信息，发送给容灾服务器端。

第三步、容灾服务卷根据初始化信息，利用容灾存储单元创建与客户端磁盘相对应的LUN集合[LUN0，…，LUNM]，用于存储客户端卷的有效数据。然后将每个LUN通过loopback或ISCSI等方式映射为逻辑磁盘，简称镜像磁盘[mirrorDisk0，mirrorDisk1，…mirrorDiskM]，除此之外，利用容灾存储单元创建一个指定大小的LUN，并通过loopback或ISCSI等方式映射为逻辑磁盘，并进行格式化，用于存放客户端发送过来的IO数据，简称IO存储卷。

第四步、卷有效数据及IO数据的备份阶段——任务初始化完成后，通过客户端的CDP驱动模块对待备份的卷集合进行监控，首先将卷集合所属磁盘的引导扇区、隐藏分区里的数据发送到容灾服务器端，容灾服务器端根据生产机的磁盘与镜像磁盘的对应关系，将数据写入到相应的镜像磁盘中，然后客户端利用卷磁盘解析读写模块来解析待备份的卷集合，将卷的有效数据通过数据发送模块发送到容灾服务器端，直到将所有的待备份卷有效数据发送完成为止，与此同时将CDP驱动模块监控到的IO数据也发送到容灾服务器端。

第五步、容灾服务器端的数据接收模块接收到卷数据之后，根据卷数据所在磁盘的偏移写入到相应的镜像磁盘中，IO数据写入以数据文件的形式存放到IO存储卷中。

第六步、客户端执行应用一致性操作，利用应用提供的一致性接口对应用进行一致性的处理，处理完成之后，发送打快照消息给容灾服务器端。

第七步、容灾服务器端获取到快照的消息之后，根据IO数据记录的所属卷以及数据所在卷的偏移信息将数据写入到相应的镜像磁盘中，当所写的IO数据所记录的时间戳大于等于打快照的时间所对应的时间戳时，利用容灾存储单元对镜像磁盘所对应的LUN执行快照操作，形成镜像磁盘快照，从而生成快照时间点。

第八步、客户端不断将CDP驱动监控的IO数据发送到容灾服务器端。

第九步、容灾服务器端将IO数据存放到IO存储卷中，并根据IO数据记录的所属卷以及数据所在卷的偏移信息将数据写入到相应的镜像磁盘中。

第十步、当到了打快照时间，跳转到第六步继续执行。

之后执行接管演练工作流程：

第一步、用户为待生成的接管演练虚拟机配置各类选项，其中，快照时间点默认采用最新快照时间点，IO时间点默认为IO存储卷中IO最新数据所对应的时间，CPU、内存，网络等配置默认与生产机保持一致，各类修复选项默认开启，例如类Unix的LVM修复、fstab修复、文件系统修复、驱动修复(删除驱动、添加驱动)、grub修复、自定义脚本修复、initramfs修复、开机自启动脚本添加，Windows操作系统的修改注册表、驱动注入、引导修复、非标准磁盘导致虚拟机无法正常启动的修复，上述选项用户都可以自由设置或采用默认值。

第二步、容灾服务器端根据用户选择的快照时间点，通过容灾存储单元对该快照时间点的镜像磁盘的快照LUN执行克隆操作，生成克隆LUN，然后通过loopback或ISCSI方式映射生成克隆磁盘[clonedisk0，…，clinediskM]，容灾服务器端的IO处理模块根据快照时间点和IO时间点从存储卷中读取相应的IO数据写入到相应的克隆磁盘中。

第三步、容灾服务器端将克隆磁盘[clonedisk0，…，clinediskM]热加载到修复虚拟机中，称为待修复磁盘。

第四步、如果生产机系统为类UNIX操作系统，则容灾服务器端中的虚拟机通讯模块则通过域套接字与修复虚拟机中的字符设备建立连接，从而实现容灾端通讯模块与修复虚拟机通讯模块建立连接，然后，将初始化信息和修复选项发送到类UNIX修复虚拟机中。如果生产机系统为Windows操作系统，同样道理，容灾服务器端依靠虚拟机通信模块与Windows修复虚拟机中的通信模块实现通信，将初始化信息和修复选项发送到Windows修复虚拟机中。

第五步、修复虚拟机中的修复模块根据初始化信息和待修复选项对待修复磁盘中的系统进行自动修复。

对于生产机为类UNIX系统，例如该生产机为Centos7系统，备份的卷为“/dev/mapper/centos-root”，其挂载点为“/”；“/dev/sda1”，其挂载点为“/boot/efi”；“/dev/sda2”，其挂载点为“/boot”：

(1)如果待修复磁盘中含有LVM卷，例如“/dev/mapper/centos-root”等，且用户选择了修复LVM卷，则利用“vgchange”命令对LVM进行激活操作，如果用户选择了删除卷组中丢失的物理卷，则利用“vgreduce”命令将丢失的物理卷进行删除；

(2)如果用户选择了修复文件系统，则通过系统命令对文件系统进行检测并修复，例如xfs文件系统，通过“xfs_repair”等相关命令对文件系统进行检测并修复，EXT系列文件系统，则通过“e2fsck”等相关命令对文件系统进行检测并修复；

(3)如果用户选择了对fstab进行修复，则首先将“/dev/mapper/centos-root”挂载到“/tmproot”目录下，解析其“/tmproot/etc/fstab”文件，然后检测fstab文件中的“file system”列是否为UUID的标识方式，若不是，则更改为卷(分区)的UUID的表示方式(UUID等信息已经存在初始化信息中)，并将未被用户选中的作为待备份的卷(分区)，在fstab中将其注释掉；

(4)如果用户选择了修复“grub.cfg”等相关系统启动文件，则将该相关文件中用设备名来辨识启动设备的，统一改为设备的UUID的形式；例如上述的生产系统中，首先将“/dev/sda2”挂载到“/tmpboot/”目录下，然后将“/dev/sda1”挂载到“/tmpboot/efi”目录下，在“/tmpboot/efi/EFI/centos”目录下找到grub.cfg文件，解析文件，如果其“root”所指向的名称为设备名，不是设备的UUID的形式，则改成为root所指的设备的UUID的形式(UUID等信息已经存在初始化信息中)；

(5)如果用户选择了修复grub，则通过“grub-install”或“grub2-install”等相关命令对其进行重新安装grub；

(6)如果用户选择了修复“initramfs”，则通过“dracut”等相关命令来重建“initramfs”文件；

(7)如果生产系统为EFI启动方式且用于选择了开机自启动脚本的添加选项，则在修复磁盘中的EFI分区下的特定的文件夹下添加startup.nsh启动脚本文件，脚本文件中添加了grub文件的路径信息；例如对于上述生产系统，在“/tmpboot/efi”目录下创建startup.nsh脚本文件，其内容为“\\EFI\\centos\\grub.cfg”；

(8)如果用户选择了删除指定的驱动，则在查找到驱动相关的文件，将其全部移动到修复挂载点下的指定的备份文件夹中。如果用户选择了我们支持安装的驱动，则从驱动库中将与生产系统相匹配的驱动文件放置对应修复挂载点下的相应的文件夹下；

(9)如果用户选择的是接管，则将用户填写的相关IP等信息写入到修复挂载点下的指定的文件中；例如对于上述生产系统，在“/tmproot”目录下的“drill_ip.config”文件中写入“IP”、“NETMASK”、“GATEWAY”等信息；

(10)如果用户添加了自定义修复脚本，则运行该自定义修复脚本；

对于生产机为Windows系统,例如该生产机为Windows Servers 2012系统，备份的卷为“C”，其中“C”为系统启动盘，其对应的磁盘为磁盘0；则将其磁盘0对应的克隆磁盘热加载到Windows修复虚拟机中，在修复虚拟机中显示为磁盘1，备份的卷为“C”在修复虚拟机中分别显示为“D”；

(1)如果用户选择了修改指定的注册表，则首先将“D”盘中的注册表进行加载，然后根据指定的注册表的键值等信息，对注册表进行更改并保存；

(2)如果用户选择了我们支持的驱动程序的注入，则将相应的驱动文件放置到相应文件夹中，并对“D”盘中的注册表进行相应的更改；

(3)如果用户选择了引导修复，则通过“bcdedit”、“bootsect”相关工具来对待修复的系统卷进行引导修复；

(4)如果用户选择对非通用磁盘物理结构导致虚拟机无法正常启动的情况进行修复，则系统修复模块首先通过解析磁盘引导扇区MBR和活动分区的引导扇区来检测待修复的磁盘是否为通用磁盘物理结构，如果检测出该修复磁盘为非通用磁盘结构物理结构，则将其转换为通用的物理磁盘结构；

(5)如果用户选择的是接管，则将用户填写的相关IP等信息写入到修复挂载点下的指定的文件中；例如对于上述生产系统，在“D”盘目录下的“drill_ip.config”文件中写入“IP”、“NETMASK”、“GATEWAY”等信息；

(6)如果用户添加了自定义修复脚本，则运行该自定义修复脚本；

第六步、修复完成后，修复虚拟机中的修复模块发送修复结束的消息给容灾服务端。

第七步、容灾服务器端热卸载克隆磁盘。

第八步、容灾服务器端依托KVM虚拟机平台，并根据用户配置的CPU、内存等选项创建接管演练虚拟机，并启动虚拟机。

第九步、接管演练虚拟机启动之后，如果是接管虚拟机，则虚拟机中的客户端将根据IP配置文件信息来配置虚拟机的网络。例如上述提到的Centos7操作系统，则根据根目录下的“drill_ip.config”来设置网络信息；例如上述提到的Windows Servers 2012操作系统，则根据“C”盘下的“drill_ip.config”来设置网络信息。

第十步、接管演练虚拟机对应的客户端检测应用是否已经启动，若没有启动，则启动应用，若在启动中遇到问题，则根据错误描述来检索记录了问题及对应解决方法的数据库，根据数据库中记录的修复方案对应用进行相应的修复，最终完成接管演练任务。

Claims (8)

1.一种业务应急接管演练方法，应用于业务接管演练系统，其特征在于，所述业务接管演练系统包括相互连接的生产机(1)和容灾平台(2)，所述生产机(1)内设置有相互连接的客户端(11)及生产存储单元(12)，所述容灾平台(2)内设置有相互连接的容灾服务器端(21)和容灾存储单元(22)，所述容灾服务器端(21)和容灾存储单元(22)还分别与KVM虚拟化平台(3)相互连接，所述KVM虚拟化平台(3)包括修复虚拟机(31)和接管演练虚拟机(32)，所述客户端(11)用于将生产机(1)的初始化信息以及待备份数据传输给容灾服务器端(21)、发送打快照信息给容灾服务器端(21)，以及对接管演练虚拟机(32)进行网络配置和应用修复；

所述容灾服务器端(21)用于将初始化信息以及待备份数据对应写入容灾存储单元(22)中，以及对待备份数据、容灾存储单元(22)生成的快照进行管理；

所述容灾存储单元(22)用于存储待备份数据、执行打快照操作，以及生成克隆磁盘；

所述修复虚拟机(31)用于对待修复磁盘中的系统进行自动修复；

所述接管演练虚拟机(32)用于执行顶替业务操作或预演操作；

所述业务应急接管演练方法包括以下步骤：

S1、根据用户选择的卷集合，客户端从生产存储单元获取各卷的相关信息以及初始化信息，并将获取的信息传输给容灾服务器端；

S2、容灾服务器端根据初始化信息，基于容灾存储单元创建镜像卷和IO存储卷，其中，镜像卷用于存放生产机的卷有效数据，IO存储卷用于存放增量IO数据；

S3、客户端将生产机的卷有效数据以及监控的IO数据传输给容灾服务器端进行备份；

S4、当生产机中卷集合的有效数据都传输并写入对应的镜像卷之后，客户端执行应用一致性处理，之后发送打快照信息给容灾服务器端；

S5、容灾服务器端将打快照时间点之间的IO数据写入对应的镜像磁盘，之后基于容灾存储单元对镜像磁盘打快照；

S6、客户端持续将监控的IO数据传输给容灾服务器端进行备份，容灾服务器端则对应将IO数据写入对应的镜像磁盘，直至到达下一个打快照时间点，则返回步骤S4，以此完成备份流程；

S7、发起接管演练任务，对待创建的接管演练虚拟机进行配置；

S8、容灾服务器端根据用户选择的快照时间点，基于容灾存储单元生成接管演练虚拟机中的磁盘设备，即克隆磁盘，容灾服务器端根据用户选择的IO时间点，将IO数据写入克隆磁盘中；

S9、容灾服务器端将克隆磁盘热添加到修复虚拟机中，即得到待修复磁盘；

S10、容灾服务器端与修复虚拟机建立通信，将初始化信息以及待修复选项发送给修复虚拟机；

S11、修复虚拟机根据接收到的初始化信息和待修复选项，对待修复磁盘中的系统进行修复，其中，待修复磁盘中的系统包括类UNIX操作系统和Windows操作系统；

S12、修复完成后，修复虚拟机发送修复结束的信息给容灾服务器端；

S13、容灾服务器端热卸载克隆磁盘；

S14、容灾服务器端根据用户配置选型，基于KVM虚拟机平台创建并启动接管演练虚拟机；

S15、判断启动的接管演练虚拟机是否为接管虚拟机，若判断为是，则执行步骤S16，否则执行步骤S17；

S16、客户端根据IP配置文件信息来配置虚拟机的网络，之后执行步骤S17；

S17、客户端检测应用是否启动，若没有启动，则启动应用，若在启动中遇到问题，则根据错误描述对应用进行相应的修复，以此完成接管演练任务；

所述步骤S11中对类UNIX操作系统进行修复的具体过程为：

1)根据初始化信息中记录的卷信息和磁盘信息找到对应的待修复磁盘，如果生产机中含有LVM卷，且用户选择了修复LVM卷，则对LVM进行激活操作，如果用户选择了删除卷组中丢失的物理卷，则将丢失的物理卷进行删除；

2)根据初始化信息中记录的卷信息和文件系统等信息，找到对应的待修复卷集合，将待修复卷集合分别进行挂载操作，简称修复挂载点集合，如果用户选择了修复文件系统，则通过系统命令对文件系统进行检测并修复；

3)如果用户选择了对fstab进行修复，则检测待修复卷中的fstab文件中的“filesystem”列是否为UUID的标识方式，若不是，则更改为对应卷或分区的UUID的表示方式，以免由于设备名称的变更导致系统无法正常启动，并将未被用户选中的作为待备份的卷或分区，在fstab中将其注释，以免系统由于无法找到该对应设备而导致系统无法正常启动；

4)如果用户选择了修复“grub.cfg”等相关系统启动文件，则将相关文件中用设备名来辨识启动设备的，统一改为设备的UUID的形式，以免由于设备名称的变更导致系统无法正常启动；

5)如果用户选择了修复grub，则重新安装grub；

6)如果用户选择了修复“initramfs”，则重建initramfs文件，从而解决因为生产机中因为一些不兼容的组件或驱动导致接管演练虚拟机无法正常启动的问题；

7)如果生产机为EFI启动方式且选择了添加开机自启动脚本的选项，则在修复磁盘中的EFI分区下的特定的文件夹下添加startup.nsh启动脚本文件，脚本文件中添加了grub文件的路径信息；

8)如果用户选择了删除指定的驱动，则查找到驱动相关的文件，将其全部移动到修复挂载点下的指定的备份文件夹中；如果用户选择其他支持安装的驱动，则从驱动库中将与生产机相匹配的驱动文件放置对应修复挂载点下的相应的文件夹下；修复虚拟机中存在一个驱动库，预先将各个系统版本常见的驱动文件编译好放到该驱动库中，根据系统版本可以查找到相应的驱动文件；

9)如果用户选择的是接管虚拟机，则将用户填写的相关IP等信息写入到修复挂载点下的指定的文件中；

10)如果用户指定了自定义脚本修复选项，则根据用户的自定义脚本来执行相应的修复。

2.根据权利要求1所述的一种业务应急接管演练方法，其特征在于，所述客户端(11)包括任务调度模块(110)、CDP驱动模块(111)、卷磁盘解析读写模块(112)、数据发送模块(113)、应用一致性处理模块(114)、自修复配置模块(115)以及数据库(116)，所述任务调度模块(110)用于调度管理CDP驱动模块(111)、数据发送模块(113)、卷磁盘解析读写模块(112)、应用一致性处理模块(114)以及自修复配置模块(115)的工作状态；

所述CDP驱动模块(111)用于监控待备份的卷集合以及IO数据；

所述卷磁盘解析读写模块(112)用于从待备份的卷集合中解析得到待备份卷的有效数据；

所述数据发送模块(113)用于将待备份卷的有效数据和IO数据传输给容灾服务器端(21)；

所述应用一致性处理模块(114)用于对应用进行一致性处理，以及发送打快照信息给容灾服务器端(21)；

所述自修复配置模块(115)用于对接管演练虚拟机(32)进行网络配置和应用修复；

所述数据库(116)内存储有应用修复方案。

3.根据权利要求2所述的一种业务应急接管演练方法，其特征在于，所述容灾服务器端(21)包括容灾控制模块(210)，数据接收模块(211)，存储管理模块(212)，IO处理模块(213)，接管演练模块(214)和虚拟机通讯模块(215)，所述容灾控制模块(210)用于分别控制数据接收模块(211)，存储管理模块(212)，IO处理模块(213)，接管演练模块(214)和虚拟机通讯模块(215)的工作状态；

所述数据接收模块(211)与数据发送模块(113)连接，用于接收数据发送模块(113)传输的数据信息；

所述存储管理模块(212)用于对待备份的IO数据、容灾存储单元(22)生成的快照进行管理；

所述IO处理模块(213)用于对客户端(11)传输过来的IO数据进行解析以及合并处理，并将处理后的IO数据写入对应的逻辑磁盘中；

所述接管演练模块(214)用于查找快照，以及根据克隆磁盘和初始化信息创建接管演练虚拟机(32)；

所述虚拟机通讯模块(215)用于与修复虚拟机(31)建立通信连接。

4.根据权利要求3所述的一种业务应急接管演练方法，其特征在于，所述数据接收模块(211)通过TCP/IP与数据发送模块(113)相互连接。

5.根据权利要求3所述的一种业务应急接管演练方法，其特征在于，所述修复虚拟机(31)内设置有与虚拟机通讯模块(215)连接的通信模块(310)以及用于修复接管演练虚拟机(32)系统的系统修复模块(311)。

6.根据权利要求5所述的一种业务应急接管演练方法，其特征在于，所述修复虚拟机(31)包括用于修复类UNIX操作系统的第一修复虚拟机以及用于修复Windows操作系统的第二修复虚拟机。

7.根据权利要求1所述的一种业务应急接管演练方法，其特征在于，所述步骤S7中对待创建的接管演练虚拟机进行配置的选项具体为：

快照时间点默认采用最新快照时间点；

IO时间点默认为IO存储卷中IO最新数据所对应的时间；

CPU、内存及网络配置默认与生产机保持一致；

各类修复选项默认开启；

上述各选项均支持用户进行相应修改。

8.根据权利要求1所述的一种业务应急接管演练方法，其特征在于，所述步骤S11中对Windows操作系统进行修复的具体过程为：

1)根据初始化信息中记录的卷信息和磁盘信息找到对应的待修复对应的卷和磁盘；

2)如果用户选择了修改指定的注册表，则首先将对待修复卷中的注册表进行加载，然后根据指定的注册表的键值等信息，对注册表进行更改并保存；

3)如果用户选择了支持的驱动程序的注入，则将相应的驱动文件放置到待修复卷的相应文件夹中，并对修复卷中的注册表进行相应的更改；修复虚拟机中存在一个驱动库，预先将各个系统版本常见的驱动文件编译好放到该驱动库中，根据系统版本可以查找到相应的驱动文件；

4)如果用户选择了引导修复，则通过“bcdedit”、“bootsect”相关工具来对待修复的系统卷进行引导修复；

5)如果用户选择对非通用磁盘物理结构导致虚拟机无法正常启动的情况进行修复，则系统修复模块首先通过解析磁盘引导扇区MBR和活动分区的引导扇区来检测待修复的磁盘是否为通用磁盘物理结构，如果检测出该修复磁盘为非通用磁盘结构物理结构，则将其转换为通用的物理磁盘结构；

6)如果用户选择的是接管，则将用户填写的相关IP等信息写入到修复卷下的指定的文件中；

7)如果用户添加了自定义修复脚本，则运行该自定义修复脚本。

Images