关于灾备项目建设的几点思考

  现在的大多数企业里，各种主要业务基本上都需要信息化来支撑。在很多企业中，比较关注IT运行方面风险的也是IT部门，所以很多企业、公司都是IT部门来主导灾备这件事。灾备从宏观上来看，对国家经济、信息化建设和抵御灾难的能力都是有帮助的；同时从具体层面来讲，灾备对保障一个企业或公司的业务可连续性和信息安全都是非常重要的。

  在灾难恢复方面，业界公认有三个目标值得努力：一是恢复时间，企业能忍受IT中断多长时间；二是网络多长时间能够恢复；三是业务层面的恢复时间。

  灾难备份系统一般由可接替生产系统运行的后备运行系统、数据备份系统、终端用户切换到备份系统的备用通讯线路等部分组成。在正常生产和数据备份状态下，生产系统通过网络传输方法向备份系统传送需备份的各种数据。当灾难发生后，备份系统将接替生产系统继续运行，此时外部终端用户将从生产主机切换到备份中心主机，继续对外提供服务。灾备系统的稳定和可靠性在一个企业中其重要性丝毫不亚于生产系统，它直接关系到业务的连续性和稳定性。那么在规划和建设灾备项目时，我们需要重点关注和思考什么问题呢？

一、数据分析

   对于企业来说，最重要的IT信息资产就是数据。我们从数据用途的角度来分析，可将需要备份的数据分为系统数据、基础数据、应用数据和临时数据；同时根据数据存储和管理的方式又可分为数据库数据、非数据库数据、孤立数据和遗失数据。

   系统数据，主要是指操作系统、应用系统安装的各类软件包和应用系统执行程序。系统数据在系统安装后基本上不再变动，只有在操作系统、应用系统版本升级或应用程序调整时才发生变化。

基础数据，主要是指保证业务系统正常运行所使用的系统目录、用户目录、系统配置文件、网络配置文件、应用配置文件、存取权限控制等。基础数据随业务系统运行环境的变化而变化，一般作为系统档案进行保存。

应用数据，主要是指业务系统的所有业务数据，对数据的安全性、准确性、完整性要求很高而且变化频繁。

临时数据，主要是指操作系统、应用系统、数据库产生的系统运行记录、数据库逻辑日志和应用程序在执行过程中产生的各种打印、传输临时文件，随系统运行和业务的发生而变化。临时数据对业务数据的完整性影响不大，增大后需要定期进行清理。

数据库数据是指通过数据库软件或数据库管理系统来进行存取和管理的数据。

非数据库数据是指通过文件等非数据库管理系统来进行存取和管理的数据。

孤立数据是指从最后一次业务数据备份后到灾难发生、系统运行停止前未灾难备份的数据。这部分数据通常需要通过人工等方法重新录入到系统中。一般情况下，孤立数据越多，系统恢复的时间就越长，业务的停顿时间也就越长。孤立数据的多少与数据备份的周期有很大关系。

遗失数据是指无法恢复或重建的数据。在灾难备份系统的设计与实施中，要重点考虑的就是防止遗失数据的产生或减少遗失数据的数量，以及如何快速查找遗失数据等等。

   通过数据分析，我们可以对将要备份的数据有一个比较清楚的认识，保护好关键的应用数据和数据库数据，同时减少孤立数据和遗失数据。

二、业务分析

在企业里有不同的业务场景，我们可以根据各种业务系统其处理的业务类型、数据存储方式、处理方式、实时性要求、每天处理的业务量、单位时间内处理的业务量等条件，将业务系统划分为关键业务系统、重要业务系统、一般业务系统等。

关键业务系统：业务数据比较集中和核心，所连服务器节点较多，对保证整个企业的正常运转至关重要；一旦业务中断，将会立刻使企业提供的服务及正常业务运作受到相当严重的影响。并且一旦在特殊时期如月末、年末、业务量高峰期中断造成的影响更大，不仅经济损失大，企业信誉降低，而且有可能要承担潜在的法律责任。

重要业务系统：业务中断将对整个企业的正常、有效运转产生较严重的影响。一旦业务发生中断，会使企业部分提供的服务及部分业务受到影响和中断，但无关大局。比如：内部企业网系统、邮件传输系统、报表业务处理系统等。

一般业务系统：业务中断将不会立刻对整个企业的正常运转产生严重影响，一旦中短可以容忍在数天或数周内恢复。比如：人事档案系统、考勤系统、工程预决算系统等。

业务中断持续时间愈长，损失愈大。不同的时期如月末、年末、业务高峰期中断也是造成灾难损失的一个重要时间因素，且业务种类不同，造成的损失也不同。我们尽可能全力保护关键和重要业务系统的高可用，并降低业务恢复所需的时间来减少企业的损失。

