关于容灾备份和恢复

其实最近一直在忙于项目的用户建议书，杂七杂八的知识都要写进去一点，自己要google一番，然后理解一下；刚好需要容灾备份和恢复的内容，搜索了许多相关的网站，总算汇总了这点东西。

其实容灾包括很多内容，比如一系列应急计划如BCP,ERP,COOP,IRP,OEP,CCP,DRP等等，以及容灾的七个层次和针对这七个层次的容灾策略，还有比较严谨和系统的容灾计划，限于篇幅和能力，没敢摘录太多内容。。。

[@more@]

容灾概念

容灾是一个范畴比较广泛的概念，广义上，我们可以把所有与业务连续性相关的内容都纳入容灾。容灾是一个系统工程，它包括支持用户业务的方方面面。而容灾对于IT而言，就是提供一个能防止用户业务系统遭受各种灾难影响破坏的计算机系统。容灾还表现为一种未雨绸缪的主动性，而不是在灾难发生后的“亡羊补牢”。

从狭义的角度，我们平常所谈论的容灾是指，除了生产站点以外，用户另外建立的冗余站点，当灾难发生，生产站点受到破坏时，冗余站点可以接管用户正常的业务，达到业务不间断的目的。为了达到更高的可用性，许多用户甚至建立多个冗余站点.

从技术上看，衡量容灾系统有两个主要指标：RPO（RecoveryPointObject）和RTO（RecoveryTimeObject），其中RPO代表了当灾难发生时允许丢失的数据量，而RTO则代表了系统恢复的时间。RPO与RTO越小，系统的可用性就越高，当然用户需要的投资也越大。

成功关键

由于容灾所承担的是用户最关键的核心业务，其重要作用勿庸置疑，容灾本身的复杂性也是十分明显的，这就决定了容灾成为一项系统工程，所以我们需要制订完备的容灾恢复分析、计划、方案、设计和实施等等步骤。

设计和完成灾难备份需要以下六大步骤：

1. 确定业务要求在设计开始阶段，必须进行“风险分析”和“业务影响分析”，以确定业务要求。必须分析每个业务流程，评估在灾难事故发生时的影响，包括业务及收入的损失。

2. 确定数据处理要求当业务要求确定后，就要将其转换成数据处理语句，或者是系统设计者可以使用的资料。得到的结果将是报表式的，包括对于每个应用所需的恢复时间，最大的数据丢失容忍量，运行所需CPU、存储容量及于其他应用和数据的相关性。

3. 设计备份及恢复方案当数据处理要求确定后，就要设计备份及恢复方案。同时可能需要进行总体设计以得出成本预计，如果有更清晰的方案要求，或者可能进行更详细的设计。

4. 选择完成设计的产品完成恢复方案的设计后，就可以选择实现这个方案的产品了。有部分产品在起初的设计阶段就已经考虑到了，但在这一阶段必须选择能够协同运行以实现恢复设计方案的产品。

5. 实现备份及恢复方案现在可以根据设计完成恢复方案了。要实现这一点，必须根据备份地点作出安排，准备灾难备份计划。

6. 保持最新的解决方案实现灾难备份是一个长期的过程。不管生产中心或备份中心有什么改变，都必须执行适当的调整以保证备份方案仍然可行。

容灾方案 Disaster Recovery Solutions

Ø 基于软件的数据备份技术

数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾，主要产品有IBM DB2 HADR (High Availability Disaster Recovery), IBM Informix HDR (High Availability Data Replication)以及 Oracle Data Guard.

Ø HACMP高可靠性灾备方案

HACMP是利用网络来侦测主机及网卡的状况,搭配AIX所提供的硬盘镜像等功能,在主机、网卡、硬盘控制卡、硬盘或网络发生故障时,自动切换到另一套备用元件上重新工作; 若是主机故障还切换至备份机上继续应用系统的运行。

Ø 基于磁盘系统的PPRC数据级容灾解决方案

全称为 Peer to Peer Remote Copy，通过 ESCON 通道建立配对的逻辑卷，能够自动将源卷上的数据同步到目标卷，利用这个特性，可以实现以存储为基础的、实时的、与应用无关的数据远程镜像功能，可根据需要选择同步或异步方式。PPRC 实现较为简单，纯粹基于硬件，是无数据丢失且具有完全恢复功能的的灾难恢复解决方案，需要两个中心均配置 IBM 的 ESS。

最佳实践

基于数据库复制技术的容灾传输的是SQL指令或者重作日志文件，在新数据没有被业务系统写入存储子系统前，就被指定发送到异地备份中心的数据库进行相关处理。数据库容灾技术采用异步传输方式，通过IP网络传输，支持一个业务中心向多个备份中心的数据库进行复制的要求，或者多个业务中心向一个备份中心复制的要求。在容灾过程中，业务中心和备份中心的数据库都处于打开状态，所以，数据库容灾技术属于热容灾方式。数据库容灾技术与存储子系统的类型、业务系统服务器的平台无关，与数据库的版本有一定关系，数据库容灾解决方案具有较好的使用灵活性。

技术最简单和投资最少的容灾解决方案是基于数据库复制技术，简单地说，就是通过安装在服务器的数据复制软件，或是应用程序提供的数据复制、灾难恢复工具（如数据库的相关工具），利用TCP/IP网络连接远端的容备服务器，实现异地数据复制，所需的成本较低，用户不需更换太多现有的系统架构，也不用担心后端存储系统的兼容性问题，只须支付软件的授权费和灾备端的硬件设备费用即可。

如果是在服务器数量较多的环境下，管理上的复杂程度就会增加，整体的投入成本也会增加。它的另一个缺点是软件安装在应用程序主机上，运行时会消耗主机的运行资源，如果硬件的等级不高，就可能给应用程序带来影响。

这是一个高性价比的容灾解决方案，也是相对比较成熟的容灾解决方案。目前也是国内比较常见的容灾解决方案。但是数据库复制容灾技术只能作为数据库应用的容灾解决方案，如果需要其他非结构数据的容灾，还需要其他容灾技术作为补充。

灾难恢复

当在生产数据库系统发生灾难的情况下，此时可使用容灾数据库首先接管业务，然后进行数据的反向恢复。具体步骤为：

1. 1.生产数据发生灾难，生产端业务停止；
2.修改数据库连接字符串的指向，将数据库指向灾备中心的数据库；
3.应用系统重新连接灾备数据库，完成业务接管；
4.排除生产系统的故障；
5.启动生产系统的数据库
6.反向恢复生产系统数据
7.修改数据库连接字符串指向，将数据库指向生产中心的数据库；
8.应用系统重新连接生产中心数据库，完成业务回切。

数据库日常备份

备份是指为防止系统出现操作失误或系统故障导致数据丢失，而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够恢复数据。

容灾系统的目的在于保证系统数据和服务的“在线性”，即当系统发生故障时，仍然能够正常地向网络系统提供数据和服务，以使系统不致停顿；而备份技术的目的与此并不相同，备份是“将在线数据转移成离线数据的过程”，其目的在于应付系统数据中的逻辑错误和历史数据保存。

容灾不能替换备份。容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的用户信息表也会被完整地删除。如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份，来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。

日常备份计划

序号	备份周期	目标
1	月完全备份	每月进行数据的完全备份
2	周累计备份	每周进行数据的累积备份，自上次完全备份以来的所有新产生修改数据
3	日增量备份	每日进行数据的增量备份，仅备份上次增量备份之后新产生的数据

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8128313/viewspace-972007/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8128313/viewspace-972007/