本文叙述了在东方证券数据中心异构环境下，对物理机、虚拟机采用温备的方式，在私有云架构中实现统一的灾备建设管理，并通过设立独立灾备演练区，实现传统灾备演练模式由人工向自动化转型，极大地降低了灾备平台的运维成本和后期建设费用，故障恢复时间也由原来的小时级缩短至分钟级，为其他券商机构提供了可参考的项目案例。
近年来，虚拟化技术的发展，为数据中心集约建设、绿色建设的要求提供了新的应用形态。从行业现状分析，当前证券公司的灾备中心通常采用虚拟化技术，实现生产端是物理机+虚拟机，备端以虚拟机为主的服务器配置模式。其中生产端物理机和虚拟机存在两种形态：一种是应用和数据是前后端分离部署，如银行三方存管的中间件类型（无状态、无数据），数据存放在专用的数据库系统中；一种是应用和数据一体化部署，数据在本机或以SAN/NAS等形式存储。
目前，证券生产中心主要以第一种前后端分离部署为主。如果按照行业监管要求，每增加一个生产系统，灾备中心对应建立一个备份系统，那么灾备中心最终形成生产系统主备1:1的资源配置策略。根据东方证券统计，当前实际生产环境运行的应用系统超过300套，备机环境异常冗余臃肿，并由此带来一系列的运维管理问题。
例如，在备机普遍采用冷备、高可用和组等运营模式下，造成备机系统重复建设、冷备虚拟机使用率低，系统处于空转待命的状态。日积月累，造成灾备中心的硬件设备、网络资源浪费严重，并加大了运维人员的工作量。同时，根据行业监管的要求，运维人员要进行周期性应急演练确保备机系统的可用性，以保证应急时的业务连续性。但是，传统的冷备方式，存在诸多问题：
第一在资源上备机会占用跟生产系统一样的资源；
第二在实际生产应急或者应急演练时，运维人员需进行一系列复杂操作进行紧急主备切换，此时备机是否可用以及人为操作失误等问题都会影响整个应急过程以及业务连续性，且生产系统上百套，其可用性验证仅仅通过人力的话就变成了一个浩大的人力工程；
第三是备机资源池的管理，目前也仅有设备和系统管理两个维度，灾备中心运维平台缺少对备机状态、使用资源、运行情况、切换情况做统一的量化管理和资源调配，备机资源利用的高效率和数字化无法实现。
市场上有没有可以同时满足上述需求的容灾备份技术和智能运维管理平台，东方证券和英方软件经过前期的技术调研，从不同维度分析了三个常见的应用技术，并得出结果。
1.1基于存储层的灾备方案
该方案主要是用于站点级的存储容灾。其基于卷级别的数据同步，通常要求主备两端的设备是同构环境，这显然无法满足大多数券商主备两端服务器异构的环境。此外，数据同步时，复制规则对用户不透明，用户无法按需对个别服务器或指定卷进行数据复制。更为重要的是，存储厂商一般都没有整合虚拟化平台和灾备端虚拟机演练、验证的方案，需要引入虚拟化平台厂商或第三方软件结合使用，过程复杂，可行性低。
1.2基于虚拟化平台的灾备方案
该方案可以充分利用灾备服务器的物理机资源，且可以原生地支持生产端VSPHERE虚拟化平台的虚拟机备份和容灾，也可以实现隔离环境下做虚拟机备端的有效性验证和测试应用程序的数据效果。但该方案存在四个重大的弊端：
一是无法很好地兼顾物理机的备份需求，其相关的转换工具虽然能够实现P2V的转换，但功能较弱；
二是物理机每次更新应用程序时，都需要按照操作流程分发到灾备服务器投产完成版本的同步更新，一致性校验依靠手工完成，基于虚拟化平台的备份方案无法满足；
三是对于非中间件类型的业务系统，无代理备份方案无法满足对核心数据做实时复制，必须依赖额外的操作完成，如通过存储层的数据复制，或通过主机层安装代理程序的数据备份或复制；
四是扩展性较差，未来的灾备端（VMware）如果转用开源的虚拟化平台技术(OpenStack/KVM）或其他国产化虚拟化平台，备份系统的迁移存在较大的局限性。
1.3基于传统备份及快照的技术方案
该方案分为两类：一类是基于文件级或应用API的复制技术实现对生产系统的备份，同时在灾备端的虚拟化平台，提前创建环境并构建生产服务器和虚拟机之间的数据同步规则，实现虚拟机对生产系统的应用容灾；一类是基于实时P2V镜像工具，将生产系统整机实时备份成虚拟机磁盘格式，当生产系统发生故障时，可直接在灾备平台启动虚拟机实现应急容灾，主要采用数据冷备和离线快照技术。该方案存在两个问题：一是对于重要的生产服务器的核心数据，定时备份存在时间窗口，RPO无法满足业务需求；二是物理服务器每次仅限应用程序更新时，该方案无法实时地、自动地完成灾备服务器版本的同步和更新，仍然需要人工校对。
上述三种常见的技术方案，难以满足复杂异构环境下灾备中心的智能化运维需求。东方证券智能云灾备中心项目，综合利用了市场上P2V、V2V以及字节级数据复制技术等应用成果，成功解决了上述三个难题：异构环境的系统备份和恢复；大规模备份系统可用性验证的自动化操作；全局性的灾备中心运维管理平台、多维度的备机资源池统一和可量化管理及资源调配。
研发团队基于以上事实，设立了项目的目标，并严格按照项目开发流程，展开了实践方法与思路探究、原型开发、虚拟演练中心搭建测试等论证环境，测试数据显示项目具有可行性。
2.1平台概述
智能云灾备中心平台汇集字节级复制、块复制、物理机和虚拟机备份及有效性验证的相关技术和原理，实现生产中心物理机或虚拟机备份到灾备中心VMware虚拟化平台上的目的，为运维人员提供数据实时同步、系统容灾和迁移的自动化管理，实现多维度的备机资源池的可量化管理及资源调配。
该平台的管理界面是基于B/S架构的软件客户端，可安装在Windows操作系统平台上，为运维人员提供向导式和界面化的操作管理；运维人员可通过总览界面查看当前灾备中心资源池相关数据，可通过备份界面进行文件、物理机和虚拟机备份，可通过统计报表查看备份记录、统计报告，可通过虚拟演练中心进行应急演练等。
2.2平台架构方案
图1 灾备中心平台架构
2.2.1架构说明
本项目总体技术框架建立要遵循“整合资源 信息共享”、“统一架构 业务协同”的原则，应用系统采用多层架构，以多种不同的数据复制技术和资源库为基础进行开发，实现资源和服务的共享，实现业务层和展现层的分离。总体技术框架分为五个基础层级，通过有效的层级结构划分全面展现整体应用系统的设计思路。
系统层：主要包括文件系统I/O、系统API、系统监控模块、文件系统层和系统网络传输系统。
核心层：主要抽象了镜像库、网络收发库、基础库、系统跨平台封装库，用于实现基于文件系统实时复制，包括系统管理模块、字节级复制、CDP模块、高可用模块和数据库装载模块；而数据库备份库和虚拟机备份库则用于实现定时备份数据库、文件系统和虚拟机。
会话层：在ISO网络通信模式中RPC跨越了传输层和应用层；RPC使得生成应用程序包括分布式复用程序更加容易；功能模块如节点管理、复制管理、高可用管理和备份管理等，都依赖RPC实现控制服务器和被管理节点的通讯。
接口层：将调用与实现解耦，不同功能模块之间的共用，不一定是共用某段代码，也可能是共用某段逻辑框架，这时候就需要抽象一个接口层出来，再通过不同的注入逻辑实现。
应用层：本课题的软件实现，同时提供多种用户界面，包括基于Web管理、客户端管理、RESTful API或第三方集成能力；应用层实现相关引用组件包括工作流、表单、统一管理、资源共享等应用组件进行有效的整合和管理。
2.2.2设计原则
（1）算法服务采用统一自研框架为基础进行开发，独立部署、独立扩展、易于维护；
（2）方便整合，程序提供对外API，可以和东方证券的监控运维系统实现对接，统一监控。
2.2.3运行环境
适用于 X86 服务器架构；VMware VSPHERE虚拟化平台。
2.3备份技术实现方案
2.3.1字节级复制技术实现
项目团队采用了字节级复制技术实现数据的快速备份，即通过将文件系统序列化I/O操作日志实时捕获并传输到备端，在尽可能短的时间内保证了源数据和备份数据的一致性；通过保存捕获的文件系统序列化I/O操作日志，保证了备份信息的完整性，使备份复制系统可以做到I/O级别的数据复制和恢复，以提高容灾恢复的精确性和灵活程度；并依靠保存文件系统序列化I/O操作的增量数据，最大限度减少对备份存储空间的要求。
本项目实现的系统包含有规则模块、操作捕获模块、本地缓存模块、本地网络模块，以及远程网络模块。其中规则模块用于指定捕获序列化操作的文件和目录；捕获模块进行序列化操作的捕获；本地缓存模块主要解决生产机系统资源和性能之间的平衡问题；本地和远程网络模块用于并行异步的网络传输。
图2 文件备份模块
首先用户通过规则模块下发指定文件和目录的复制规则到捕获模块，来决定捕获和传递哪些指定文件和目录的序列化操作日志，这样可以对各个数据流进行策略化和并行化处理。
当应用程序在对文件系统中规则内的文件或目录的读、写等访问操作时，会通过系统API调用传递给操作系统内核处理，在主流操作系统支持下，本装置在文件系统数据通道上加载对应的堆叠式文件系统或可加载文件系统捕获模块，截获文件操作序列化的I/O操作数据流或IRP(I/O请求包)。将各个I/O操作发生的时间(when)、发起的进程(who)、操作具体针对哪个文件(which)、文件的具体操作位置(where)、操作的内容(what)组织成序列化操作日志。
在获得序列化的I/O操作数据流以后，通过内存空间地址转换管道，将数据从内核态传递到用户态。缓存模块的作用是序列化I/O操作日志产生的速度高于网络的传输的速度时，保证I/O不受影响且操作的日志不会丢失。本地缓存模块根据当前系统资源状态（CPU、内存、网络等使用情况），决定是将数据先缓存到磁盘，后期再发往网络模块处理，还是直接发往本地网络模块处理，以保证不影响本地工作机正常的生产服务。
图3 文件系统序列化I/O操作传输交互图
根据策略规则在生产机和远程的备机之间建立起网络数据通道，将序列化的I/O操作根据规则分配给对应的网络数据通道，并根据数据通道的收发情况，决定是否需要先缓存I/O操作到本地存储，而发送模块会根据序列号优先将缓存处理完毕。在每个I/O操作包上都带有操作序号和规则信息，在传递I/O操作数据时，始终通过保证I/O操作的序号来保证文件的一致性。
2.3.2物理机整机复制技术实现
整机备份和恢复需要把服务器上的操作系统及应用备份下来，在需要的时候，通过备份下来的数据将操作系统及应用恢复到原服务器上或者其他服务器上。
图4 策略创建及位图构建模块
策略创建及位图构建模块，用于对源端磁盘创建保护策略，并对源端磁盘空间进行划分，根据划分结果于驱动模块101中构建源端磁盘的位图（bitmap）。
有效数据分析模块102，用于分析源端磁盘快照的分区结构，将分区信息、启动信息所在的磁盘块读取出来，再根据文件系统的接口获取文件系统的块的位图。
数据传输客户端模块103，用于将有效数据分析模块102分析出来的磁盘有效数据传输到云端。在本项目具体实施例中，数据传输客户端模块103会对有效数据进行加密后再传输至云端20。
数据接收服务端模块202，用于将接收到的磁盘有效数据按照对应的位置写入到备份存储机硬盘中。具体地，数据接收服务端模块202于接收到磁盘有效数据后，根据有效数据分析模块102得到的位图将接收到的磁盘有效数据按照对应的位置写入到硬盘。
在本项目具体实施例中，由于在生产端需要捕捉数据变化的位置，当源端磁盘上发生数据变化时，首先需要明确变化数据所处的位置，因此设置驱动模块101位于文件系统之下和硬件磁盘驱动之上，以用来实时捕捉源磁盘上的数据变化，所述驱动模块101用于监控上层发往磁盘驱动上的I/O操作，所述驱动模块101的行为是实时性质的，即无时无刻都处于监控状态。
图5 块复制捕获监控管理架构
一般来说，读操作不会产生数据变化，因此，该技术主要获取写操作产生的数据变化。也就是说，驱动模块101会时刻监听并捕获上层发往源端磁盘驱动的写I/O，一旦获取，会立刻更新将其位图（bitmap）中对应的位置1，然后根据源端磁盘的保护策略将当前的位图（bitmap）实时或周期触发条件产生时发给备份模块102，并于成功发送之后，立刻将位图（其bitmap）原来1的位置为0。位图的每一位的值初始化为1，规定0表示对应的小磁盘空间无数据变化，1表示对应的小磁盘空间有数据变化，在初始状态，显然所有的数据都是没有同步过的，因此，会将位图的每一位的值初始化为1。
需说明的是，在策略创建及位图构建模块100构建并初始化位图后，所述驱动模块101即会根据各源端磁盘的保护策略将该位图（bitmap）传给备份模块102，同时将构建于驱动模块101中的位图（bitmap）中所有的位全部置为0，以便实时捕捉源端磁盘上的数据变化，并将其转化成位图中的位图信息。
备份模块于接收到所述驱动模块的位图时，将当前接收到的位图与前一次接收到的位图进行整合，根据整合后的位图的位图信息将源端磁盘上相应块的数据备份到备端。这里需要说明的是，备份模块102中位图bitmap的位值从1置为0的前提是：备端将该块数据成功写入到备端磁盘上，从而确保了备份的准确性。
如图6所示，假设源端为一个90MB的磁盘的物理布局，将其从空间上划分为相等的9份，每一份代表10MB的空间，位图构建模块100创建相应的位图（bitmap），在进行完第一次周期全同步之后，驱动模块101的位图上的所有位则变为0；当第一次往源端磁盘上更新一些数据，假设这些数据最终落盘在10~20M和30~40M的数据块上，驱动模块101监测到该些数据变化后，则会将位图（bitmap）上块2和块4从0变为1；当第二次继续往源端磁盘上更新一些数据，假设这些数据最终落盘在10~20M和50~60M上，若之前位图中块2对应的位仍为1（即未触发周期同步），则此时只需将位图（bitmap）中块6对应的位从0变为1即可。
图6 CBT位图变化过程
这里需要介绍CBT（Changed Block Tracking）数据块修改跟踪技术，它是VMware实现增量备份的底层支撑技术。CBT的优势在于节约空间，它允许只备份发生了修改的数据。CBT的工作原理就是让VMKernel监控自上次快照时间点依赖有哪些数据块中的数据被改变了，并记录下这些被改变的数据块的偏移量，依靠这些便宜量获取数据块中的修改数据。CBT是备份系统高效备份的关键，能显著提高备份速度，降低备份数据存储空间。
与现有技术相比，本项目实现的整机备份和恢复的系统及方法，基于块复制的周期同步系统及方法通过利用策略创建及位图构建模块对源端磁盘创建保护策略，将产生变化的I/O操作转化成位图中的位图信息传送至备份模块，由备份模块根据位图信息将源端磁盘上相应块的数据备份到备端，实现了基于块复制的周期同步目的。减少了磁盘读写资源的非必要消耗，也提高了备份的效率。驱动模块是基于磁盘块进行备份的，所以它不受文件系统的限制，可以支持各种文件系统甚至没有文件系统的磁盘也可以进行数据备份，应用面更为广泛。
2.3.3虚拟机复制技术实现
虚拟机备份和恢复，是一种直接访问虚拟化平台获取虚拟机的相关信息并完成对单个虚拟机或多个虚拟机的备份和恢复操作。
与现有技术相比，本项目设计的虚拟机备份控制装置、系统及方法通过比较多磁盘数据间差异实现备份虚拟机，以解决大规模虚拟机备份系统中因重复读取冗余数据而导致的备份速度慢，占用存储空间大，消耗过多网络带宽资源的问题。
整个系统包含了三大部分，虚拟机备份控制装置、源虚拟化平台宿主机和备份存储机。
图7 虚拟机备份架构
虚拟机备份控制装置，用于从源虚拟化平台宿主机获取需要备份的虚拟机的磁盘信息，并下发对指定磁盘创建快照任务。
源虚拟化平台宿主机，负责响应虚拟机备份控制装的查询请求并提供备份虚拟机磁盘信息，根据虚拟机备份控制装置下发的指定磁盘创建快照任务对指定磁盘创建快照以保证备份过程中母盘数据的一致性，并根据磁盘快照获得全量/增量数据传输至备份存储机。
备份存储机，根据所述虚拟机备份控制装置下发的备份指定磁盘任务，对源虚拟化平台宿主机发送的相对应的磁盘进行数据拷贝，并将已备份磁盘信息发送至所述虚拟机备份控制装置。具体实现过程如下：
虚拟机备份控制装置启动一次虚拟机备份或复制任务，通过IP网络访问源虚拟化平台宿主机获取有待备份的虚拟机磁盘信息并创建临时快照。获取的虚拟机配置信息，包括每个虚拟机所对应的磁盘列表以及每块磁盘所对应的磁盘识别符以及磁盘hash校验值或CBT变化块信息。
在上述过程中，如果是首次执行就先新建备用虚拟机，否则就直接基于已经存在的备用虚拟机。虚拟机备份控制装置根据已获得的备份虚拟机磁盘信息以及已备份磁盘信息进行比对，查找是否存在重复磁盘，若查找到重复磁盘，于获得的备份虚拟机磁盘信息中删除所重复的磁盘设备，若未找到重复磁盘，则根据比对结果形成全量备份列表或增量备份列表。
从备份存储机获取已备份磁盘信息，通过遍历查找所述备份虚拟机磁盘信息及所述已备份磁盘信息中是否存在重复磁盘识别符的磁盘设备以及磁盘数据一致性比对，删除重复磁盘设备，根据比对结果获得全量备份列表及增量备份列表，根据全量备份列表及增量备份列表下发备份指定磁盘任务。
其次，源虚拟化平台宿主机根据磁盘快照获得磁盘数据后，调用磁盘接口，将整个链上的磁盘映射为一个块设备；然后调用C语言的open函数，将块设备映射为文件指针上的磁盘地址空间；接着调用C语言的pread或fread函数，读取文件指针内的数据，循环读取：每次根据Offset偏移量读取一小部分数据，直至读取全部数据；最后调用网络收发库，将读取到的数据发送给备份存储机。
然后，备份存储机调用磁盘接口，创建一个空磁盘；然后调用C语言的open函数，将块设备映射为文件指针上的磁盘地址空间；调用C语言的pwrite或fwrite函数以及网络收发库，将通过网络收发库收到的数据循环写入磁盘：每次根据Offset偏移量写入一小部分数据，直至写入全部数据。
最后，虚拟机备份控制装置下发指令，通知源虚拟化平台宿主机删除源虚拟机的临时快照，完成本次虚拟机的备份复制任务。
在本项目具体实施例中，所述的磁盘接口包括但不限于：Qemu模拟器提供的qemu-img命令行接口；VMware提供的VDDK接口；HyperV提供的VirtualDisk接口；以及各类厂商基于上述接口封装或二次开发实现的其他接口。
2.3.4备份有效性验证的实现
通过前面的技术研究，可以实现对物理机和虚拟机的整机备份和还原。随着备份数据的增多，用户需要知道灾备中心上保存的备份数据有效性，才能确保灾难发生的时候，灾备中心保存的备份是真实可用的，恢复后的数据是准确的，恢复的应用是能正常运行的。
本项目设计和实现的基于虚拟化技术保护数据的有效性验证系统，包含源虚拟化平台和备份管理机。
图8为系统架构图，其包括：源虚拟化平台下生产虚拟机、生产网络、备份虚拟化平台下备份虚拟机、隔离网络、验证虚拟机以及备份管理机。
图8 整机备份有效性验证系统架构
整个验证过程是，在备份虚拟化平台上创建与源虚拟机相同配置的虚拟机，备份源虚拟数据到备端虚拟机，创建快照作为还原点，另外在备份虚拟化平台上，创建验证机，同时指定还原点快照文件作为当前磁盘文件，将验证机设置到隔离网络内，通过隔离网络内的管理机对验证机执行验证操作，并记录验证结果，从 而达到备份数据的有效性验证的目的。图12为本项目实施过程中创建验证虚拟机的流程示意图，其过程如下：
图9 创建验证虚拟机的流程
首先，连接备份虚拟化平台，获取待验证的虚拟机快照还原点信息。
其次，判断当前快照还原点数据是否已经执行过验证，判断方法为对比管理机内本地记录，每次验证完毕后，保存当前快照点信息到管理机内。如果当前还原点未验证，则针对当前还原点执行验证过程，获取备份虚拟机配置，调用备份虚拟化平台，根据此配置创建空磁盘的新虚拟机，作为验证机。
然后，将验证机网卡设置到隔离网络内交换机上。接下去，将备份虚拟机的快照还原点对应的磁盘文件，作为新磁盘挂载到验证机上。再者，对验证机创建快照。
最后，开启验证机，执行验证操作，记录当前还原点已经验证。图13为本项目实施过程中验证虚拟机执行的流程图，其过程如下：
图10 验证虚拟机执行的流程
首先，将创建的验证机开机。然后，在管理机上通过源生产机器的IP，访问到隔离网络内的验证机，执行命令或验证脚本，检查验证机上的应用或端口是否正常工作。执行的验证结果，成功或者失败的日志记录到管理机的统计报表中。
其次，关闭验证机，取消备份虚拟平台上注册的验证机，删除存储上验证机对应目录下的虚拟机相关文件。
最后，找到存储中备份虚拟机目录下的验证机残留的快照文件，删除这些残留的快照文件。因为验证机磁盘是关联的备份虚拟机的磁盘，所以新创建的快照文件，默认在备份虚拟机目录下。
综上所述，本系统提供的虚拟机创建和验证方法，可以很好地将验证机设置到隔离网络内，通过隔离网络对验证机执行验证操作。验证机开机不影响生产环境，IP地址无需配置，保持生产IP，无需配置网络映射关系，从而实现了全自动化有效数据验证的功能，并且可以设置自动验证脚本及策略、输出演练结果报表供企业参考和评估。验证过程中对源虚拟机备份机制无影响，可以同时执行备份任务。在实际应用坏境中是具有较实用的价值。
2.4资源复用规则引擎实现方案
平台可从业务系统维度出发，对灾备中心的相关数据资源包括镜像资源、VMDK数据、资源配置、应用环境配置进行分类数据展示。其中可以对虚拟化平台CPU、内存、存储使用资源、剩余资源和各类业务系统资源覆盖情况进行展示，对集群中每台Exsi主机的资源使用情况可以展示。
2.4.1资源复用规则
为了更好的实现资源复用，本课题设计了资源复用规则引擎，通过该引擎对虚拟化平台CPU、内存等重要资源进行动态规划，并对资源使用情况和各类应用系统资源覆盖情况进行展示。首先对公司所有业务系统的备份方式、服务时间及服务等级等相关信息进行采集，结合如部分业务系统仅在交易时间段提供服务，部分企业内部系统的系统等级不高等证券行业业务特性进行数据建模。
图11 资源分配规则引擎设计
按业务系统等级分为A、B、C三类，设置业务系统覆盖率，A:a B:b C:c，假设可用资源 x，各类业务系统所需资源 A:YA 、B:YB 、C:YC，各类业务系统实际覆盖率计算公式如下：
2.4.2基于规则分配资源
配置资源，配置备机虚拟资源所需要的CPU、内存IP访问资源，硬盘资源使用（基于现有的VMDK文件或者新建硬盘资源），定义配置所属的业务系统，定义资源使用等级并按照时间的维度进行划分。
可以根据配置的资源向灾备中心申请资源，灾备中心根据资源复用规则进行试算，符合使用要求的即完成资源的交付，并自动创建虚拟机。
基于VMDK文件创建的虚拟机，可以基于验证结果对硬盘文件的可用性进行校验；可以配置如端口访问等检查规则，并在虚拟机成功激活后按照访问规则进行验证。
图12 虚拟机启动及资源配置流程
2.5平台部署方案
本项目已在我司生产环境部署运行，界面功能清晰，统计数据精准，具体的架构部署与功能实现如下：
图13 平台部署架构
在生产区域同时包含VSPHERE虚拟化平台和生产物理机，拥有独立的计算资源池和存储资源池，涉及各类应用系统、数据库系统和中间件系统。
备份资源池，即本项目重点建设内容，通过物理服务器和存储部署VSPHERE虚拟化平台。在备份资源池提供的计算和存储资源上，通过单独的虚拟机部署智能云灾备中心的“管控平台”。备份资源池提供的存储资源通过SAN挂载到生产虚拟化平台。实际过程如下：
针对生产虚拟化平台上运行的虚拟机，管控平台通过无代理的虚拟机备份技术进行备份，采用每周全量备份加每日增量备份的策略保存到SAN协议挂载的备份资源池存储资源。当需要进行应急接管时，生产虚拟化平台可以直接加载备份资源池上的虚拟机备份副本。
针对生产物理机，管控平台通过部署代理程序的方式，完成将整机备份到备份资源池。备份过程中不影响生产物理机的业务运行。运维人员可以采用每周全量备份加每日增量备份的策略，保存到SAN协议挂载的备份资源池存储资源。当需要进行应急接管时，管控平台通过在备份资源池上提前创建的虚拟机，自动加载生产物理机保存在备份资源池上的整机备份，快速启动并完成业务应急接管。当生产服务恢复上线后，运维人员通过管控平台，可以将正在备份资源池上运行的应急接管服务器中的生产数据，实时反向同步到生产物理机，并在维护时间段完成交割将系统切回到生产物理机。
在日常的运维管理工作，运维人员还可以充分利用备份资源池上创建备份数据的验证。包括生产物理机或虚拟机的备份的有效性，通过自动化的操作方式，在隔离网络内周期性地执行整机备份的有效性和验证。执行时对原有生产虚拟化平台的备份，以及生产物理机的备份完全没有影响。
3.1系统整机保护
智能云灾备中心打破传统一对一高可用保护方式，综合了整机备份、虚拟机备份和字节级复制等技术，将物理机通过转换成可在虚拟化平台运行的VMDK文件，整机备份到VMware虚拟化平台上，虚拟机则以无代理方式备份到VMware虚拟化平台上，整个过程以准实时速度进行。在正常情况下，灾备中心的备份系统不启动，不占用计算资源，且管控平台完全基于B/S架构，操作简单，全面兼容各种服务器，备份的系统也可以恢复至其他服务器。
图14 异构平台系统备份
该方案具有极大灵活性和创新性，在生产系统发生故障的时候，运维人员点击虚拟化平台上的备份文件即可快速启动系统，降低了RTO值。同时由于备份系统属于无开机状态，无需消耗额外的IP地址，当系统接管时，IP地址自动漂移过来。更重要的是，备份文件只占用灾备中心的存储资源，不占用计算资源，减少计算资源使用。
例如100台生产系统，在灾备中心只占用100台系统的存储资源，当设置允许所有系统同时发生故障的最大概率为20%的时候，即可以减少80%计算资源的软硬件设备成本，且当系统故障恢复时，备份系统的资源释放后，可以给其他需求复用，做到资源共享，具有非常高的经济性和安全性。
3.2虚拟演练中心
智能云灾备中心通过设置专门的演练中心，在生产环境网络之外，为了解决备份系统之间IP冲突的问题，建立了私有网络作为独立的演练网络。演练准备环节，假设将生产系统A作为自动演练的目标系统，在灾备中心克隆一个备份系统A1，同时通过A1在演练环境克隆出备份系统A2。演练开始后，启动自动演练程序，可通过两种方式进行演练自动化：
一是网络验证，分两种，一种是Ping备份系统A2本身；一种是通过在演练环境创建代理网关，让备份系统A2与代理网关相互Ping；
二是自定义脚本验证，通过自定义脚本程序验证备份系统A2的可用性。
图15 生产环境与演练环境进行物理隔离图
验证演练结束时，平台会自动输出可用性验证报告。如果验证成功，则会输出成功提示，表明系统能开机运行；如果验证失败，则输出失败的原因。演练结束后，备份系统A2会自动关机，然后系统自动删除，释放资源。
该演练方案具备极大创新性和竞争力，可以在不影响生产系统的情况下，实现平台化的大规模虚备份系统的自动化验证，适合应急演练、可用性验证、测试、复盘等场景。演练平台基于B/S架构，简单易用，易维护，可降低运维人员的工作量，达到智能化运维目标。
3.3快速搭建测试/UAT环境
基于智能云灾备中心，针对已有测试环境或UAT环境的应用系统，一方面用户如需要在两个环境中部署一样的应用系统，则可通过灾备中心实现应用系统快速迁移，另一方面，如应用系统长期处于停止状态，则可释放所有计算资源，只占用存储资源，当用户需要重新部署时则可通过灾备中心直接将系统拉起。通过这种创新的做法，复用计算资源，减少重复部署应用的劳动量，提高工作效率。
3.4业务系统在线热迁移
智能云灾备中心备份方案结合了全服务器备份、虚拟化备份、块复制和字节级复制等技术，通过P2V或V2V的方式，在不停机的情况下，一键自动化将系统迁移到金桥数据中心，且迁移过程中IP地址和新增数据可实时同步过去。
图16 系统在线热迁移
本方案的系统迁移工具功能强大，自动化程度高，无需人为部署应用系统，两边数据中心无需相同的存储、硬件配置，只需要相同的操作系统，且系统迁移过程对生产系统性能影响小，不需要停机；支持上千台系统及异构硬件的迁移；支持跨云及虚拟化平台迁移；整个迁移过程可加密传输，安全可靠，实现源机与目标机的数据同步，迁移完成后可快速启动系统。
本项目从立项到原型开发、测试验证，到方案界面设计和功能实现，到最后落地部署运行，整个过程科学严谨，务实高效。在项目技术和功能实现方面，团队大胆应用新技术与新方案，成功建成了行业首个智能云灾备中心，实现异构环境下的整机和虚拟机备份，实现业务恢复RTO降低，以及应急演练和可用性验证演练的自动化，极大地降低了运维人员的工作量，并通过灾备中心基于B/S架构的管控平台，对设备和系统数量、备机状态、使用资源、运行情况、切换情况、演练验证等做统一的量化管理和资源调配，实现灾备中心的智能化运维。
实践方案具有创新性、稀缺性、实用性和参考价值，普遍适用于证券机构特别是中大型券商机构灾备中心的建设。