服务器灾备方案

服务器灾备方案（精选6篇）

篇1：服务器灾备方案

服务器灾备方案

一、服务器灾备的目的

服务器灾备计划就是在平时对服务器的重要数据、数据库、配置文件、应用服务等做备份，为了在发生重大灾难或者事故后，能尽快将原服务器中重要的数据、数据库或者应用服务等恢复出来继续给客户提供服务。

※本方案适用于基于Windows操作平台下的服务器。

二、主要的服务器备份方式

按备份系统的准备程度，可将其分为冷备份、温备份和热备份三大类。

备份系统未安装或未配置成与当前使用的系统相同或相似的运行环境, 应用系统数据没有及时装入备份系统。一旦发生灾难，需安装配置所需的运行环境，用数据备份介质（磁带或光盘）恢复应用数据，手工逐笔或自动批量追补孤立数据，将终端用户通过通讯线路切换到备份系统，恢复业务运行。优点：设备投资较少，节省通信费用，通信环境要求不高。缺点：恢复时间较长，一般要数天至1周，数据完整性与一致性较差。将备份系统已安装配置成与当前使用的系统相同或相似的系统和网络运行环境，安装了应用系统业务定期备份数据。一旦发生灾难，直接使用定期备份数据，手工逐笔或自动批量追补孤立数据或将终端用户通过通讯线路切换到备份系统，恢复业务运行。优点：设备投资较少，通信环境要求不高。缺点：恢复时间长，一般要十几个小时至数天，数据完整性与一致性较差。

备份处于联机状态，当前应用系统通过高速通信线路将数据实时传送到备份系统，保持备份系统与当前应用系统数据的同步；也可定时在备份系统上恢复应用系统的数据。一旦发生灾难，不用追补或只需追补很少的孤立数据，备份系统可快速接替生产系统运行，恢复营业。优点：恢复时间短，一般几十分钟到数小时，数据完整性与一致性最好，数据丢失可能性最小。缺点：设备投资大，通信费用高，通信环境要求高，平时运行管理较复杂。

在计算机服务器备份和恢复中，冷备份服务器（cold server）是在主服务器丢失的情况下才使用的备份服务器。冷备份服务器基本上只在软件安装和配置的情况下打开，然后关闭直到需要时再打开。

温备份服务器（warm server）一般都是周期性开机，根据主服务器内容进行更新，然后关机。经常用温备份服务器来进行复制和镜像操作。

热备份服务器（hot server）时刻处于开机状态，同主机保持同步。当主机失灵时，可以随时启用热备份服务器来代替。

冷备份

温备份

热备份

三、服务器灾备的计划

对于基于Windows操作平台下的服务器，因为服务器功能、角色各不相同所以需要有不同的灾备计划来实现所有服务器的灾备方案。接下来就按服务器的功能与角色分类，来进行不同的灾备计划：

（一）IIS：WEB应用服务器

基于IIS的WEB服务器可以使用冷备份、温备份和热备份。我们的建议是使用冷备份或温备份，在另一台服务器或者虚拟机上搭建相同的IIS环境，可以定期将生产环境下的IIS配置文件和数据文件导入到备用环境中。如果生产环境下的IIS服务器出现问题无法使用时，直接切换到备用的IIS服务器上就可继续为客户提供WEB应用服务。

（二）SQL：数据库服务器

SQL Server上的数据库可以使用冷备份、温备份和热备份。可以使用另一台服务器或者虚拟机搭建起一套环境相同的SQL，然后将生产环境中的SQL上的配置文件、数据文件等导入备用SQL中。如果生产环境下的SQL Server出现问题无法使用时，直接切换到备用的SQL Server上就可继续为客户提供数据库服务了。还可以使用2台服务器同时连接存储设备做群集，将数据库中的数据文件放在群集中。这样当其中一台SQL Server出问题不可用的时候，管理员不用做任何操作，群集将会自动切换至另一台SQL Server上。

（三）AD：活动目录服务器

活动目录服务器可以使用温备份和热备份。我们的建议是使用热备份，建立多个域控并开启所有域控的全局编录功能，让彼此之间相互复制域信息。这样在某一台域控出现问题不可用的时候，其他域控制器会自动取代它的功能为域用户提供服务。

（四）DNS：域名服务器

活动目录服务器可以使用冷备份，温备份和热备份。我们的建议是使用热备份。建立多个DNS服务器，彼此之间开启区域复制，并且客户端需要设置多个DNS服务器的指向。这样在某台DNS服务器出现问题不可用的时候，客户端所指向的其他DNS服务器能继续为客户端提供DNS服务。

