灾难恢复计划制度

灾难恢复计划制度（精选9篇）

灾难恢复计划制度 篇1

件

2011-07-09 15:52来源:论坛论坛我要评论(0)

 摘要：本文简单的介绍了在部署灾难恢复计划时比较容易忽略那些，而忽略了这些对企业会造成怎样的损失呢？这是难以想象的，本文就为大家列出了在部署灾难恢复计划时最易忽略的九大事件。 标签：灾难恢复计划

谁都知道用有一个有效的灾难恢复计划的重要性。那么，在部署灾备方案的时候，有哪些重要的因素被忽视了?基于对数以千计的中小型用户的调查，我们列出了大家最易忽略的九件事。

1.没有考虑到可能会破坏基础设施和数据运行的所有可能性

除了显而易见的病毒，木马，蠕虫等威胁，还需要想到您所处的地理位置发生自然灾害的可能性，比如是否处于地震断层或是在洪水区，风暴多发区，或拉闸限电等等。在制定灾备计划时，一定要把这些看似与IT无关的因素也考虑进去，如果自然条件实在太恶劣，劝您可以考虑换个地方建设数据中心。

2.灾备计划过于依赖很少的某几个员工

常常看到有些企业的 灾难恢复计划依赖于某几个甚至一个IT员工，这很危险。万一如果该人由于某种原因无法工作或者刚好找不到他/她怎么办?您需要确定员工也得有“备份”，矩 阵式结构的雇员组织形式会更好的做出应急响应。而且负责灾备的员工分布的地理位置最好是分散的，以防某一地区发生重大灾害。

3.故障或灾难来临时，依靠手工流程通知工作人员

假设您的设备由于停电而终断运行，可是现场又没有人，负责灾备的IT人员怎么会知道机房停电了?您需要建立一套自动化的系统，发生灾难或者服务终断时它可以自动的通知您的IT员工。你还可以选择第三方服务，请服务商来监控您的设施并且指派受过灾备培训的专业人员来帮你执行你的灾难恢复计划。

4.未能提供充足的后备电源

如果您的机房所在地常受到断电影响，一定要购买寿命最长的、最不易受干扰而间断的电力供应。还要准备好额外的备用电池以保证业务的持续能力。

5.忘记安排哪些资源需要优先恢复

您的IT应用中，哪些是最重要的?是否有一些可以等待一两天也不会影响到业务?你需要事先安排好应用与服务的恢复顺序。比如，你可以选择首先重启您公司的电子邮件应用，然后再恢复部门文件服务器。在安排这个顺序时，你需要考虑到相关的法规遵从要求.6.未制定规范灾难恢复计划流程文档

在制订了一套灾备计划之后，您一定要把如何执行恢复计划的步骤写下来，要详细到每一个进程以及记录，描述所有系统资源的位置。这个灾备恢复步骤手册一定要多印几份，并且存储在多个不同的地方，并确保所有关键恢复人员人手一份。

7.忘记测试灾难恢复计划

确保恢复计划在有紧急状况时真的可以恢复出来!虽然这似乎是显而易见的事，但是许多企业都忽视了这一点，没有充分测试他们的灾备恢复计划。应该定期进行灾难演习，测试每种可能发生的情况，从基本的电力故障到可能导致持续几个月的重大灾难性事件。

8.密码也很难找到

虽然密码保护是数据安全的重要环节，不过还是建议您最好至少在两个不同的、安全的地方保存您的系统密码。确保一个以上的IT工作人员的人有机会进入那里，并能获得所有密码。并且，如果这些关键人员辞职了，一定要及时更改密码。

9.未能保持恢复计划的更新

您需要不断更新您的灾难恢复计划，至少一个季度要再看一次。确定调用该计划的触发点，如人员、设备、地点或应用的改变等等。这不仅有利于IT工作人员的技能保持更新，还将让你有机会发现灾备计划程序中的漏洞并优化之。

灾难恢复计划制度 篇2

Moodle是全球最流行的网络课程平台[1], 虽然它免费开源, 但在我国推广应用出现如下困境:

(1) 适用于Linux服务器, 而Windows平台难做到高并发、高性能;

(2) 缺乏MySQL数据库灾难恢复技术;

(3) 插件众多, 缺乏成熟的应用经验参考;

(4) 缺乏LAMP技术人员。

问题的第 (2) 点即Moodle信息系统安全保障最为关键, 因为应用越深入, 如果出现信息安全方面的问题, 最后损失也就越惨重, 所以, 研究解决第 (2) 点是问题的重中之重。这也是当前很多学校放弃免费开源的Moodle平台转而选择付费网络课程平台的重要原因。