三、灾备中的技术分析

目前有很多种容灾技术，分类也比较复杂。但总体上可以区分为离线式容灾（冷容灾）和在线容灾（热容灾）两种类型。

离线式容灾：所谓的离线式容灾主要依靠备份技术来实现。其重要步骤是将数据通过备份系统备份到磁带上面，而后将磁带运送到异地保存管理（还可使用虚拟带库技术，可提升备份恢复的性能和速度）。离线式容灾具有实时性低、可备份多个副本、备份范围广、长期保存、投资较少等特点，由于是备份一般是压缩后存放到磁带的方式所以数据恢复较慢，而且备份窗口内的数据都会丢失，因此一般用于数据恢复的RTO（目标恢复时间）和RPO（目标恢复点）要求较低的容灾。也有很多客户将离线式容灾和在线容灾结合起来增加系统容灾的完整性和安全性。

目前主流的备份软件主要有：

l Symantec Veritas NetBackup

l EMC Legato NetWorker

l IBM Tivoli Storage Manager

l Quest BakBone NetVault

在线式容灾：在线容灾要求生产中心和灾备中心同时工作，生产中心和灾备中心之间有传输链路连接。数据自生产中心实时复制传送到灾备中心。在此基础上，可以在应用层进行集群管理，当生产中心遭受灾难出现故障时可由灾备中心接管并继续提供服务。因此实现在线容灾的关键是数据的复制。和数据备份相比，数据复制技术具有实时性高、数据丢失少和容灾恢复快、投资较高等特点。根据数据复制的层次，数据复制技术的实现可以分为三种：基于存储的复制技术、基于操作系统主机的数据复制和基于数据库的数据复制。

  (1)基于存储的数据复制技术

　　国内常见的容灾解决方案，由存储厂家提供技术实现生产中心存储设备与灾备中心存储设备的直接远程镜像，将数据以同步或异步的方式复制到远端。其优点是将数据与应用分开，对主机系统的运行资源影响比较小，缺点是必须在本地端和灾备端分别配置两套相同的存储系统。

  (2)基于主机的数据复制技术

　　通过安装在服务器上的数据复制软件，实现异地数据复制。该技术的优点在于成本相对较低且能兼容不同厂家的存储设备，缺点是会占用主机的系统资源。

(3)基于数据库的数据复制技术

基于数据库的容灾技术传输的是数据库指令或者重作日志文件。该技术与存储类型和服务器平台无关，具有较好的使用灵活性。比如oracle中的DG技术，db2中的hadr技术，mysql中的主从复制。

三、灾备的级别和等级划分    

     一般来说，灾备可以分为数据级、应用级和业务级三个级别，可能大多数人对这三种级别的灾备都不是很了解，那么下面我们就来具体的了解一下这三种灾备。

　　数据级灾备：主要关注的就是数据，就是在灾难发生之后，可以确保数据不受到损坏。对于级别较低的数据级灾备来说，可以将需要备份的数据通过人工的方式保存到异地实现。如将备份的磁带(盘或光盘)定时运送到异地保存就是方法之一。而较高级的数据灾备方案则依靠基于网络的数据复制工具，实现生产中心不同备份设备之间或是生产中心与灾备中心之间的异步/同步的数据传输，如采用基于磁盘阵列的数据复制功能或存储级的数据实时复制。

　　应用级灾备：建立在数据级灾备的基础上的，对应用系统进行复制，也就是在异地灾备中心再构建一套应用支撑系统。支撑系统包括数据备份系统、备用数据处理系统、备用网络系统等部分。应用级灾备能提供应用系统接管能力，即在生产中心发生故障的情况下，灾备中心便能够接管应用，从而尽量减少系统停机时间，提高业务连续性。

　　业务级灾备：是最高级别的灾备系统。它包括非IT系统，所以当发生大的灾难时，用户的办公场所可能会被损坏，用户除了需要原来的数据以外，还需要工作人员在一个备份的工作场所能够正常地开展业务。

　　实际上，业务级容灾还关注业务接入网络的备份，不仅考虑支撑系统的服务提供能力，还考虑服务使用者的接入能力、甚至备份的工作人员。

　　在灾备系统建设中，根据需要选择不同的类型。应该综合考虑数据与应用系统的重要性、业务关联度、技术成熟度、基础设施条件、成本和管理维护等一系列因素。

　　在数据中心中，不管是生产中心还是灾备中心，他们之间的业务都是有联系的。比如数据库必须先启动，之后才能启动应用程序;应用服务器接管完成，才能进行网络的切换。只有严格按照流程操作，才能确保灾备的顺利切换。

    灾备的等级根据国家标准，可以划分为6个等级。如图所示：

    