（五）ISA：防火墙及代理服务器

ISA服务器可以使用冷备份和温备份。另找一台服务器搭建ISA，然后将原生产环境下的ISA服务器中的配置和一些规则导入到备用ISA中，当ISA出现问题不可用的时候，将备用ISA启动起来配置完成后就可继续工作了。

（六）Exchange：邮件服务器

Exchange可以使用热备份。Exchange服务器的备份主要是针对邮箱存储这个角色进行的，推荐使用2台服务器同时连接存储设备做群集，将用户邮箱数据储存在群集中。这样当其中一台邮箱角色出问题不可用的时候，管理员不用做任何操作，群集将会自动切换至另一台邮箱角色服务器上。

（七）SCOM：用于服务器监控的平台

SCOM可以使用冷备份。可以使用另一台服务器或虚拟机作为备用SCOM服务器，当生产环境下的SCOM出问题不可用的时候，可以将备用SCOM启用起来。

※不过受原来那台SCOM监控的那些服务器必须重新更改代理的配置指向新的SCOM服务器，以便于接受新SCOM服务器的管理和监控。

（八）SCVMM：用于管理虚拟化的平台

SCVMM可以使用热备份。可以使用另一台服务器或虚拟机作为备用SCVMM服务器，当生产环境下的SCOM出问题不可用的时候，将虚拟机的资源转移到备用SCVMM上即可。

※对于基于Hyper-V的虚拟机灾备办法：

1、可以在平时将虚拟机的硬盘文件和虚拟机配置文件备份到异地，在虚拟机不可用的时候直接用备份的虚拟机硬盘文件和配置文件将虚拟机重建。

2、如果虚拟机是在SCVMM的管理下，那也可以通过SCVMM转移到可用宿主机上进行恢复。

（九）MOSS：自动化办公平台

MOSS可以使用冷备份、温备份或热备份。可以使用另一台服务器或虚拟机作为备用MOSS服务器，定期将MOSS上的配置文件和数据导入到备用MOSS服务器中去，当生产环境下的MOSS服务器出问题不可用的时候，可以将备用MOSS服务器启用起来。（这是针对于MOSS服务器上数据量较少的方案。）数据量较大的还是建议，使用2台服务器同时连接存储设备做群集，将MOSS中的数据文件存在群集中。这样当其中一台MOSS出问题不可用的时候，管理员不用做任何操作，群集将会自动切换至另一台MOSS服务器上。

（十）DPM：用于备份和恢复的服务器

※以上这些基于微软产品的文件、软件和平台等还都可以通过DPM来进行备份和恢复。DPM本身也可以备份自己服务器上的数据库和文件，我们建议让DPM服务器连接存储设备，将DPM备份的那些数据存在存储设备中。当DPM出现问题不可用的时候，可以重新搭建一台新的DPM来识别存储设备中的那些备份文件。

篇2：服务器灾备方案

来源：中国计算机报

2010年08月24日11:44 我来说两句(0)复制链接 打印

大中小

作者：郭涛

企业只要投巨资建设了灾备系统，以后就不会再出现业务中断和数据丢失了吗?其实，灾难备份/恢复与业务连续性有很大的差别，不能将两者混为一谈。“对灾备的错误认知是导致灾备建设失败的重要原因。”EMC公司资深业务连续性咨询顾问许瑀表示。

容灾不等于业务连续性

一些企业领导的固有思维是：容灾与业务连续性是一回事，只要拥有了灾备系统，就不应该再出现业务的停顿。其实，灾难备份主要用于应对较大的灾难事件，而不是针对局部的事故。业务连续性的概念更宽泛，无论是局部的故障，还是重大的灾难，都不能使业务中断。

许瑀表示：“灾难备份是业务连续性的基础，是企业多层次信息保护体系的重要组成部分。为确保业务连续性，企业应优先考虑建设基本的灾难备份和恢复系统。在„9·11‟灾难事件中，美国世贸中心里数百家没有灾难备份系统的公司彻底消失了。这充分体现了灾难备份作为企业信息架构基础组成部分的重要性。在建立了完善的灾备系统后，企业可以考虑构建多层次的信息保护体系，进一步提升业务连续性水平。”

由于投入的资金数量不同，信息基础设施的状况不同，灾备建设的思路不同，不同行业的用户在建设灾备系统时，很难遵循一个统一的策略。不过，企业在建设灾备系统时应遵循这样一个原则，即无论采用何种技术手段，都必须保证数据的安全。这是灾备建设的底线。