2012年6月18日, 笔者架设的Moodle网络教学平台 (http://61.164.87.150:5481/) 出现数据库连接故障, MySQL数据库服务无法启动, 且显示“1067进程意外终止”, 简称6.18事件。经研究, 是因断电宕机导致innodb数据库存储引擎的数据表空间文件ibdata1损坏。如果不能完成灾难恢复, 两年来的课程建设成果将付之东流, 会对该平台的进一步推广应用带来极大的负面影响。这是一场前所未有的严峻考验。经过48小时的艰苦奋战, 终于成功完成MySQL数据库灾难恢复, 使系统恢复平稳运行。2012年12月, 该平台荣获宁波市第八届高校数学成果三等奖。

本文主要以6.18事件为背景, 提供了一份Moodle系统灾难恢复方案与应对计划, 为Moodle平台在我国的深入推广应用提供进一步的关键技术参考。

1 Moodle系统架设概况

笔者架设的Moodle网络教学平台采用WAMP架构, 即Windows+Apache+MySQL+PHP。各部件版本为:Windows Server 2003、Apache 2.2.17、MySQL 5.1.53、PHP 5.2.0和Moodle 1.9.10+。经过两年的应用实践证明, 该组合成熟、稳定、可靠, 并经过系统优化, 在Windows平台获得高并发和高性能, 很好地满足了全系1 600师生的并发访问。服务器性能优化方案如表1所示。

MySQL数据库使用innodb存储引擎的优势:

(1) innodb提供了满足ACID的事务安全型表[3], 具有提交、回滚和崩溃恢复能力;

(2) innodb支持行级锁定, 提供了最佳的并发访问功能[4];

(3) innodb支持参照完整性约束;

(4) innodb表空间文件可任意大, 单个文件突破2GB的32位Windows操作系统限制。

表1通过三种方法来提高MySQL数据库并发和性能:

(1) 增加并发连接数。设置MySQL服务器的并发连接数max_connections, 但同时必须考虑innodb数据库存储引擎的并发数innodb_thread_concurrency。如果max_connections过大, 而innodb_thread_concurrency过小, 连接上MySQL的客户端仍然需要排队待处理。innodb_thread_concurrency设置范围为0～1000。设置为0时, 则表示禁止innodb进行并发检查, 由操作系统来实施并发控制处理[5]。

(2) 使用各种缓冲池。如设定查询缓冲query_cache_size、表缓冲table_cache和存储引擎缓冲池innodb_buffer_pool_size等, 使重复查询直接在内存缓冲中命中, 使数据库操作都在内存中完成, 尽量减少磁盘慢设备的I/O操作。

(3) 还可以采用Memcached等高性能、分布式缓存服务器[6]将MySQL数据库和PHP对象事先缓存在内存中, 以避免磁盘I/O操作, 彻底释放数据库压力。这需要单独安装Memcached服务器和PHP的Memcached客户端处理模块php_memcache.dll[7]。Memcached分布式缓存服务器PHP管理界面如图1所示。

上述优化的结果使得Moodle实现了高并发、高性能。缓冲池越大, 缓冲到内存中的索引和数据就越多, 磁盘I/O也就越少, 用户获得的体验也就更好, 但同时也带来了安全风险。因为突然停电、雷击、病毒或其他意外事故引发服务器宕机时, 若缓存中的数据尚未保存到磁盘, 则会引起MySQL数据丢失甚至MySQL服务器无法正常启动[8]。

2 MySQL数据库灾难恢复

Innodb表是满足ACID的事务安全型表, 主要通过设定innodb_force_recovery的值来实现数据恢复级别。innodb_force_recovery影响整个Inno DB存储引擎的恢复状况, 它的取值范围是0～6, 0是默认值, 表示当需要恢复时执行所有的恢复操作。取值1～6中, 大的数字包含前面所有数字的影响。innodb_force_recovery取值及含义如表2所示。

如果出现MySQL服务器无法正常启动, 并弹出“1067进程意外终止”错误信息, 表空间页面就可能发生了损坏, Moodle网站彻底崩溃了。MySQL崩溃后会在C:WINDOWSPCHealthErrorRepUser Dumps下产生大容量文件, 甚至将磁盘空间都耗尽, 这时, 应先删除该文件夹下的所有文件以释放磁盘空间。

使用innodb数据库存储引擎, MySQL的data目录下的Moodle文件夹里的*.frm文件只存储表结构, 而表数据则写在ibdata1中。如果ibdata1损坏, MySQL服务无法启动。此时, 应当采用如图2所示的流程进行灾难恢复。

具体实现步骤如下:

(1) DOS命令行方式下, 进入bin目录, 运行D:MySQLMySQL Server 5.1bin>mysqld--innodb_force_recovery=4。

然后命令行窗口一直停在那里不进行下去, 不用管它了。再在任务管理器中, 可以看到mysqld.exe的进程运行着。上述命令的作用是以只读方式启动MySQL数据库服务器。这时候, 发现root账号可以登录MySQL数据库服务器了;

(2) 在DOS命令窗中, 使用这条命令, 将Moodle数据库里的所有表结构和数据都导入到Moodle.sql文件里 (假定MySQL账号是root密码是123) :

mysqldump-uroot-p123 moodle (要导出的数据库名称) >d:zzgMoodle.sql;

(3) 在DOS命令窗中, 使用下列命令删除moodle数据库:

(4) 退出MySQL客户端程序;

(5) 在任务管理器中杀死mysqld.exe进程;

(6) 将MySQL的data目录下所有文件都删除:

ib_logfile0、ib_logfile1、ibdata1、nbpt-4ebc16f457.err、nbpt-4ebc16f457.pid;

注意:ibdata1文件是innodb引擎数据库的数据保存的地方, 最好不要删除, 把它移除到一个地方留着, 另外mysql这个目录不要删除, 其他还有用的数据库目录也不要删除;

(7) 在服务中, 正常启动MySQL服务器, 发现可以正常启动, 并在数据目录下重建了上述被删除的数据文件、日志文件、错误日志文件等;

(8) 创建空数据库moodle, 使用命令:【create database moodle;】;

(9) 使用php MyAdmin-3.5.1将Moodle.sql导入到空的moodle数据库中, 所有数据表会自动重建。

3 应对计划

Moodle系统灾难是小概率事件, 一旦发生, 损失可能是致命的。为了防止MySQL数据灾难, 事先应当作一份应对计划, 因为并不是每次都能顺利恢复。Moodle系统灾难类型多种多样, 可能的灾难类型及应对预案如表3所示。

虽然针对各种灾难有相应的应对预案, 但最直接、简单、保险、且又能应付各种灾难的方法就是对Moodle系统定期进行整站二进制文件备份, 即包括Apache配置文件、PHP配置文件、MySQL配置文件、MySQL数据库目录、Moodle网站、Moodle数据目录moodledata作二进制文件冷拷贝 (即先停止Apache服务、MySQL服务后再进行拷贝) , 再异地保存备份设备, 这样, Moodle系统一旦出现问题, 就可立即采用整站拷贝备份文件的方法, 在原先服务器或新服务器上将Moodle系统恢复到最近备份状态。根据备份周期来分, 可以做日备份、周备份或月备份。备份的方法可以是手动备份, 也可以采用双机热备份。根据moodle系统各部件的特点, 采用整站手动备份和恢复是比较简便、经济的方法, 并经实践证实, 该方法是应对Moodle系统所有灾难的可靠方法。下面给出Moodle系统整站二进制文件手动冷备份和恢复的具体方法:

(1) 备份MySQL数据库, 备份前请停止MySQL服务。采用基于数据库文件的备份方式 (二进制文件备份方式) 。需要备份的文件有:

MySQL的data文件夹下的下面两个目录和ibdata1文件 (其他几个文件在下次MySQL服务器启动时会自动重建) 、Moodle数据库目录、MySQL数据库目录、其他数据库目录;

(2) 备份Moodledata整个文件夹, 该目录是Moodle系统的用户数据目录;

(3) 备份个Moodle网站程序及文件 (备份时请停止Apache服务器) ;

(4) 备份php.ini配置文件;

(5) 备份my.ini配置文件;

(6) 备份Apache安装程序中的conf文件夹。

有了上述的整站备份周计划 (或日计划、月计划) , 数据灾难发生时, 就可直接在相同环境的机器上30分钟内重建Moodle服务器并恢复服务, 从而使数据损失减少到最小程度。这样就确保了Moodle信息系统的数据安全。

基于整站备份的Moodle系统恢复方法:

(1) 架设好基本WAMP系统, 并停止MySQL服务器和A-pache服务器;

(2) 将conf文件夹、php.ini和my.ini拷贝到原先相应的位置并覆盖同名文件;

(3) 把Moodle网站程序及文件拷贝到网站www文件夹即htdocs中;

(4) 把Moodledata数据文件拷贝到原先的位置;

(5) 把MySQL数据库的data文件夹中所有文件和文件夹都删除, 并把备份的MySQL的data目录下的所有文件和文件夹都拷贝到其中;

(6) 启动MySQL服务器和Apache服务器, Moodle系统就恢复成功了。

4 结语

本文从6.18事件引出Moodle数据安全论题, 接下来讨论了为了解决Moodle高并发、高性能而带来的数据安全风险, 最后, 给出了MySQL数据灾难恢复和应对计划———Moodle整站备份和数据恢复方法。上述过程在笔者架设的Moodle网络课程平台 (http://61.164.87.150:5481/) 上得到了实践检验, 证实是可靠、有效、经济的。

虽然本文是针对WAMP架构的Moodle平台来展开讨论, 但由于Apache、MySQL、PHP和Moodle是跨平台的, 基于LAMP架构或LNMP架构的Moodle平台的灾难恢复和整站备份计划步骤与本文做法相同。

参考文献

[1]黎加厚.课程管理系统Moodle (魔灯) 在中国的发展[EB/OL].http://blog.sina.com.cn/s/blog_624df0fc0100onej.html.

[2]曾棕根.基于WAMP的简体中文Moodle架设与性能优化[J].现代教育技术, 2011, 21 (4) :136-139.

[3]罗凡, 等.MySQL中InnoDB引擎的动态存储管理[J].东北师大学报:自然科学版, 2006, 38 (1) :22-26.

[4]顾治华, 忽朝俭.MySQL存储引擎与数据库性能[J].计算机时代, 2006 (10) :8-10.

[5]InnoDB Startup Options and System Variables[EB/OL].http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_thread_concurrency.

[6]Memcached官网[OL].http://memcached.org/.

[7]Installing memcached for Windows on Apache/PHP and Xenforo[EB/OL].http://fixitwizkid.com/threads/installing-memcached-forwindows-on-apache-php-and-xenforo.8905/#post-63093.

[8]陈小辉, 文佳, 邓杰英.MySQL的体系结构及InnoDB表引擎的配置[J].福建电脑, 2009, 25 (7) :162.

砍掉灾难恢复预算，不智 篇3

灾难恢复就像一份保险，没有意外发生，这部分投资看起来像浪费; 一旦发生意外，它却可以拯救一个企业。现在取消灾难恢复的预算，决不是明智的选择。

我刚刚开完公司今年的预算会议，整整一天的时间，像是打了一场浴血的战争。会议的结果并不好，2009年，我的部门得到的预算约等于零。更让我没想到的是，公司的灾难恢复（Disaster Recovery）预算居然也被取消了。

一直以来，所有企业设计对业务至关重要的生产服务时，都会在数据库中存一个备份。可是，这似乎要到此为止了，管理团队不想再为灾难恢复系统买单了。

我始终无法想象，重要服务数据丢失有多么可怕。时至今日，也没有任何一家大公司敢冒这样的风险。但我们的管理层就敢，他们的想法是，这些备份系统中的数据可能一辈子也用不上，却要白白增加一倍的成本。所以，当他们审核支出项目，试图从中找出可以削减之处时，就把眼光锁定在了灾难恢复上。他们认为从新安装项目中剔除灾难恢复，可以节省一半成本。

但我认为，灾难恢复可以在发生意外之时挽救公司的“生命”。这就相当于购买一份保险，前期的付出可以避免后期的重大损失。如果一个公司，关键系统每瘫痪一小时就会损失数百万美元，那它就必须拥有能在备用数据库操作的能力。飓风、地震、恐怖袭击……太多的灾难会让人猝不及防。不管我们多么不希望，这些都是现实的可能，会造成毁灭性的损失，无论对企业还是对人。在灾难过后，不得不关门停业的企业还少吗？

我们公司很久以前就展开过激烈的争论，最后支持灾难恢复的一方获胜。现在灾难恢复的概念居然又遭到质疑，真是很让人失望。管理层质疑，这些服务器只有在出现问题时才会被启用，它们到底有什么价值？如果放弃灾难恢复，就可以将现有的服务规模扩大一倍，所以为什么不放弃备份服务器，把有限的预算应用到新的服务上？

这真是让人左右为难啊。

在经济不景气的现状下，能够把服务扩大一倍，的确是非常诱人的。但从专业的角度看，我想我们还是应该保持现有的服务规模，安全第一。

而且，如果现在取消了灾难恢复系统，什么时候才能重新建立呢？无论业务规模有多大，灾难恢复系统都需要多花一倍的成本。在现有的业务基础上，我们的管理层认为灾难恢复是浪费; 那么，当业务规模扩大一倍、两倍，甚至10倍的时候，他们的想法就会改变吗？

看起来，我不会得到任何新安全服务的预算了。新项目计划中没有灾难恢复的预算，我也只能祈祷不要发生意外。

灾难恢复计划制度 篇4

“非典”发生后,我国广大农村地区经历了严峻考验.虽然这一次疫情并未在农村地区广泛传播,但已经暴露出了农村在应对突发性灾难事件方面存在的严重问题.面对“非典”发生后的`严峻挑战,我国农村社会保障制度需要进行根本性的改进革新,在发生突发性灾难的情况下首先需要考虑解决农民的人身救治问题,把农民的灾难救助纳入社会保障的轨道上,依法予以解决.结合国际社会灾难救助的一般规律,今后我国农村地区社会保障改革的主要趋向是:在国家和地方财政支持下改善农村医疗状况,加强农村医疗队伍建设;加强国家对农村养老事业的资金投入,并使之制度化、规范化;建立乡村突发性灾难的社会救助制度;加强立法,对乡村危机时刻的社会治安和秩序进行有效管治;建立基层社会组织物资储备系统以应对危难时刻的群众需要;广泛开展宣传教育工作,提高群众灾难自救能力.

作 者：雷玲  作者单位：西北农林科技大学,经济管理学院,陕西,杨凌,712100 刊 名：西北农林科技大学学报(社会科学版) 英文刊名：JOURNAL OF NORTHWEST SCI-TECH UNIVERSITY OF AGRICULTURE AND FORESTRY(SOCIAL SCIENCE EDITION) 年，卷(期)： 3(6) 分类号：F323.89 C913.7 关键词：非典   农村   农民   社会保障体制  

数据中心灾难恢复的策略 篇5

1 灾难恢复策略的规划

灾难恢复是为恢复计算机系统而提供的技术保证。业界的许多经验和教训说明，灾难恢复的成功在于经过良好训练和预演的人在自己的角色上实施预先计划的策略，即灾难恢复计划。

事实上，灾难恢复计划要求有周详的事前准备，尤其是灾难所引起的对业务的冲击程度的分析，并制定相应灾难后的恢复策略，利用可行的信息技术，提出最佳的恢复方案。

在系统备份和灾难恢复计划建立以后，还必须在事前反复测试，并随时调整，加以改进，完整的系统恢复方案才能得以建立。其中灾难恢复策略在整个恢复方案中起着非常重要的作用。

灾难恢复计划是不能被忽略的重要方面，但很多用户或机构常常在灾难发生时才认识到数据恢复策略的重要性。灾难恢复策略必须仔细考虑以确保能涉及所要保存的所有类型和地域的数据，还要考虑如果一场灾难性的数据损失情况发生时，这些数据和拥有数据的系统能够被恢复。

可以按照以下步骤来制定数据恢复策略：

(1)评估用户或机构对数据流和有效数据的需要。

(2)每次数据损坏事故造成的经济损失有多大。

(3)在多长时间范围内必须成功进行数据恢复，以避免影响效益。

(4)评估数据损失的风险，确定跨部门的数据恢复策略优先级别。

(5)评估数据存储设备的所有潜在风险。

(6)使用上述评估结果制定质优价廉的安全机制，包括备份。

(7)数据损失的间接代价是什么。

(8)通过对所有的数据损坏进行预算来制定预防策略和最终的数据恢复策略。

2 主机的灾难恢复策略

以下列出通常情况下主机可能出现的几种灾难情况，并给出相应的解决措施。

(1)主机数据磁盘故障(非系统盘)：若数据盘使用了RAID l、RAID 5等技术，则可直接热替换硬盘;若数据盘已不能访问，则需先修好物理盘，然后从备份介质恢复数据。

(2)主机物理损坏(不在数据备份范畴内)：将主机数据磁盘取出，防止在维修过程中被损坏。将数据磁盘放在其他的主机上进行备份，并对主机进行维修。

(3)系统盘物理损坏：替换系统盘，通过备份系统的灾难恢复功能恢复操作系统或重新安装系统。

(4)操作系统不能启动：直接通过备份系统的灾难恢复功能恢复操作系统。例如，利用备份系统的镜像文件恢复出主机系统盘。在没有备份系统的情况下要重新安装操作系统。

(5)磁盘上数据损坏(如由于人为失误、病毒或黑客攻击)，通过备份介质上的数据备份来恢复数据，或利用数据恢复技术来找回数据。

3 文档、介质的灾难恢复策略

(1)文档及介质管理的问题：对于数据中心来说，灾难发生过后，经常出现的问题不是来自如何从磁带中将数据恢复出来，而是来自以下几个方面：

◆缺乏、甚至完全没有文档的恢复计划和措施;

◆在重新配置硬件的时候，找不到原始系统配置和设置的文档;

◆磁带文档、归档和跟踪相关资料的缺失，或不完整的磁带归档策略;

◆对部门级的服务器保护不够充分。

(2)文档及介质恢复的策略：在制定数据恢复策略时，要充分考虑到灾难发生之后影响数据恢复的几个因素，主要有以下几点：

◆文档及归档系统配置：成功的业务应用和数据恢复，始于完整的系统配置记录文档，包括随着时间的推延，系统配置被改变的日志记录。一旦这些文档被创建，至少要有一个副本被存放在异地，以防本地的文档及其副本被损坏或毁坏;

创建文档，并在异地将文档进行归档是快速并有效地重建系统的重要步骤。如果有一个可以进行裸设备恢复的方案，能够往磁盘上直接加载所记录的系统配置，为新设备提供自动重建，将会为关键应用服务器的重建提供更高的价值。

◆文档及归档灾难恢复的程序：为了确保业务的成功恢复，必须建立一个简捷有效的灾难恢复程序，以及严格按照既定的程序去建立文档，并与业务关键数据一起安全地异地保存，这样可以避免反复地恢复测试;

◆安全措施、文档及磁带介质跟踪：针对业务灾难偶发事件的恢复计划，应包括异地存放磁带及记录其磁带内容的文档的策略和程序。如果没有这些记录磁带内容的文档，在恢复时就要花大量的时间来索引和阅读这些磁带，以寻找藏于其中的重要数据。这样会大大地延误系统和数据的恢复。

根据业务需要来决定磁带异地存放的频率;磁带内容必须建档;异地保存的文档必须是安全的和易于取出的;同时，磁带必须是被跟踪的。所有这些步骤对于数据的安全保护和确保有效恢复来说都是必须的。

4 其他策略

(1)判别和保护所有关键业务的服务器：为了业务的不间断，所有运行着关键业务应用的部门级服务器，都必须被迅速恢复。在大多数个案中，并没有考虑对全都关键系统的保护，造成整体系统不能运行的尴尬局面。而事实上，这些部分应该与数据中心完全一样，在同一计划中文档化其保护程序和实施方案。

任何正在使用的服务器，以及每一台台式机和便携机，从某种意义上来说都是值得保护的。最基本的数据保护可保证某种程度上的恢复。进一步而言，裸设备恢复的方案可以确保以最少的时间和工作步骤来恢复这些系统，而且只需要少量的备份设备。

(2)在线数据保护更利于恢复：在线数据保护是数据磁带保护的重要补充，能够在灾难恢复的过程中快速地确保业务运行。要想能够在灾难发生后数小时内恢复业务，必须要有一个在线的、异地的生产数据的可用副本。只要有这样的第二个、第三个副本，数据通过网络传送到异地的存储设备上，依靠无论是嵌入存储硬件中，还是挂接在存储服务器上运行的复制技术，可以使中断在数分钟内恢复运行。由于这些数据是实时和在线的，通过业务主机重定向系统就可重新运行。这种方法可将业务运行与灾难发生的区域分开，在较低的压力下，从容地重建数据中心及其业务操作。

具有持续监控、数据连贯性和可用性的自动化工具是至关重要的，通过从大量灾难获得的重要经验，使用上述手段可以保护业务运行更可靠。

(3)建立灾难恢复中心：可以建立灾难恢复中心来及时地恢复所有的数据。所谓灾难恢复中心就是除了拥有一套完整的计算机网络系统之外，另外建立一套计算机网络系统。这套系统能在突发性灾难造成数据中心停止工作时，迅速并及时地接管原来运行在数据中心的所有或部分业务，达到减少或避免灾难事件发生时所造成的损失，提供完善、优质的服务。

灾难恢复中心有非实时和实时两种模式。非实时模式就是利用磁带备份技术，数据中心的人员每天定时备份数据，并及时送往灾难恢复中心，尽量保证灾难恢复中心拥有数据中心的最新数据，一旦灾难发生，灾难恢复中心可将业务在较短时间内恢复运作。这种模式的特点是数据备份的技术难度不大，但很难保证数据中心与备份中心间的数据实时一致。实时模式就是在数据中心和灾难恢复中心之间通过通信线路，进行数据实时备份，将数据中心主机的数据实时送往灾难恢复中心，保证数据中心和灾难恢复中心间数据一致。当灾难发生，数据中心陷于瘫痪时，灾难恢复中心将在最短的时间内接替所有或部分业务，恢复系统正常运作。

参考文献

[1]林小村主编.《数据中心建设与运行管理》.科学出版社, 2010年4月

灾难恢复计划制度 篇6

虚拟化抽象层从底层硬件分离应用，所以比起传统未虚拟环境需要更高级别的系统规划与管理。幸好，有方法克服这些虚拟化难题，更好控制环境。

虚拟灾难恢复

每个组织必须拥有虚拟灾难恢复计划预防突发事件，虽然灾难的类型与范围取决于公司的位置有所不同。

虚拟化技术本身并不是灾难恢复解决方案，但相对传统的非虚拟环境，虚拟化为灾难恢复带来了更多的选择。出于我们的目的，虚拟灾难恢复主要包括数据到外部地点的移动。

谈及虚拟灾难恢复，正确的规划是主要的虚拟化挑战之一。

管理员需要谨慎考虑数据在LAN或跨WAN如何移动数据到远程地点。虚拟灾难恢复的这个组成部分通常包括对连通性和带宽的详细评估。

在LAN架构中也包括更改，即从NAS或SAN对数据的优化。经常测试很重要，这能确保数据能恢复到主要的数据中心，或从远程站点（如DR站点）直接可用。因此，广泛的测试是虚拟灾难恢复计划的重要构成部分。

虚拟机备份与数据保护

数据保护在大多数据中心处于优先权位置，但这只是虚拟化挑战的另一方面。它能支持单个文件的实时恢复，也能在业务连续性方面发挥重要作用，能遵守法规遵从的要求。

在这里，管理员的最大问题在于如何部署适用于软件与硬件的备份工具，使得虚拟数据备份与虚拟机备份更方便。“人们假定（备份）与在物理环境一样，”EvolveTechnologiesLLC公司的CEODaveSobel说，“多数备份软件期望能访问物理硬件。但在虚拟环境不是如此。”

对于虚拟机备份，管理员通常使用快照工具和持续的数据复制来捕获虚拟机状态存到SAN，然后使用复制工具复制数据到站外存储。

涉及到虚拟环境中的数据保护与虚拟机备份，恢复也体现出一些虚拟化挑战。从虚拟机快照里来的数据颗粒恢复如果缺少合适的软件工具，就会出现问题。并不是所有备份软件都能从虚拟机里提供颗粒恢复，这迫使管理员首先恢复虚拟机，可能恢复到实验室服务器，然后提取所需的文件。至少，虚拟化能促进先前备份与恢复过程的改变。

虚拟化安全问题

虚拟化安全的最大问题在于熟知任务，如日常扫描和打补丁应该及时执行。例如，如果你有500个系统，对于管理员来说，验证这500个系统都运行的是最新的应用和操作系统很困难。

由于虚拟化安全呈现的抽象状态经常让任务管理变得混淆。管理员很容易丢失对主机操作系统与虚拟机正确更新的追踪，每个工作负载的转移让情况更加复杂，会丢失工作负载的位置。忘记打补丁或者缺乏扫描会让虚拟机或主机易受攻击。

灾难恢复计划制度 篇7

依赖云计算的银行可以在由第三方管理的服务器上租用空间，而不是使用组织内部管理服务器硬件。云计算服务有望为银行节省资金、缩短恢复时间，但是到目前为止，云计算迟迟没有得到采用，规模较小的银行在充当开路先锋。

约翰·奥勃朗(John O'Brien)是南卡罗来纳州哥伦比亚市康加里州立银行(Congaree State Bank)主管信息技术的执行副总裁，他说：“我们与灾难恢复有关的IT成本有望削减一半，恢复时间也有望缩短至三分之一。”

康加里州立银行下设两家分行，拥有1.22亿美元的资产。它在2006年就开始与佐治亚州阿尔法利塔市的安全系统公司(Safe Systems Inc.)合作，使用后者提供的托管电子邮件服务。该银行计划今年年中之前实施安全系统公司的托管灾难恢复服务：Continuum。

随后，康加里州立银行会将灾难恢复计划由原来使用该银行其中一处的冗余服务器，变为使用安全系统公司的异地服务器。

奥勃朗说：“这可以有效地利用资源，还可以帮助我们满足监管要求、履行股东的义务，即拥有一项恢复计划，以便尽快让系统恢复运行。”面向灾难恢复的云服务不但可以存储数据，还能对整个网络做镜像处理。遇到灾难，重建计算环境后，银行就能够使用连接至云服务提供商的数据链路，从远地继续运行自己的系统。一旦银行重新建好了物理站点，提供商随后可以把银行的镜像系统发送到重新建好的站点。

安全系统公司的总裁达伦·布里奇斯(Darren Bridges)说：“金融机构必须知道自己数据的确切位置。”他表示，他公司把服务器只放在两个地方(一个在佐治亚州，另一个在犹他州)。“我们知道客户数据具体放在我们安全场地中的哪个地方。”

不过，大多数银行对于远程灾难恢复服务并不感兴趣。据弗雷斯特研究公司在2010年第三季度开展的一项IT硬件调查显示，只有3%的金融服务公司表示，他们计划在今后12个月实施基于云的灾难恢复服务。7%的金融公司称，他们计划在今后一年或更晚实施这项服务。81%的金融公司表示自己没有兴趣，或者有兴趣，但未有购买云产品和服务的计划。

灾难恢复计划制度 篇8

测试亮点

●领先的性能:昆腾DXi6802在完整配置系统中和入门级配置中保持相同的16.3TB/小时的多线程企业备份吞吐量, 同时采用内嵌式重复数据删除来降低磁盘上存储的数据量。

●监控和报告:Quantum VisionR改进了对容量使用率的监控和报告, 从而节省了重复数据删除成本, 逐步提高备份和复制性能, 并且能够单点管理昆腾磁盘和磁带基础设施。

●创新、可扩展的架构:Stor NextR文件系统的智能元数据管理、专为均衡性能而优化的存储, 数据完整性检查, 以及动态磁盘池 (DDP) 技术整合在一起, 可同时提高可用性和性能, 减少数据重构时间。

●云高效与云就绪:DXi6800可支持昆腾Q-CloudR, 这将使企业机构得以充分利用基于云的数据保护和灾难恢复服务, 该服务利用昆腾重复数据删除复制来优化异地保护和恢复。

●保护虚拟环境:昆腾vmPRO?软件可无缝保护分公司和远程办公室的异构虚拟机, 并将其备份复制到中央数据中心里的DXi6802。通过以原始文件格式来保护数据, vm PRO提供极高的恢复性能。

●整体端到端数据保护:昆腾的N层架构让企业机构能够延长保留期, 充分利用合适的技术组合, 在与数据价值长期匹配的存储上安置数据。

●简单、经济实惠的可扩展性:DXi6800的“按需付费”容量许可方案让企业机构能够充分利用改平台的全面性能, 同时只为自己所需的容量付费。

●灾难恢复优化:ESG实验室发现, DXi6800支持赛门铁克NetBackup AIR (自动映像复制) , 并与其集成, 同时可缩短灾难期间恢复业务所需的时间, 并通过缩短恢复时间目标 (RTO) 而提高恢复服务水平。

支持的言论

●ESG实验室高级分析师Tony Palmer表示:“通过DXi6802, 昆腾再次开发出一个令人印象深刻的解决方案来保护任何规模物理和虚拟数据中心里的数据, 为灵活、强大、高性能的数据保护设定了新的标准。”

灾难恢复计划制度 篇9

在网络设计和实现过程中, 为用户端计算机分发和部署IP地址是一项重要而又繁重的基础工作。如果采用静IP地址部署策略会大大增加网络管理人员的工作量和增加地址冲突的几率[1]。同时在静态IP部署策略中, 对于接入控制和接入用户的身份认证是很难完成的。因此, DHCP (Dynamic Host Configuration Pro tocol) 动态主机分配协议应运而生。DHCP协议实现了客户端IP参数的自动配置, 降低了用户使用网络的技术难度, 减轻了网络管理员的工作量。如果DHCP服务功能出现问题, 将导致用户接入和用户认证无法完成[2], 特别是在无线网络的环境中, 这种影响更大。因此, 为了保证DHCP服务的可用性和可靠性, 应该采取相应的冗余策略和负载均衡策略[3]。

2、DHCP服务的部署模式

DHCP服务器既可以分散部署在每一个IP网段中, 也可以集中部署到一个IP网段内。

(1) 分散式的DHCP服务器部署

这种部署方式是在每个IP网段部署一台DHCP服务器, 这台DHCP服务器负责为本网段的客户分配IP地址。这种配置方案的实现起来比较简单, 而且DHCP服务所引发的网络流量不会扩散到其他网络。但这种配置方式并不适用于规模较的网络, 分散的服务器部署不便于配置修改和故障排除, 同时也会增加部署的成本。

(2) 通过DHCP Relay的集中式DHCP服务部署

通过在网络中的第三层交换机或者路由器上配置DHCP Relay功能, 实现对DHCP广播数据包的单播转发, 从而实现DHCP服务的服务范围从一个IP网段扩展到多个IP网段[4]。在这种部署方案中, 可以在网络中集中部署一台DHCP服务器同时为多个IP网段提供DHCP服务。DHCP服务的请求和回复数据包由途经的路由提供DHCP Relay转发。

3、传统的DHCP冗余方案

为了提高DHCP服务的可用性和生存能力, 研究者和厂商提出了不同的DHCP冗余方案以实现DHCP服务的灾难恢复功能。

3.1 RFC2131提供的冗余策略

RFC2131中提出可以在同一网段内配置多个DHCP服务器[5], 这些DHCP服务器均可对客户端提出的DHCP请求进行响应。为了避免地址分配冲突每个DHCP服务器将各自持有一个独立的地址块。客户端会根据DHCP服务响应到达的先后顺序来选择指定的DHCP服务器所提供的IP地址。

这种冗余策略存在的缺陷在于每个IP网段都需要进行DHCP的冗余配置, 增加了网络建设成本;同时由于每个服务器都需要持有一个独立的IP地址块增加了网络IP地址规划的难度。

3.2 基于DHCP Relay部署模式下的冗余策略

在这种部署模式下, 通常部署两台DHCP服务器, 一台作为主服务器, 另一台作为备份服务器。按照一定比例将可以分配的IP地址块分配给两台服务器, 常用的是80%的可用地址给主服务器, 20%的地址给备份服务器。另外还有一种DHCP冗余实现方法是, 安装一台次服务器指派与原服务器范围不重叠的地址。客户的地址请求或迁移只需从次服务器获得地址。当暂时租用时限过半时, 将更新到主服务器。这两种部署方式都需要在路由器中启用DHCP Relay功能, 同时将主、备份服务器分别作为首选和备用DHCP Relay中继对象。

上述两种冗余策略共同的问题在于主服务器和备份服务器之间没有建立联系, 对于已分配的地址不能进行监控和数据交换;客户机在进行DHCP服务器转换时会出现地址变换问题, 会对客户机上的用户进程的运行产生影响;由于地址块要划分成两个部分, 增加IP地址规划的难度。

4、基于DHCP Failover协议的DHCP灾难恢复技术

为了解决传统DHCP冗余技术所存在的局限, IETF提出了DHCP Failover协议草案[6]。DHCP Failover提供与传统DHCP冗余策略不同的灾难恢复方式。

4.1 DHCP Failover协议的基本原理

DHCP Failover提供了一种高可靠性的DHCP服务, 允许配置两台冗余工作的DHCP服务器, 共同管理同一个IP地址池。如果其中一台服务器出现故障, 另一台服务器可以无缝接管它的工作, 同时允许已经建立租约的DHCP客户端继续持有和更新它们的IP地址租约。客户端在请求地址是不需要知道是哪台服务器在响应请求。即使主服务器已经停止工作, 这些客户端仍可以继续工作。

DHCP Failover协议中, 主服务和备份服务器之间通过建立TCP连接来实现共同维护同一个IP地址池的目的。主、备份服务器之间通过互发侦测数据包来检测彼此之间的通信状况, 从而确定当前的工作模式。服务器的工作模式主要有三种[7]:标准模式 (NORMAL) 、通信中断模式 (COMMUNICATIONS-INTERRUPTED) 、伙伴宕机模式 (PARTNER-DOWN) 。在这三种模式下, 主、备份服务器会有不同的地址租用管理方式。

4.2 DHCP Failover的部署模式

在DHCP Failover协议下, 可以根据网络的不同情况采用多种灵活的部署模式。

1.简单服务器备份模式。在此模式下配置主服务器和备份服务器各一台, 备份服务器提供对主服务器上的所有地址区域的故障恢复功能, 如图1 (a) 所示。

2.多主服务器备份模式。在此模式下配置多台主服务器和一台备份服务, 备份服务器提供对各台主服务器的所有地址区域的故障恢复功能, 如图1 (b) 所示。

3.同步服务器备份方式。在此模式下, 配置两台互为备份的服务器, 同时为对方所管理的地址区域提供故障恢复功能, 如图1 (c) 所示。

5、结束语

为了确保接入控制和用户接入认证等网络的基础功能的有效实施, 必须保证网络中DHCP服务的高度可用。DHCP Failover协议实现了DHCP服务器的高效冗余, 提高了DHCP服务器的容灾能力。在工程实践中, Cisco公司的Network Registrar (CNR) 系统, ISC (Internet Software Consortium) 提供的开源DHCP软件, Alcatel-Lucent公司的VitalQIP均采用了DHCP Failover协议来实现DHCP的灾难恢复。DHCP Failover采用了DHC加载平衡算法作为负载均衡算法, 因此下一步的研究将围绕如何实现DHCP冗余的前提下提高负载均衡效率来展开。

参考文献

[1]林泽东等基于改进DHCP服务器的校园网IP地址管理方法福建电脑2009年第10期

[2]徐润沁等基于DHCP+接入认证系统的技术浅析计算机系统应用2009年第5期

[3]李莉敏DHCP技术及实现DHCP冗余电子科技2005年第4期

[4]杭州H3C通信技术有限公司DCHP技术白皮书www.h3c.com 2008年

[5]Droms, R.:Dynamic Host Configuration Protocol.RFC2131 (DraftStandard) Updated by RFCs 3396, 4361 (March1997)

[6]Droms, R., Kinnear, K., Stapp, M., etal.:DHCP Failover Protocol (March2003) http://www3.ietf.org/proceedings/03mar/I-D/draft-ietf-dhc-failover-12.txt