四、设计整合的架构

 对于灾备系统来说，设计一个基于扩展性、安全性、高性能、易管理的整合架构是非常有必要的。      

 扩展性要求：应用系统不但要求为前端应用主机提供大量数据的访问，同时要提供多用户的并行访问，而且要支持数据存储的扩展性。因此，在建设灾备系统时，应首要考虑的问题就是存储系统的扩展性。在这里扩展性包括两方面的含义：存储容量的扩展与存储系统性能的扩展。存储数据量大，而且增长速度快。这就要求在建立存储系统时，要选用先进的存储网络结构，并选用模块化、易扩展的存储设备，以适应应用系统对数据存储系统容量扩展的要求。此外，随着业务系统的增加，服务器数量的加大，存储数据量不断增长，这样势必会增加整个应用系统的访问量。为适应应用系统这一变化，给使用者提供一个快速的访问查询，除改进原有的网络系统及应用系统外，还需要将存储系统进一步升级。所以，存储系统应能满足系统性能扩展性要求。

 安全性要求：海量的数字化信息是系统中最为宝贵的信息资源，需要建立非常安全的存储系统，并设计完善的备份恢复系统，以确保数据不会丢失。作为重要的应用系统，是否能够为用户提供7×24小时的连续访问，也是服务质量高低的重要指标。因此，系统需要建立起冗余的IP网络和应用服务器系统，而且要选用高安全性的存储设备，以支撑整个的应用系统。

 高性能要求：整个应用系统由多个子系统组成，通过提高各子系统的性能，可提高应用系统的整体处理性能。由于系统中所有的重要数据均保存在海量的存储系统中，每次的访问请求均要通过存储系统来读写数据，因此，海量存储系统要为应用系统提供高性能的数据访问支撑。

 易管理性要求：对于许多客户来说，都面临着一个重要问题——降低维护成本。用户应用系统较为分布，且各系统内部结构较为复杂，就需要有专门的大量维护人员进行维护，大大增加了系统的维护成本。有的用户用于系统维护的成本甚至几倍于系统软硬件的投资成本，如何降低系统维护成本，成为用户迫切需要解决的问题。对于此问题，在建立灾备系统之初，就要考虑采用先进的技术，尽量降低维护成本。比如采用系统的集中管理、图形化简易管理、自动化的运维管理方式；选用先进、成熟的存储管理软件；根据系统的实际应用需求，制定相应的备份恢复策略，实现数据的自动备份，减少维护人员手工操作等。

五、灾备测试

     在企业IT这一块，通常用业务来衡量灾备目标：哪些业务最重要？哪些业务可容忍的恢复时间最短？所以业务连续性是灾备需要考虑的重要因素，对灾备系统进行测试也是衡量其可用性的一个关键。

通常企业里有若干业务系统，在进行灾备测试的时候应该有所选择，以避免影响公司的正常业务运转。最好的办法是每次对企业内部的单独一套业务系统进行测试，这样不仅达到了预期目的，更可以尽量减少对IT人员及公司日常工作的影响。

灾备测试不仅是为了保证紧急情况下能够正常工作而对你的IT系统进行测试，这个过程同时也能够让企业中的员工切身了解灾难发生时具体的操作流程。有了这样的知识及经验储备，意外发生时大家就不会惊慌失措了。事实上灾备体系的使用过程应该是简洁自然的，而且以这样的状态进行操作也的确能使其发挥更好的保障效果。通过测试体验我们会认识到启动灾备不需要像与时间赛跑那样紧张拼命，而是一个自然有序的过程。

我们都希望自己的数据得到全天候的保护，无论遭遇何种恶劣的情况，数据绝不能丢失。当然，轻度损失在所难免，最近半小时的数据无法保障可以理解。但我们同时要看到，如果灾难真的来临，不是所有的数据都需要在第一时间得到恢复，确认哪些数据是业务最关键的部分也是在制定恢复策略中重点考虑的。在企业中那些最重要、最关键的业务信息才是我们在紧急情况下亟需保护的重中之重，这就要求我们制定恢复的优先次序，恢复时即从最关键、最需要及时恢复的业务上入手，而那些相对次要的应用程序及数据则可以在灾难过后慢慢恢复。

我们需要明白，能够通过灾难恢复及其它相关因素将应用程序恢复到灾前状态才是我们建立灾备机制的根本目的。请记住，没测试过的灾备系统才是企业最危险的敌人。缺少了测试和验证，这样的灾备系统就是不完整、不可靠的，并且很有可能在需要的时候起不到应有的作用，这就违背了当初我们设计该系统的初衷了。