重异地灾备 轻本地保护

“实际上，导致信息系统出现中断，97%的原因是物理设备故障和系统的逻辑错误，只有3%的业务中断是由大灾难引起的。”许瑀分析说，“本地数据保护与异地灾难恢复都非常重要。有的用户认为，只要建设了异地灾难恢复系统就能抵御所有的灾难，因此忽视了本地的数据保护。这其实是一个误区。”

许瑀举例说：“某用户的磁盘出现故障，由于换盘时的错误操作导致了核心数据库的损坏。该用户利用本地备份系统恢复数据，恢复时间长达一周，而且丢失了两天的数据。”有用户盲目追求过高的异地灾难恢复RTO和RPO指标，要求RTO小于4小时，RPO小于15分钟。但事实上，该用户在进行本地数据恢复时，RTO大于1天，RPO为24小时。用户投巨资建设灾备系统，却不能减少因本地故障带来的损失，这其实是本末倒置。许瑀认为，只有将信息系统的本地数据保护和异地灾难恢复相结合，才能构成完善的业务容灾体系。本地数据保护与异地灾难恢复防范的风险不同，因此采用的技术手段、机制和措施也不一样。有些需要面向公众提供服务的系统，对灾难恢复的时间要求十分严格。但是大多数信息系统对灾难恢复等级的要求并不太高，通常可以接受几小时的灾难恢复时间。对于大多数用户来说，最重要的不是恢复时间的长短，而是数据能够100%被恢复。

RTO、RPO指标过高

在建设灾备系统的过程中，RTO和RPO是两个非常重要的指标。那么，RTO与RPO的数值是不是越小越好呢?“某银行针对其网上支付业务建设灾备系统时，提出系统恢复时间小于30分钟(即RTO小于30分钟)，只能丢失5分钟的数据(即RPO小于5分钟)。”许瑀表示，“我看到用户的RTO和RPO指标要求时，第一感觉就是这不现实。因为银行的系统出现故障后，为了恢复数据，技术人员通常要根据日志对活动账号进行分析，而所有的日志分散在多个业务系统中，处理这些日志可能要采用手工方式。完成上述一系列步骤，银行至少要花费一两个小时的时间。”

企业在制定灾备恢复的目标时，一定要从业务的实际需求出发，不能盲目追求过高的RTO、RPO指标。过高的RTO和RPO指标不仅会增加灾备建设的成本，而且会让用户迷失在数字游戏中，对业务的保护无益。

忽视日常的运维管理

“2007年，某公司的核心业务系统发生意外宕机，多个关键业务数据库瘫痪。公司领导决定启用同城灾备系统。但是在进行恢复时，技术人员发现，容灾端数据严重滞后于生产端数据，灾备系统根本无法启用。”许瑀举例说，“事后，人们在追查原因时发现，由于系统管理员在进行灾备端测试时中断了灾备数据的复制关系，测试完成后又忘记了恢复灾备数据的复制关系，从而导致灾备系统无法启用。”

在某些企业中，灾备系统完全成了摆设。平时，这些企业的技术人员不对灾备系统进行定期检查，而且忽视了灾备演练。因此当灾难发生时，灾备系统很难发挥作用。中金数据系统有限公司高级副总裁陈天晴告诉记者，他们曾经按照合同要求为某客户提供灾备演练服务，但是客户的相关人员总以工作忙为由推脱，造成服务合同迟迟不能履行。许瑀表示：“企业在建成灾备系统后，应该定期进行灾备演练，并建立完善的业务连续性计划(BCP)，包括详细的灾难恢复计划及本地恢复计划等。

篇3：灾备系统建设方案及实现

关键词：灾备,数据集中,业务连续性

引言

一般来说, 灾难的发生是不可避免的, 只是机率有大有小, 而灾难备份是一个持续性的过程, 伴随信息系统正常运行的整个生命周期。

引起灾难的因素很多, 目前对于其定义也是众说纷纭, 没有统一的认识。在这里将灾难定义为部分或全部的计算机软硬件设备、附属设备、文档表格或机房环境损坏以至于严重影响数据处理中心正常运行的事件, 它可能由于自然灾害、突发事件、设备故障及人为因素等造成。灾难备份是指利用技术、管理手段以及相关资源确保既定的关键数据、关键数据处理系统和关键业务在灾难发生后可以恢复的过程。

一个完整的灾难备份系统主要由数据备份系统、备份数据处理系统、备份通信网络系统和完善的灾难恢复计划所组成。在灾难备份系统建设中, 数据备份是关键, 如何将数据 (包含系统、应用和业务等数据) 完整地实时复制到灾难备份中心, 是灾难备份建设中需要重点考虑的事项。目前有两种主要的方式, 一是基于磁盘系统的硬件方式灾难备份技术, 二是软件方式的灾难备份技术。

我们的信息化建设模式采用了数据集中存放、集中处理的全省大集中模式。这种模式在加强账务监管、实现数据共享、创新业务开发和降低运营成本等方面体现出巨大的优势。然而, 数据全省大集中模式对核心业务系统的稳定性也提出了更高的要求:一旦数据中心发生毁灭性灾难, 受到影响的将是全辖范围内的全部分支机构和几乎所有业务, 必将造成巨大的经济损失和声誉损失, 严重的会造成客户流失, 甚至有可能引起社会的不安定。因此, 我们建设灾备的目的就是要确保数据安全和核心业务系统不间断运行, 提高核心业务系统风险防范能力, 降低企业运营风险, 将损失降低到可接受的程度, 提升管理和服务质量, 增强银行的核心竞争力。

1 建设原则和阶段目标

我们的灾备系统应按照“统一规划、分步实施、平战结合”的原则进行建设。

坚持统一规划原则。要统一标准, 明确需求, 建立健全与灾备建设相匹配、符合国际标准和行业规范的技术标准和规章制度。要使灾备建设在投资规模和风险控制两个方面上达到平衡可控, 为业务连续性提供保障。

坚持分步实施原则。要将灾备建设的总体目标, 细化分解为多个阶段性目标和任务, 实行边建设, 边总结, 边发展的方式, 在阶段性建设过程中不断完善IT治理结构, 从组织与制度上保证灾备系统建设的连续性和完整性, 确保总体目标的最终实现。

坚持平战结合原则。要保证灾备中心的系统平时可以得到充分利用, 数据实现共享, 能够利用灾备系统提供的高性能主机资源、存储资源为我们提供更大的处理能力。实现灾难时为灾备中心, 平时为测试中心和培训中心。

整个灾备系统的建设计划分为三个阶段:

第一阶段首先在同城实现核心系统、生产数据的集中异地备份, 全面实现数据级备份;柜面、综合前置、银联、现代支付等核心系统的应用级备份。

第二阶段在同城分步实现全部业务的应用级备份, 实现测试、培训环境的综合使用。

第三阶段在异地建设能实现全面数据级备份;柜面、综合前置、银联、现代支付等核心系统的应用级备份。通过演练、评估灾备系统切换, 完善应急体系和应急管理, 逐步减少数据丢失量和系统恢复时间, 最终达到五到六级的灾备水平。需求分析数据的集中带来了风险的集中, 一旦省中心发生灾难将造成难于挽回的损失, 灾备系统建设是迫在眉睫。同时, 灾备系统建设是一个投资大, 见效慢, 结构复杂的系统工程, 必须经过科学的规划和论证, 做到既要能够快速接管生产又要充分利用设备资源。因此在系统设计上我们必须要同时解决以下三个问题, 即全省核心业务系统的灾难备份问题、全省集中性的测试培训系统建设问题和备份数据异地保存的问题。要通过一个方案解决三个问题, 就必须从设备选型、切换策略制定和网络规划上进行统一考虑, 合理分配资源、充分利用资源和有效管理资源, 真正做到花一样钱, 干三样事儿。

2 设备方案

在灾备设备的选型上, 主要考虑了资源配置的灵活性和设备维护的简化性。设备数量少, 结构简单, 可以减少机房空间的占用, 降低能源消耗, 为异地机房的选址提供了更多的可能。因此, 采用了新购置1台IBM I570主机, 划分6个动态LPAR分区 (其中1个OS400分区, 5个AIX分区) , 主机资源可以在各分区间动态调整;另新购置一台IBM DS5300存储, 连接570主机, 磁盘容量配置为30TB。按照每个分区的数据量分配相应的独立存储空间。由于灾备中心本身就是为小概率事件准备的, 主备中心同时发生故障的概率更小, 因此灾备中心没有必要配置双机系统, 采用单机方式完全能够满足要求。

核心系统的灾备环境使用一个OS400分区, 在DS5300上划分15T的存储空间建立2个ASP分别用于生产和测试, 按照生产环境配置要求, 安装操作系统和数据库, 建立与生产环境相同业务子系统。同时安装OMS数据同步软件, 并加入到生产主备机系统中, 同步内容与生产备机相同。灾备系统的处理能力是现有的生产环境的70%, 可以在灾难发生时承担起全省核心业务存、贷、汇的处理。

柜面业务系统使用3个AIX分区, 每个分区处理能力与现有生产环境相似, 可以承担全省所有终端的接入。各分区上安装与生产环境相同的操作系统和数据库, 参数配置也与生产环境保持一致。当生产柜面前置系统升级时要同步升级灾备系统中的柜面前置系统。

银联、ATM前置和支付系统各采用1个AIX分区, 安装与生产环境相同的操作系统和数据库, 参数配置及调优和程序升级也与生产系统同步进行。在灾难发生时承担银联、ATM前置和现代支付的业务处理。

3 测试培训系统的实现

在核心系统使用的OS400分区上建立测试和培训子系统, 使用单独的ASP存储区域, 按照测试和培训的要求建立库表和基础数据。平时灾备环境中启动OMS子系统和测试培训子系统, 由于各子系统使用的是自己专用库表, 因此测试培训对OMS数据同步不会产生任何影响。所有AIX系统分区中, 生产系统的用户与测试和培训环境的用户分开设置。平时生产系统用户封闭, 密码上收省中心, 测试及培训用户启用。当灾难发生或进行灾备切换演练时, 只需将培训测试子系统停止, 将生产子系统启动, 并按照制定好的切换流程修改相应的地址和参数, 即可实现灾备系统的切换。由于各环境间的资源可以实现动态调配, 因此可以满足不同测试内容和培训规模的要求。

4 数据集中备份的实现

按照数据集中备份的要求, 生产系统在实现本地数据集中备份后, 还需进行备份数据异地存放。在灾备系统中IBM DS5300可以与生产环境的DS8300存储实现存储级的数据异地备份体系。充分利用磁盘阵列复制技术, 配合使用集中备份管理系统, 可以实现生产环境中各种数据自动备份到异地, 在灾难发生时可有效减少数据丢失, 缩短系统恢复时间。具体为将灾备环境下的DS5300中剩余的15TB的存储容量分成两部分, 一部分用于AIX系统的外置存储, 大小约2TB;另外的13TB空间通过存储软件的管理做为数据备份空间使用。

参考文献

[1]周亚清, 王全刚.中小金融机构的灾备方案选择[J].金融电子化, 2008.[1]周亚清, 王全刚.中小金融机构的灾备方案选择[J].金融电子化, 2008.

[2]于锡强.金融交易系统的灾备技术研究[J].硅谷, 2008 (15) .[2]于锡强.金融交易系统的灾备技术研究[J].硅谷, 2008 (15) .

篇4：服务器灾备方案

灾难恢复软件的应用十分广泛，预计2015年市场规模将达到400亿美金，其中基于云的灾难恢复市场规模可达40亿美金。DataGardens的目标用户为云计算数据中心，以及拥有分支机构、并对业务稳定性有核心需求的大中型企业。目前主要客户包括加拿大皇家邮政、Savvis云托管提供商和Care Factor（加拿大领先的数据中心）等。

相对于其他商家，DataGardens的竞争优势在于：首先，其产品是基于软件的，没有对硬件的依赖性；其次，它兼容所有的操作系统以及基础设施；最后，软件十分易于安装，在进行同步或数据迁移时只需几十兆带宽，比竞争对手要低很多。目前DataGardens正在筹建中国分公司，预计到今年第4季度将建立本地的技术支持、研发团队以及服务团队。

创新中国现场提问：

评委：第一，如何取得用户信任是很重要的问题。第二，跟其他同类软件相比，你们的产品效率如何？

篇5：服务器灾备方案

本文结合国土资源部数据中心现状，分析研究了实现同城灾备的技术方案，即同步传输方案和异步传输方案，以及这些技术方案的技术实现层面：存储层、主机层和数据库层。在此基础上，本文进一步分析了两种方案的技术框架、设备组成和技术特点，并对两种方案在数据安全保障、对生产系统影响、传输距离和带宽要求和应用场景等方面进行了对比，为今后同城灾备中心建设提供了思路。引言

在“十一五”期间，随着国土资源行业内诸多调查评价工程的开展和信息化建设的推进，国土资源部数据中心积累了大量的数字化成果，这批成果越来越多地应用于国土资源部各类业务系统中，成为国土资源管理和国家宏观决策的重要信息参考来源。

另一方面，随着存储与应用服务等计算机硬件设备的增加，来自硬件设备本身、机房环境、人为操作和外界不可预知的风险及不确定性也随之增加，造成数据丢失或业务的突然中断，给国土资源管理带来重大不便。因此，保障国土资源数据安全和业务系统稳定运行是今后数据中心首先要考虑的问题。现状与需求

2．1现状

目前，在国土资源部数据中心已经建立了基于SAN架构的内网核心存储备份系统，管理着支撑电子政务平台和综合监管平台等重要业务系统的数据源，该架构下的存储备份体系框架图如下所示：

数据中心的存储设备由两台磁盘阵列组成，分别是HDS 9980V和HDS USPV，通过两台Brocade 24000光纤交换机与生产主机、存储备份服务器和磁带库连接组成存储局域网(SAN)，存储备份软件采用Bakbonenetvauh实现众多应用系统数据的定期备份。目前的存储备份体系解决了在数据中心内部出现单点故障的情况下数据的安全问题。

点击图片查看大图

图1 国土资源部数据中心内网存储备份体系示意图 2．2 需求

为了解决在部数据中心发生整体灾难的情况下数据安全问题，需要在同城某地机房选择建立一个数据备份中心，把部数据中心重要业务系统的数据备份到灾备中心，在生产中心发生灾难的情况下，实现数据的可恢复和可使用，在有限的投资和管理成本下，实现最小程度的数据丢失。实现方案

在同城实现数据灾备有两种方式可供选择，一是数据同步传输备份方式，二是数据异步传输备份方式。数据同步传输备份方式，就是通过容灾软件将本地生产数据通过某种机制复制到异地，在异地建立起一套与本地数据实时同步的异地数据。数据异步传输备份方式则不要求备份数据与生产数据实时同步。

在实现方法上，目前可以操作的层面有三种，一是存储硬件本身，就是通过盘阵自带的软件模块实现两端的数据传输，如EMC的SRDF、HDS的UR和TrueCopy、IBM的PPRC等；二是应用主机层面，通过应用主机进行两端的数据传输，如IBM的XRC软件、Bak—Bone的NetVauh Replicator和Veritas的VVR软件等；三是数据库层面，通过数据库的相关模块实现两端的数据传输，如：Oracle的Data Guard和SQL Server的Mirror等。这三种层面的数据传输都可以实现同步和异步的方式。

基于存储硬件本身的同城灾备需要两端的磁盘阵列为相同类型，而且在两端部署统一版本的数据传输软件；基于主机的数据传输则需要在两端各部署一台主机，在主机上安装数据传输软件，而不要求两端的磁盘阵列为相同类型；而基于数据库的数据传输则要求数据库类型一致，对主机和磁盘的依赖较小。方案对比

实现同城异地的数据灾备，根据数据传输的方式，分为同步传输方案和异步传输方案两种，两种方案对传输链路、配置硬件和数据安全保障方面都有一定的区别。

4．1同步传输方案

同步传输方案由于两端对数据传输

的实时性要求比较高，一般采用光纤链路实现生产中心和灾备中心的数据传输。同步传输方案的示意图如下(图2)：

点击图片查看大图

图2 基于光纤链路的同步传输方案示意图

在同步传输方案中，除了租用光纤链路之外，还需要在生产中心和灾备中心部署以下软硬件设备：

磁盘阵列：如果采用基于磁盘阵列的容灾软件，则需要在灾备中心部署与生产中心同类型的磁盘阵列，两端分别部署容灾软件；如果是采用基于主机和数据库的容灾软件，则不需要部署相同类型的磁盘阵列。管理、测试与验证服务器：部署在灾备中心，用来管理、测试与验证备份数据，不一定与生产中心完全相同，但是需安装相同的应用系统、数据库系统、中间件等。

密集波分复用器(DWDM)：需要在生产中心和灾备中心各部署一个，实现备份数据的多波段传输。

4．2异步传输方案

异步传输方案可以采用与同步传输方案相同的架构(如图2所示)，只是容灾软件设置的数据传输方式不同。

另外，http:///zixun/异步传输方案由于对传输速度的要求不像同步传输那样苛刻，可以采用以太网络传输，因而不受距离的限制。采用以太网络传输的异步备份方案如图3所示：

硬件配置方面，由于采用了以太网链路传输，需要在生产中心和备份中心两端各部署一台FC和IP转换的路由器，而不是密集波分复用器(DWDM）。其他硬件设备可参照同步传输方案配置。

点击图片查看大图

图3 基于以太网的异步传输方案示意图

4．3方案对比

采取同步或异步的备份方式，需要根据业务系统应用特点、需要备份的数据量和投资成本来综合考虑。除了本身传输方式的区别以外，采取同步或异步的数据备份方案，还存在以下几个方面的区别。

数据安全保障方面。同步传输备份方案在最大程度上保障两端的数据一致，在一定的距离内做到了数据的零丢失；异步传输备份方案由于存在一定的时间差，会有一定程度的数据丢失，数据丢失量是依据传输策略制定可控的RPO(数据恢复点，例如2小时、4小时、12小时等)，RPO值设置越小，数据丢失越少。

对生产系统的影响。同步传输备份方案会占用生成系统的I／O，降低生产系统的性能，异步传输备份方案对生产系统不会产生过多影响。

传输距离与带宽要求。同步传输方式要求带宽比较高，一般采用光纤链路，距离(链路距离)不超过100公里，最好在60公里以内；异步传输方式对带宽和距离的要求低很多，可以采用以太网络，因此不受距离限制。

适用场景。同步传输方式适用于业务系统数据变化和更新频率高，数据比较重要，不允许有任何数据丢失的业务系统，同时，投资的企业和部门又有意愿和财力进行设备投资和改善生产系统的运行性能。异步传输方式适用于业务系统数据变化和更新频率不高，能够容忍一定程度的数据丢失的业务系统，同时，投资企业和部门又不愿花费过多财力进行设备投资和生产系统的更新升级。讨论和建议

在部数据中心虽然运行了许多的业务系统，但是大部分业务系统不像银行、保险等金融业务那样实时强，数据不必做到零丢失，同时，考虑到远程灾备的目标是应对小概率事件，那么，灾备的投入产出比就非常重要，因此尽可能少的减少投资成本和运维成本是建设灾备中心需要考虑的一条重要原则。

篇6：服务器灾备方案

根据国务院《住房公积金管理条例》相关规定和有关文件要求，全国各省市、自治区、直辖市和计划单列市、新疆生产建设兵团共有330多个住房公积金管理中心，铁路、电力、煤炭、石油、中直机关、省直机关等行业机构也成立了几十个分中心，这些中心和分中心都建设了自己住房公积金信息管理系统，但是，所有中心、分中心的信息系统的容灾备份基本尚属空白。个别中心在原有信息系统基础上建设了小规模数据备份系统，也有个别中心提出了中心之间数据互备的设想，但是，都没能达到灾备的标准和要求。

全国各中心住房公积金信息系统现状概述：

1、各中心均有自己的信息系统。

2、各中心信息系统投入投入差异较大，粗分为五个等级： A级：有上亿元的投入，如深圳；

B级：有数千万元的投入，如北京、上海、昆明、武汉、广州、长春等；

C级：一般省会城市和副省级城市的投入多在千万元以上； D级：再退一步，像郑州这类城市中心，投资规模多在几百万元。

E级：一般地市中心的投入多在几十万至一、二百万不等。

3、主机系统：少数中心选用中型计算机，如A级、B级中心； 较大规模中心（如B级、C级、D级）选用小型计算机；一般中心（如D级、E级）多选用PC服务器。

4、操作系统：操作系统也是差别较大，有hp、IBM的UNIX系统，也有SUN公司的Solaris，还有WINDOWS系统。

5、数据库系统：多数为ORCALE，也有Sybase、DB2，使用SQLServer的中心也不少。正版和盗版也是同时存在，大中心肯定用正版，多数小中心会用盗版。

6、应用系统：全国各中心的应用系统差别也非常大。做公积金管理软件的单位有东软、金软、北京金天鹏、深圳恒泰丰、西安金房子等等。也有自行组织开发的中心，比如郑州、开封等中心。

我们将根据不同中心的主机系统、数据库系统、操作系统、网络系统、存储系统等现现状，建设全国性的住房公积金容灾备份中心。

建设目标：

构建满足全国住房公积金管理机构的容灾备份中心，为其提供高性能、高可用性、高扩展性、高安全性的硬件架构、软件平台及技术支持，满足各住房公积金管理中心数据远程备份的要求，确保其数据安全。

具体建设目标包括：

1、提供数据打包存储服务：面向对象为信息系统规模小、规范程度差的中心。

2、核心系统运行服务：面向对象为经济发展较差地区、无条件建设规范化住房公积金信息管理系统的中心。

3、数据级容灾服务：面向对象为信息系统较为先进、灾备投入较小的中心。

4、系统级灾备服务：面向对象为信息系统先进、灾备投入较大、灾难恢复要求时间较短的中心。

5、应用级灾备服务：面向对象为信息系统先进、灾备投入较大、灾难恢复要求时间极短的中心。

以上灾备级别，基本能够满足当前各地住房公积金管理中心的灾备需求。

灾备中心还应达到或接近以下条件：

1、交通便利：飞机、火车、汽车均能顺利到达。

2、选址安全：地质结构稳定，发生特大自然灾害的几率小。

3、建筑物稳定：灾备中心的建筑物达到规定的抗震要求。

4、供电保障：灾备中心具有充足的电力资源。

5、通讯资源充沛：灾备中心必须接入多家运营商的通讯电路。

6、技术先进：灾备中心必须吸纳当前最新技术成果。

7、管理运行规范：按国家标准进行运营管理。

8、满足需要和发展：满足当前需要，支持未来发展。

9、满足技术交流：灾备中心具备技术的交流的功能。

10、长效机制：生活方便、环境优美、协调统一。建设任务：

建设完善的机房环境，构建良好的主机系统、存储系统、网络系统、安全体系及数据容灾备份体系，为全国住房公积金管理中心构筑可靠、高效、易用的灾备平台。

运用现代信息技术手段，将全国各住房公积金管理中心的业务数据或信息系统，集中远程备份。

建设原则：

一、先进性、标准化

采用先进成熟的技术和设计规范，保证系统能够高效、稳定地运行，结合当前住房公积金信息化应用情况，选用符合国际标准的技术和产品，保证系统的标准化和一致性，并保证在以后的发展过程中能够适应信息技术的发展趋势。

二、经济性、实用性

根据灾备中心的实际应用需求进行方案设计，选用性价比高的设备，建设一流的灾备系统，既能够满足住房公积金业务系统容灾的应用需求，又能够适应将来应用的扩展，系统应该能够方便地升级，并能够保护原有的投资。

三、高可靠性

在系统设计特别是关键点的设计中，选用高可靠性产品，并有合理的冗余和可靠的系统备份策略，保证系统具有故障自愈的能力，确保系统可靠运行。

在充分考虑技术先进性的同时，还要从系统结构、技术措施、设备性能、系统管理、厂商技术支持及维修维护能力等方面着手，确保系统的高可靠性，达到最大的平均无故障时间。

四、高开放性

采用符合OSI（开放系统互联）标准的技术和通信协议，采用符合ISO（如IEEE、ITU-T、ANSI等）标准的相关协议，采用国家标准和国际标准的网络规范，结合省内、国内各地住房公积金信息系统情况，充分考虑硬件环境、软件平台的兼容性，使得符合国际标准的不同厂商的产品可以无缝地添加进来。

五、高安全性

灾备中心必须具备足够的安全性，具有有效的容灾、容错等风险保障机制，能够防止来自系统内部恶意破坏及来自外部的恶意攻击，能有效防止因人为误操作带来的影响，采用有效的安全防范措施和安全手段，保证系统的完整性和机密性，并对信息访问和系统操作提供有效的权限认证，对雷击、火灾、盗窃等意外以及人为误操作等不可预知的问题，具有良好的预防和恢复机制。

六、高性能

灾备中心设计中，必须保障服务器、网络及各种设备的高吞吐能力，保证各种信息（数据、语音、图像等）的高质量传输，构建高质量的可服务于图像、语音、数据的综合网络系统，为关键业务提供QoS（Quality of Service）保障。

七、可扩展性

灾备中心采用的实现技术和产品必须标准化，系统结构及设备易于扩展，技术和产品发展具有良好的可持续性、可扩充性，将来能够方便平滑地对原有系统进行升级和更新。

八、灵活性、兼容性

选用符合国际发展趋势的国际标准软件、硬件、网络等技术，以便系统具备可移植性、高可靠性等优点，以便在将来发展中延伸采用最新技术，同时，为不同的现有设备提供互联手段，保证现有各种住房公积金信息系统的顺利接入。

九、结构的合理性

采用合理高效的系统结构，设计的系统结构应能合理安排冗余和负载，实现有效的流量控制和负载均衡，能够避免网络风暴和数据瓶颈，确保系统畅通运行，并能适应灾备中心业务发展的需求。

十、低碳、绿色、环保

绿色数据机房（Green Data Center）是指数据中的IT系统、机械、照明和电气等，能取得最大化的能源效率和最小化的环境影响。