关于数据级灾备与应用级灾备之间的区别和联系

关于数据级灾备与应用级灾备之间的区别和联系

灾备的应用对于企业来说是一项重要的技术应用，对于企业数据安全起到了很大的作用。谈到灾备这个话题，很多CIO就会把异地应用级灾备放在首位，还特别强调建设一个数据零丢失、应用自动切换的最高级别的异地灾备系统。这其实是一个认识上的误区。灾备的重要性是毋容置疑的，但这并不是说灾备就一定要建应用级，从实际需求出发，“选择适合自己的”才最重要。

按照行业通俗的说法，灾难备份从保障的程度上一般分为三个级别：数据级、应用级和业务级。其中数据级、应用级都是在IT系统的范畴之内而言，业务级则考虑到IT系统之外的业务因素，包括备用办公场所、办公人员等。

数据级灾备的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。较低等级的数据级灾备可通过备份的数据人工方式保存到异地实现，比如将备份的磁带定时运送到异地保存就是方法之一。而较高级的数据灾备方案则依靠基于网络的数据复制工具，实现生产中心和灾备中心之间的异步/同步的数据传输，比如采用基于磁盘阵列的数据复制功能。

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

灾备建设中，如何选择数据级，还是应用级呢？我们可以从灾备的目标、投入产出比等多个角度进行分析。

异地灾备应对的是小概率事件，需考虑投入产出比

灾难的范畴很广，可能导致数据遭到破坏的计划外事件都属于灾难的范畴，其中包括自然灾害、业务运行所依赖的服务的中断、IT系统故障、人员错误操作、恶意攻击以及恐怖袭击等。下图是业界权威机构对灾难的分类：

从图上可以看到，无论是面对占据灾难比重44%的硬件故障，还是占据49%比重的软件、人为、病毒故障，需要的都不是远程的灾备保护，需要的只是本地的数据保护;而剩下的7%的自然灾难和社会灾难，才真正需要异地远程灾备。也就是说，通过双机热备、本地备份、CDP这些在线/近线的数据保护手段，就能解决93%的系统故障;而远程异地灾备，不论是数据级还是应用级，应对的都只是7%的小概率事件。

既然远程灾备的目标是应对小概率事件(同城灾备是高效率的小概率事件，异地应用级是低效率的极小概率事件)，那么，灾备的投入产出比就非常重要。一般而言，应用级灾备的投入会是数据级灾备投入的2-3倍，甚至更高，而且每一次从生产中心切换到异地灾备中心都需要耗费的大量人力、物力和时间，而回切的过程也同样复杂而耗费精力巨大。

因此，相对于应用级灾备而言，数据级灾备的投入产出比更高。与其建设昂贵的异地应用级灾备，不如做好本地的数据中心保护，再配合远程的数据级灾备。因此，在现实环境中，我们更常见的是“本地CDP+远程数据级灾备”这种数据保护模式。

灾备建设需要考虑循序渐进，分级建设

灾备建设的投入很大，不能一蹴而就一步到位，需要的是一个循序渐进的过程。数据级灾备和应用级灾备并不冲突，数据级灾备是应用级灾备的基础，异地灾备可以先做数据级的。很多的用户在建设灾备系统时，往往就先做数据级灾备，后续再扩展成应用级灾备。这么做的原因是多方面的。

原因一，与异地应用级的灾备相比，异地数据级灾备的投入比较小，却可以在极端情况发生时起到作用。在出现大地震等大面积的自然灾害的情况下，用户其实可以接受一个相对比较长的业务恢复时间，外界也会有一个比较大的容忍度。有了异地数据备份后，就可以用几天甚至更长的时间来恢复业务，而不至于彻底瘫痪。

原因二，灾难备份建设不是一个简单的技术方案，而是一项系统工程，灾备中心的基础建设、IT系统需要一个逐步建设的过程，运行维护团队、技术支持力量需要长期培养锻炼才能具备理想的应急能力。因此，先做数据级灾备，积累建设经验，培养灾备队伍，具备相当的能力之后，再建设应用级灾备系统就会容易很多。

此外，在从数据级灾备向应用级灾备过渡的过程中，还要根据业务系统按需划分灾备等级，不能一刀切。即使在同一个单位或者部门内，也存在多个应用系统。这些信息系统的重要性、复杂度都各不相同，对应的灾备等级也不相同。因此，我们需要根据业务系统的实际需求来逐个确定灾备等级。一般而言，“2/8原则”是比较常见的，也就是20%的应用是关键和核心的，需要应用级灾备，而80%的应用是非关键的，需要的只是数据级灾备。在实际的异地灾备中心建设中，这种应用级和数据级混合的建设模式是最典型的。

在应用级灾备的建设过程中，还存在一些常见的误区，它们是：

(1) 应用级灾备就是业务自动切换

(2) 应用级灾备就是数据零丢失

(3) 应用级灾备就是通过应用层(服务器或者应用软件)来做灾备

就第一个误区而言，这其实是一种追求技术的理想主义，并不适用实际环境。灾备中心的业务接管是一个管理和决策的过程，绝不是某一项具体的技术。技术不能替代管理，技术也不能替代决策，这早已成为了业界的共识。完善的灾备预案、适时的灾备演练、专业的技术支持队伍才是保障应用级灾备发挥作用的关键。

灾备切换是一系列操作的组合，不是单一的技术动作

不管生产中心还是灾备中心，彼此的业务之间都有逻辑的联系，服务的启动顺序也有严格的要求。比如数据库必须先启动，之后才能启动应用程序;应用服务器接管完成，才能进行网络的切换。如果应用程序先于数据库启动，结果肯定会是出错。在实际的灾备切换时，我们看到，操作员都会有一本完整的切换操作手册，上面说明了软件、硬件、服务的启动顺序，每一步的操作内容和预期的目标等等。只有严格按照流程操作，才能确保灾备的顺利切换。

因此，灾备切换是一系列技术操作的过程组合，不是单一的技术动作。

灾备切换是一个决策的过程，不能依靠单一的技术实现

灾难的类型多种多样，不是每一种灾难都需要启用灾备中心。而每一次灾备中心的启用，都需要耗费大量的人力和物力。因此，在发生灾难时，首要的是快速判断灾难的类型、可恢复性和后果等内容，然后根据灾备预案来决定是否启用灾备中心。比如，通过本地备份只需要半小时就能在本地恢复业务，就完全不需要启用灾备中心。此外，应用级灾备的对象往往是关键的业务，越关键的业务，切换就越需要慎重，这不是单一的个人意愿，往往需要的是集体的决策。

因此，灾备切换更是一个决策过程，而不是单一的技术实现。在实际案例中，99%以上的用户都不会选择自动切换。

说到第二个误区“应用级灾备就是数据零丢失”，很多CIO都认为难以理解。应用级

灾备当然要求数据零丢失，这一点通过磁盘阵列的同步镜像软件就能实现，技术上根本没有难度，为什么说这是误区呢？让我们从技术上做一些分析。

镜像并不能保证数据的完全同步

磁盘阵列具备同步镜像功能，能够实现主备磁盘阵列的完全数据同步。但是，磁盘阵列的数据同步并不意味着应用的数据也是同步的。为了提高性能，服务器一般都采用了写缓存，写缓存的数据并没有实时的真正写入到磁盘阵列上，因此，磁盘阵列上的数据和应用的数据是存在差异的。如果生产中心发生了故障，即使磁盘阵列的数据是同步的，也无法保障应用服务器的缓存数据也同步传输到了灾备中心。

镜像会降低生产中心的性能

镜像的实现机制是一个写IO要同时得到主备磁盘阵列的响应后，才能返回写OK。也就是说，对数据的一个写操作，需要主备磁盘阵列的二次写操作确认和主备站点的来回传输，时延会是普通写操作的3-5倍，甚至更高。因此，采用数据镜像后，会给生产中心带来比较明显的性能影响。此外，如果链路不稳定，出现闪断、抖动等情况，就会进一步加大生产中心的影响。

从上述的分析可以看出，镜像方式并不像想象的那么完美。那么什么机制才是比较有效的呢？

一些厂家采用的准实时复制技术就是一种答案，比如H3C的自适应复制技术。如果采用这种技术，IO写入主磁盘阵列就返回OK，然后复制模块再将这个写IO采用异步复制的方式传输到灾备阵列。这种方式不会降低主磁盘阵列的性能，还能做到准实时的数据同步。如果再把自适应复制技术和快照技术相配合，还能保证灾备中心的数据一致性，从而实现灾备中心的数据丢失量最少，数据肯定可用。

第三个误区也是我们经常碰到的，主要是把数据同步和应用接管两个概念混在了一起。

应用级灾备包括两个方面：数据同步和应用接管，其中数据同步是应用接管的基础，但数据同步和应用接管是两种不同的技术。

数据同步的技术多种多样，即可以基于存储阵列的复制软件实现，比如EMC MirrorView、H3C Replication等，也可以基于服务器或者应用软件实现，比如Veritas VVR、Oracle DataGuard等。但不管采用何种技术，都只是在不同的层面实现了数据的同步，要具备应用接管，还需要其他组件的配合，比如DNS域名切换解析、备用网络启用、应用服务切换等等。在现实环境中，我们最常见的应用级灾备方案是“磁盘阵列的数据复制+备用服务器”，也就是通过磁盘阵列来实现数据同步，通过备用服务器提供业务接管能力。

数据级容灾和系统级容灾都是在IT范畴之内，然而对于正常业务而言，仅IT系统的保障还是不够的。有些用户需要构建最高级别的业务级别容灾。业务级容灾的包括很多非IT 系统，比如电话、办公地点等。当一场大的灾难发生时，用户原有的办公场所都会受到破坏，用户除了需要原有的数据、原有的应用系统，更需要工作人员在一个备份的工作场所能够正常地开展业务。实际上，业务级容灾还关注业务接入网络的备份，不仅考虑支撑系统的服务提供能力，还考虑服务使用者的接入能力、甚至备份的工作人员。

简单来说，灾难备份的等级可以用三个嵌套的同心圆表示，从数据级灾备、应用级灾备到业务级灾备，业务恢复等级逐步提高，而需要的投资费用也相应增长。

由于灾备所承担的是用户最关键的核心业务，其重要作用勿庸置疑。灾备涉及到众多技

术以及众多厂商的各类解决方案，其复杂性也不言而喻。因此，在灾备建设中，不论是数据级灾备还是应用级灾备，“选择适合自己的”是构建灾备系统的一条基本准则。用户需要根据自身的实际需求量身打造，而在实际建设中，许多用户的灾备站点也都是经过长期积累、多次改造后形成的。

分布式环境灾备实现

分布式数据库研究现状及发展趋势摘要随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化，使分布式数据库系统应运而生。为了符合当今信息系统的应用需求和企业组织的管理思想和管理模式。分布式数据库提供了解决整个信息资产被分裂所成的信息孤岛，为孤岛联系在一起提供桥梁。本文主要介绍数据库数据存储特点，以及分布式数据库灾备的实现方法。 关键词分布式数据库；发展趋势；现状及问题 1.引言 当今社会已进入了信息时代，人们将越来越多的信息存储在网络中的计算机上。如何更有效地存储、管理、共享和提取信息，越来越引起人们的关注。随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化，集中式数据库已经不能满足人们的需求，因此分布式数据库系统应运而生，并且得到迅速发展。 分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接 起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式架构发展，基于关系型的分布式数据库在保留了传统数据库的数据模型和基本特征下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。 分布式数据库系统是由分布于多个计算机结点上的若干个数据库组成，,每个子数据库系统都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、终端，以及各自的局部数据库管理系统，分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上，它的数据存储方式与集中式数

关于数据级灾备与应用级灾备之间的区别和联系

关于数据级灾备与应用级灾备之间的区别和联系 灾备的应用对于企业来说是一项重要的技术应用，对于企业数据安全起到了很大的作用。谈到灾备这个话题，很多CIO就会把异地应用级灾备放在首位，还特别强调建设一个数据零丢失、应用自动切换的最高级别的异地灾备系统。这其实是一个认识上的误区。灾备的重要性是毋容置疑的，但这并不是说灾备就一定要建应用级，从实际需求出发，“选择适合自己的”才最重要。 按照行业通俗的说法，灾难备份从保障的程度上一般分为三个级别：数据级、应用级和业务级。其中数据级、应用级都是在IT系统的范畴之内而言，业务级则考虑到IT系统之外的业务因素，包括备用办公场所、办公人员等。 数据级灾备的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。较低等级的数据级灾备可通过备份的数据人工方式保存到异地实现，比如将备份的磁带定时运送到异地保存就是方法之一。而较高级的数据灾备方案则依靠基于网络的数据复制工具，实现生产中心和灾备中心之间的异步/同步的数据传输，比如采用基于磁盘阵列的数据复制功能。 应用级灾备是在数据级灾备的基础上，把应用处理能力再复制一份，也就是在异地灾备中心再构建一套支撑系统。支撑系统包括数据备份系统、备用数据处理系统、备用网络系统等部分。应用级灾备能提供应用接管能力，即在生产中心发生故障的情况下，能够在灾备中心接管应用，从而尽量减少系统停机时间，提高业务连续性。 灾备建设中，如何选择数据级，还是应用级呢？我们可以从灾备的目标、投入产出比等多个角度进行分析。 异地灾备应对的是小概率事件，需考虑投入产出比 灾难的范畴很广，可能导致数据遭到破坏的计划外事件都属于灾难的范畴，其中包括自然灾害、业务运行所依赖的服务的中断、IT系统故障、人员错误操作、恶意攻击以及恐怖袭击等。下图是业界权威机构对灾难的分类：

数据库灾备的重要性

数据库灾备的重要性 【摘要】随着社会经济的发展，信息安全渐渐成为众人关注的焦点。数据的安全和业务运行的可靠性越来越重要。本文将从简析数据库灾、简析数据库灾备体系在实际中的应用、浅谈数据库灾备的重要性及其发展方向等几个方面做一简要的分析。 【关键词】数据库；灾备系统；重要性 Shallow Analysis on the Importance of Database Disaster Recovery Li Sheng-bo （Information and Communication Company Qinghai Electric Power Corporation QinghaiXining 810008） 【Abstract 】With the development of social economy，information security has become the focus of public concern. Data safety and operational reliability is more and more important. This article from the analysis of the disaster，database of database disaster recovery system in the practical application of database backup，the importance and development of several aspects such as a brief analysis. 【Keywords 】database；disaster recovery system；importance 1 数据库灾备 数据库灾备就是指建立一个异地的数据库系统。该系统是本地关键应用数据的一个可用复制。当异地系统出现灾难时，系统至少会在本地或异地保存有一份可用的关键业务数据。该系统可以是与本地生产数据的完全复制，也可以略微滞后，但必须保证可用。主要运用的技术是数据备份和数据复制技术。所有的数据以保证数据一致性和不中断为前提，手动备份和自动备份并存、物理备份和逻辑备份并存、全量备份和增量备份、同时多DB并发备份、多实例DB并发备份、支持MYSQL和Oracle备份，灾备力度掌控在库级，不仅能够全库备份，且能备份部分库，配置调整灵活，根据不同的业务需要进行合理配置。 灾备系统的灾难防御范围包括服务器、存储等硬件设备损坏造成的宕机；地震、火灾、机房进水等造成的机房失效以及空调损坏、多站供电断电、瘟疫蔓延时机房无法进入等极端情况。 Oracle Data Guard通过利用数据同步技术来实现Oracle的高可用性、增强性能以及自动故障转移方案，来创建和维护主数据库及多个备用数据库，主数据库的改变因运用数据库灾备系统能够保证整个数据在运用过程中不会发生信息的丢失。 数据库备用类型。

灾备技术分析

1.1.1灾备技术分析 1.1.1.1灾备等级建议 设计一个灾备系统，需要考虑数据安全保障、网络带宽、数据备份/恢复可用，关系到备份/恢复数据量大小、数据中心和灾备中心间的距离和数据传输方式、灾难发生时要求的恢复速度等。根据这些因素，通常将灾备分为四个等级。 第0级，无灾备中心：这一级灾备，实际上没有灾难恢复能力，它只在本地进行数据备份，并且被备份的数据只在本地保存，没有送往异地。 第1级，本地磁带备份，异地保存：在本地将关键数据进行备份，然后送到异地保存。灾难发生后，按照预定数据恢复程序恢复系统和数据。 第2级，主备站点备份：在异地建立一个热备份点，通过网络以同步或异步方式把主站点的数据备份到备份站点，备份站点一般只备份数据，不承担业务。当出现灾难时，备份站点将接替主站点的业务，从而维护业务的连续性。 第3级，活动灾备中心：在相隔较远的地方分别建立两个数据中心，它们都处于工作状态，并进行相互数据备份。当某个数据中心发生灾难时，另一个数据中心接替其工作任务。这种级别的备份需要配置专用的硬件设备和复杂的管理软件，需要的投资相对而言是最大的，但恢复速度也是最快的。 通过比较分析，本项目拟采用灾备第2级进行数据灾备系统的建

设。 1.1.1.2灾备类型分析 灾备系统可以分为业务级灾备、数据级灾备、应用级灾备共三种类型。 (1).业务级灾备：主要在应用软件开发阶段，对数据进行主用数据库和灾备数据库的提交，这种方式需消耗10%左右的主机资源，对网络的要求也很高，因为其数据几乎是实时传递的，此外这种方式对系统开发人员要求极高，要注意每个模块跟数据相关的代码，否则极容易出现数据不一致的情况。 (2).数据级灾备：有基于存储阵列的数据镜像和基于管理软件的数据镜像两种方式。前者跟主机以及现有的IP网络没有关系，它通过FC（或FC-IP-FC）来实现阵列一级的数据同步，整体投资大，但数据安全性最有保障，且应用系统较多时实施较方便；后者需消耗10%~30%的处理器资源，对网络环境依赖较大。传统的数据备份可以认为是初级的数据级灾备方式，只是实效性差。 (3).应用级灾备：主要用于基于数据库的灾备，这种方式的系统变更的数据可以通过数据库本身的功能，通过IP网络从数据中心复制到灾备中心，这种方式不用兼顾应用层面和存储层面，整体成本是比较低的。传统的应用级灾备是通过主机一级的卷复制来实现数据灾备，对网络、主机的资源消耗较大。 根据业务需求并通过比较分析，本项目拟采用应用级的数据灾备方案。

六种数据库容灾方案

六种数据库容灾方案 1、经典方案，即双机ha，单盘阵的环境。 简单的说，双机热备就是用两台机器，一台处于工作状态，一台处于备用状态，但备用状态下，也是开机状态，只是开机后没有进行其他的操作。打个比方来说，在网关处架上两台频宽管理设备，将两台的配置设定为一致，只是以一台的状态为主，一台为次。主状态下的频宽管理设备工作，处理事件，次状态下的频宽管理设备处于休眠，一旦主机出现故障，备用频宽管理设备将自动转为工作状态，代替原来的主机。这就是“双机热备”。 2、单机双盘阵（os层镜像）。针对某些用户的双盘阵冗余的需求，我提出了在os层安装卷管理软件，用软件对两台盘阵做镜像的方案，但只有单机工作，一台盘阵挂了，因为os层的软raid的作用，系统仍然可以工作。 3、双机双柜（os层镜像）方案，这个方案，仍然是用os层做镜像，但是用了双机ha，这种方式有个尚未确认的风险，非纯软方式的ha要求主机有共享的存储系统。一台机器对盘阵lun做的镜像虚拟卷，是否也适用另一台主机，也就是说，a主机做的镜像，b主机接管后，是否会透明的认出a机做镜像之后的逻辑虚拟卷，如果ab两主机互相都能认，那么就是成功的方案！！ 4、双机双柜（底层镜像）。这种方案，虽然共享的lun不是在一台物理盘阵上，但是被底层存储远程镜像到另一台盘阵上，能保持数据的一致性

5、双机双柜纯软方式HA。这种方案，主机装纯软HA软件，虽然纯软不需要外接盘阵，但是接了盘阵，照样可行。 6、双机双柜（hacmp geo），其实geo大体上就是个类似于纯软HA的软件。

数据库安全 （一）数据库安全的定义 数据库安全包含两层含义：第一层是指系统运行安全,系统运行安全通常受到的威胁如下，一些网络不法分子通过网络，局域网等途径通过入侵电脑使系统无法正常启动，或超负荷让机子运行大量算法，并关闭cpu风扇，使cpu过热烧坏等破坏性活动；第二层是指系统信息安全，系统安全通常受到的威胁如下，黑客对数据库入侵，并盗取想要的资料。 编辑本段 （二）数据库安全的特征 数据库系统的安全特性主要是针对数据而言的，包括数据独立性、数据安全性、数据完整性、并发控制、故障恢复等几个方面。下面分别对其进行介绍 1．数据独立性 数据独立性包括物理独立性和逻辑独立性两个方面。物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的；逻辑独立性是指用户的应用程序与数据库的逻辑结构是相互独立的。 2．数据安全性 操作系统中的对象一般情况下是文件，而数据库支持的应用要求更为精细。通常比较完整的数据库对数据安全性采取以下措施： （1）将数据库中需要保护的部分与其他部分相隔。 （2）采用授权规则，如账户、口令和权限控制等访问控制方法。 （3）对数据进行加密后存储于数据库。 3．数据完整性 数据完整性包括数据的正确性、有效性和一致性。正确性是指数据的输入值与数据表对应域的类型一样；有效性是指数据库中的理论数值满足现实应用中对该数值段的约束；一致性是指不同用户使用的同一数据应该是一样的。保证数据的完整性，需要防止合法用户使用数据库时向数据库中加入不合语义的数据 4．并发控制 如果数据库应用要实现多用户共享数据，就可能在同一时刻多个用户要存取数据，这种事件叫做并发事件。当一个用户取出数据进行修改，在修改存入数据库之前如有其它用户再取此数据，那么读出的数据就是不正确的。这时就需要对这种并发操作施行控制，排除和避免这种错误的发生，保证数据的正确性。 5．故障恢复 由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏。数据库系统能尽快恢复数据库系统运行时出现的故障，可能是物理上或是逻辑上的错误。比如对系统的误操作造成的数据错误等。 SQL server数据库安全策略 SQL Server2000[1]的安全配置在进行SQL Server2000数据库的安全配置之前，首先必须对操作系统进行安全配置，保证操作系统处于安全状态。然后对要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的Web应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似“,;@/”等字符，防止破坏者构造恶意的SQL语句。接着，安装SQL Server2000后请打上最新SQL补丁SP3。 SQL Server的安全配置 1．使用安全的密码策略 我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库账号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa账号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步，建议密码含有多种数字字母组合并9位以上。SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非您确认必须使用空密码，这比以前的版本有所改进。同时养成定期修改密码的好习惯，数据库管理员应该定期查看是否有不符合密码要求的账号。 2．使用安全的账号策略 由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个账号进行最强的保

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

现在的大多数企业里，各种主要业务基本上都需要信息化来支撑。在很多企业中，比较关注IT运行方面风险的也是IT部门，所以很多企业、公司都是IT部门来主导灾备这件事。灾备从宏观上来看，对国家经济、信息化建设和抵御灾难的能力都是有帮助的；同时从具体层面来讲，灾备对保障一个企业或公司的业务可连续性和信息安全都是非常重要的。 在灾难恢复方面，业界公认有三个目标值得努力：一是恢复时间，企业能忍受IT中断多长时间；二是网络多长时间能够恢复；三是业务层面的恢复时间。 灾难备份系统一般由可接替生产系统运行的后备运行系统、数据备份系统、终端用户切换到备份系统的备用通讯线路等部分组成。在正常生产和数据备份状态下，生产系统通过网络传输方法向备份系统传送需备份的各种数据。当灾难发生后，备份系统将接替生产系统继续运行，此时外部终端用户将从生产主机切换到备份中心主机，继续对外提供服务。灾备系统的稳定和可靠性在一个企业中其重要性丝毫不亚于生产系统，它直接关系到业务的连续性和稳定性。那么在规划和建设灾备项目时，我们需要重点关注和思考什么问题呢？ 一、数据分析

对于企业来说，最重要的IT信息资产就是数据。我们从数据用途的角度来分析，可将需要备份的数据分为系统数据、基础数据、应用数据和临时数据；同时根据数据存储和管理的方式又可分为数据库数据、非数据库数据、孤立数据和遗失数据。 系统数据，主要是指操作系统、应用系统安装的各类软件包和应用系统执行程序。系统数据在系统安装后基本上不再变动，只有在操作系统、应用系统版本升级或应用程序调整时才发生变化。 基础数据，主要是指保证业务系统正常运行所使用的系统目录、用户目录、系统配置文件、网络配置文件、应用配置文件、存取权限控制等。基础数据随业务系统运行环境的变化而变化，一般作为系统档案进行保存。 应用数据，主要是指业务系统的所有业务数据，对数据的安全性、准确性、完整性要求很高而且变化频繁。 临时数据，主要是指操作系统、应用系统、数据库产生的系统运行记录、数据库逻辑日志和应用程序在执行过程中产生的各种打印、传输临时文件，随系统运行和业务的发生而变化。临时数据对业务数据的完整性影响不大，增大后需要定期进行清理。 数据库数据是指通过数据库软件或数据库管理系统来进行存取和管理的数据。 非数据库数据是指通过文件等非数据库管理系统来进行存取和管理的数据。 孤立数据是指从最后一次业务数据备份后到灾难发生、系统运行停止前未灾难备份的数据。这部分数据通常需要通过人工等方法重新录入到系统中。一般情况下，孤立数据越多，系统恢复的时间就越长，业务的停顿时间也就越长。孤立数据的多少与数据备份的周期有很大关系。 遗失数据是指无法恢复或重建的数据。在灾难备份系统的设计与实施中，要重点考虑的就是防止遗失数据的产生或减少遗失数据的数量，以及如何快速查找遗失数据等等。 通过数据分析，我们可以对将要备份的数据有一个比较清楚的认识，保护好关键的应用数据和数据库数据，同时减少孤立数据和遗失数据。 二、业务分析 在企业里有不同的业务场景，我们可以根据各种业务系统其处理的业务类型、数据存储方式、处理方式、实时性要求、每天处理的业务量、单位时间内处理的业务量等条件，将业务系统划分为关键业务系统、重要业务系统、一般业务系统等。 关键业务系统：业务数据比较集中和核心，所连服务器节点较多，对保证整个企业的正常运转至关重要；一旦业务中断，将会立刻使企业提供的服务及正常业务运作受到相当严重的影响。并且一旦在特殊时期如月末、年末、业务量高峰期中断造成的影响更大，不仅经济损失大，企业信誉降低，而且有可能要承担潜在的法律责任。

数据库级容灾

1.1.1 数据库级容灾 以Oracle数据库为例，数据库级容灾方式的主要由第三方的软件或者Oracle 自带的Data Guard 中的Logical Standby来实现，其传输的是SQL指令或者 重做日志文件。下面以第一种方式进行详细说明。 这类第三方软件的原理基本相同，其工作过程可以分为以下几个流程： ●第1步：使用Oracle以外的独立进程，捕捉重做日志文件（Redo Log File） 的信息，将其翻译成SQL语句 ●第2步：把SQL语句通过网络传输到灾备中心的数据库，在灾备中心的 数据库执行同样的SQL。 显然，数据库级容灾方式具有如下技术特点和优势： ●在容灾过程中，业务中心和备份中心的数据库都处于打开状态，所以，数 据库容灾技术属于热容灾方式； ●可以保证两端数据库的事务一致性； ●仅仅传输SQL语句或事务，可以完全支持异构环境的复制，对业务系统 服务器的硬件和操作系统种类、以及存储系统等都没有要求； ●由于传输的内容只是重做日志或者归档日志中的一部分，所以对网络资源 的占用很小，可以实现不同城市之间的远程复制。 其实现方式也决定了数据库级容灾具有以下缺点： ●对数据库的版本有特定要求； ●数据库的吞吐量太大时，其传输会有较大的延迟，当数据库每天的日量达 到60G或更大时，这种方案的可行性交差； ●实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活； ●复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作 流程进行，有一定的维护成本。 ●数据库容灾技术只能作为数据库应用的容灾解决方案，如果需要其他非结 构数据的容灾，还需要其他容灾技术作为补充 1.1.2 卷管理级容灾 卷管理级容灾有多种实现方式，而基于主机逻辑卷的同步数据复制方式以 VERITAS Volume Replicator（VVR）为代表。VVR是集成于VERITAS Volume Manager（逻辑卷管理）的远程数据复制软件，它可以运行于同步模式和异步 模式。在同步模式下，其实现原理如图1-1所示。

关于数据级灾备与应用级灾备之间的区别和联系

灾备的应用对于企业来说是一项重要的技术应用，对于企业数据安全起到了很大的作用。谈到灾备这个话题，很多CIO就会把异地应用级灾备放在首位，还特别强调建设一个数据零丢失、应用自动切换的最高级别的异地灾备系统。这其实是一个认识上的误区。灾备的重要性是毋容置疑的，但这并不是说灾备就一定要建应用级，从实际需求出发，“选择适合自己的”才最重要。 按照行业通俗的说法，灾难备份从保障的程度上一般分为三个级别：数据级、应用级和业务级。其中数据级、应用级都是在IT系统的范畴之内而言，业务级则考虑到IT系统之外的业务因素，包括备用办公场所、办公人员等。 数据级灾备的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。较低等级的数据级灾备可通过备份的数据人工方式保存到异地实现，比如将备份的磁带定时运送到异地保存就是方法之一。而较高级的数据灾备方案则依靠基于网络的数据复制工具，实现生产中心和灾备中心之间的异步/同步的数据传输，比如采用基于磁盘阵列的数据复制功能。 应用级灾备是在数据级灾备的基础上，把应用处理能力再复制一份，也就是在异地灾备中心再构建一套支撑系统。支撑系统包括数据备份系统、备用数据处理系统、备用网络系统等部分。应用级灾备能提供应用接管能力，即在生产中心发生故障的情况下，能够在灾备中心接管应用，从而尽量减少系统停机时间，提高业务连续性。 灾备建设中，如何选择数据级，还是应用级呢？我们可以从灾备的目标、投入产出比等多个角度进行分析。 异地灾备应对的是小概率事件，需考虑投入产出比 灾难的范畴很广，可能导致数据遭到破坏的计划外事件都属于灾难的范畴，其中包括自然灾害、业务运行所依赖的服务的中断、IT系统故障、人员错误操作、恶意攻击以及恐怖袭击等。下图是业界权威机构对灾难的分类： 从图上可以看到，无论是面对占据灾难比重44%的硬件故障，还是占据49%比重的软件、人为、病毒故障，需要的都不是远程的灾备保护，需要的只是本地的数据保护;而剩下的7%的自然灾难和社会灾难，才真正需要异地远程灾备。也就是说，通过双机热备、本地备份、CDP这些在线/近线的数据保护手段，就能解决93%的系统故障;而远程异地灾备，不论是数据级还是应用级，应对的都只是7%的小概率事件。

灾备系统技术方案

目录 第1章灾备系统技术方案 (3) 1.1异地灾备项目概述 (3) 1.1.1项目目标 (3) 1.1.2项目范围 (3) 1.1.3项目建设原则 (3) 1.2项目建设整体集成工作需求分析 (4) 1.2.1XX图书馆异地灾备系统的总体要求分析 (4) 1.2.2XX图书馆存储设备现状分析 (6) 1.2.3异地灾备存储系统的技术要求分析 (8) 1.2.4项目建设重点工作分析汇总 (8) 1.2.5项目建设工作难点分析 (10) 1.3灾备系统技术方案 (13) 1.3.1方案的总体设计 (13) 1.3.2灾备建设的总体方案 (14) 1.3.3数据级灾备平台设计 (31) 1.3.4灾备链路及SAN网络设计 (33) 1.3.5核心业务数据同步复制技术方案 (38) 1.3.6非核心业务数据异步复制技术方案 (47) 1.3.7长期保存数据的灾备技术方案 (55) 1.4我方投标灾备技术方案优势 (59) 1.4.1与现有存储系统整合最好的灾备方案 (59) 1.4.2提供业界最先进存储灾备技术 (60) 1.4.3最合理的SAN网络设计及灾备链路方案 (60)

1.4.4采用业界评价最高的存储 (61) 1.4.5业内唯一可提供100%数据可用性承诺的存储 (62) 1.4.6业界公测性能排名第一的存储 (63) 1.4.7业界第一款支持双活存储集群的存储 (67) 1.4.8内置存储虚拟化功能 (72) 1.4.9扩展能力极其出色 (82)

第1章灾备系统技术方案 1.1异地灾备项目概述 1.1.1项目目标 通过建立XX图书馆异地灾备系统，提高XX图书馆核心业务系统的风险抵御能力，避免或减少灾难打击和重大事故对XX图书馆及XX图书馆核心业务系统和重要系统造成的损失，确保核心业务系统的数据安全和作业持续性，实现核心业务数据异地实时同步复制、非核心业务数据以及各类数字资源异地保存。 1.1.2项目范围 1、异地灾备系统的建设：包括存储设备、配套设备及软件的安装、调试和集成，机房综合布线实施等。 2、异地灾备系统的培训：提供异地灾备系统使用及运维培训，确保用户能够熟练掌握、使用和维护异地灾备系统。 1.1.3项目建设原则 XX图书馆异地灾备系统建设须遵循以下原则： 1、可靠和实用性原则 异地灾备系统的设备选型、设计规划和实施方案、运维方案等方面均需考虑可靠性，实用性。 2、可扩展性原则 异地灾备系统的设备选型和软件应充分考虑可扩展性，能满足由于业务增长和业务需求带来的扩展要求。 3、成本效益原则 根据灾难恢复目标，按照灾难恢复资源的成本与风险可能造成的损失之间取得平衡的原

XXXX公司Oracle数据库异地容灾方案

XXXX公司Oracle数据库异地容灾方案 2011年08月29日

1、公司简介 XXXX公司。 2、项目背景 ●XXXX有两个数据中心。 ●两个基地之间使用TCP/IP网络进行连接。 ●生产业务系统的后台数据库为Oracle。 ●数据库服务器操作系统为Windows。 ●数据库目前总体数据量约为2.4T。 ●生产系统为双机容错架构。 ●希望远程数据中心成为容灾中心。 3、解决方案 3.1方案原理 这是一个很典型的应用场景，用户对RPO、RTO的要求比较高，用户希望数据丢失尽可能少，恢复尽可能快。可是，要实现这一愿望，传统的容灾方案都是采用昂贵的存储设备或卷管理软件来实现，投入相当惊人，用户很难接受！CommVault的CDR连续数据复制是一个性价比很高的解决方案，工作原理如下图所示：

这个Oracle远程容灾方案的设计思想是：在容灾系统初始化时或备份系统被破坏时，利用备份和恢复来传送数据库的DBF文件；在数据库日常工作时，利用CDR来时复制数据库日志文件，并将日志回滚到备份数据中（对于双机架构来说，原理相同，所需模块相同， 如图生产主机可为双机或集群架构）。系统的数据流如下图所示：

3.2实施过程 在这个方案中，我们采用了CommVault的备份技术和CDR技术，数据共有4份冗余，除了生产数据外，还有容灾数据，本地备份和异地备份数据；这里需要注意的是，在两个数据中心的数据库都是使用本地数据为业务系统提供服务，并且将数据在两个数据中心之间相互复制，以便达到两个数据中心互为容灾中心的目的。整个容灾系统的建立共分4个阶段： ●初始化阶段：通过备份＋恢复方式，在容灾站点生成初始化数据 ●容灾复制阶段： 1.通过CDR复制交易日志 2.自动回滚日志实现数据库容灾 3.每天做异地数据库的冷备份 4.每天做本地数据库的热备份 ●灾难重建阶段： 如果数据崩溃，由于本地和异地都有灾备数据，通过本地的直接恢复实现本地网络 的灾难数据重建，避免在远程网络上传送大量的初始化数据 ●容灾演练阶段： 将容灾站点的数据库打开，就可以使用了。恢复正常工作方式，只要将灾备的数据 恢复，然后回滚以前的日志数据，就能恢复容灾复制阶段。 4、技术要点 在这4个阶段中，充分利用了CommVault的独特技术： ●CDR复制：连续数据复制，复制数据库交易日志。 ●断点续传：支持从中断点继续传送。 ●GridStor：支持多个介质服务器使用不同地区的数据源，这样就不需要通过网络来 回传送大量的数据。 ●自动恢复和回滚：支持以时间或者自动的方式，恢复和回滚日志或其它数据，而不 需要手工执行。 ●辅助拷贝：支持将本地的备份数据复制到异地，实现异地的灾备。

虚拟化技术灾备解决方案原理分析

虚拟化技术灾备解决方案原理分析 虚拟化技术灾备解决方案的核心思想是双向复制，数据在其他地方实时产生一份可用的副本，此副本不需要做数据恢复，即可投入使用，当中断恢复后再还原回去。 当主服务器突然发生故障或者因其他损坏而停止工作时，和主服务器同步并做备份的虚拟主机开始启动，它将临时客串成为主服务器，同时向管理员发送邮件或者直接发送通知到管理员的移动终端上。当主服务器恢复后，虚拟机上包括操作系统、数据库、应用程序和其他相关数据都被无缝地迁移回原来的主服务器。完成这些操作只需要轻松地点击几下鼠标，用户根本感觉不到曾有业务中断。“这一切都是利用虚拟化技术灾备解决方案所带来的方便。”Novell公司工程师杨英宏说。 用户大量的业务系统依靠IT作为支撑，如果IT系统环境出现问题，将很难保证业务的正常运行，同时带来较大损失。市场上流行着各种各样的灾备技术和系统，但是，由于传统灾备系统的安装、配置和复杂度比较高，价格也比较昂贵，用户80%的投入只保护了20%的服务器，而且并不能真正保证业务运行。 灾备的目的是当灾难发生后，要立即恢复系统，尽快投入使用，所以灾备采用的各种技术，无论是数据备份、数据复制还是其他技术，都将围绕着业务的连续来进行。衡量这些灾备技术的指标主要是RPO(Recovery Point Object，恢复点目标)和RTO(Recovery Time Object，恢复时间目标)。 在虚拟化技术的灾备解决方案中，把要备份的目标定义为工作负载，这是指独立于硬件平台之上的一些应用运行环境，包括操作系统、数据和应用。 虚拟化技术灾备解决方案的核心思想是双向复制，数据在其他地方实时产生一份可用的副本，此副本不需要做数据恢复，即可投入使用，当中断恢复后再还原回去。数据复制的最大好处是副本数据立即可用，没有数据恢复时间，RTO 非常好。因为是实时复制，RPO也非常好，几乎不会丢失多少数据。

银行应用级灾备建设方案

银行应用级灾备建设方案

目录 1项目背景及建设需求 (3) 2各系统数据备份概况 (4) 3灾备端应用部署规划 (5) 4灾备网络通信系统 (7) 5各业务系统应用级部署工作计划 (8) 6各业务系统应用部署工作分解 (9) 6.1系统部署 (9) 6.1.1AIX平台 (9) 6.1.2虚拟机平台 (9) 6.2FTP环境构建 (10) 6.3系统验证 (11) 6.3.1验证前准备 (11) 6.3.2单系统验证 (15) 6.3.3系统集成验证 (16) 7项目主要风险点 (17)

1项目背景及建设需求 目前，我行灾备项目已完成核心业务域和城商业务域数据级同城备份，通过两台IBM中端磁盘阵列实现了两大业务域关键数据从生产中心到灾备中心的同城复制。其中： ?DS5100承载ESB、加密平台、图形前端数据库三个系统数据复制，未实现数 整报表系统的数据复制 ?DS5020承载PCSP（综合前置）、ATMP、虚拟化平台数据复制，未实现财务 系统（NC）数据复制 按山东省银监局相关要求：2013年三季度，需要完成国际结算、信贷、图形前端、票据、手机银行、NC、ATMP、数整报表、加密平台、综合前置、ESB等十一个重要业务系统的应用级灾备建设。

2各系统数据备份概况 十一个业务系统数据存储及异地备份概况统计如下表： 从上表可知，ESB、加密平台、图形前端、ATMP、综合前置（PCSP）等五个系统数据通过磁盘阵列实时复制到灾备端，数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统数据则通过每日全备、定时FTP传送至灾备端。

3灾备端应用部署规划 目前，灾备中心网络链路已就绪，各业务系统应用服务器硬件已完成上架、加电测试等相关工作。各系统部署规划如下表： 系统名称系统平台数据库应用灾备端服务器配置 ESB AIX6100-07 DB2 9.1 P740一台 加密平台AIX6100-07 P720一台 SQLServer 虚拟机 图形前端Windows2008 2008 ATMP AIX5300-12 Oracle10g P720一台 综合前置AIX6100-07 P720一台 数整报表AIX6100-07 DB2 9.1 P740一台 国际结算Windows2003 虚拟机 信贷系统Windows2003 虚拟机 票据系统SLES10 虚拟机 手机银行SLES11 虚拟机 财务系统 AIX5300-12 P720一台 （NC）

数据库容灾、复制解决方案全分析(绝对精品)要点

数据库容灾、复制解决方案全分析（绝对精品） 目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案： （1）基于存储层的容灾复制方案 这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。 目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。 （2）基于逻辑卷的容灾复制方案 这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。 我一直有一个困惑，存储级的复制，假如是同步的，能保证数据库所有文件一致吗？或者说是保证在异常发生的那一刻有足够的缓冲来保障？ 也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？ 上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案 我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧…… 我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失，也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。 所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。

服务器灾备方案

服务器灾备方案 一、服务器灾备的目的 服务器灾备计划就是在平时对服务器的重要数据、数据库、配置文件、应用服务等做备份，为了在发生重大灾难或者事故后，能尽快将原服务器中重要的数据、数据库或者应用服务等恢复出来继续给客户提供服务。 ※本方案适用于基于Windows操作平台下的服务器。 二、主要的服务器备份方式 按备份系统的准备程度，可将其分为冷备份、温备份和热备份三大类。 冷备份备份系统未安装或未配置成与当前使用的系统相同或相似的运行环境, 应用系统数据没有及时装入备份系统。一旦发生灾难，需安装配置所需的运行环境，用数据备份介质（磁带或光盘）恢复应用数据，手工逐笔或自动批量追补孤立数据，将终端用户通过通讯线路切换到备份系统，恢复业务运行。优点：设备投资较少，节省通信费用，通信环境要求不高。缺点：恢复时间较长，一般要数天至1周，数据完整性与一致性较差。 温备份将备份系统已安装配置成与当前使用的系统相同或相似的系统和网络运行环境，安装了应用系统业务定期备份数据。一旦发生灾难，直接使用定期备份数据，手工逐笔或自动批量追补孤立数据或将终端用户通过通讯线路切换到备份系统，恢复业务运行。优点：设备投资较少，通信环境要求不高。缺点：恢复时间长，一般要十几个小时至数天，数据完整性与一致性较差。 热备份备份处于联机状态，当前应用系统通过高速通信线路将数据实时传送到备份系统，保持备份系统与当前应用系统数据的同步；也可定时在备份系统上恢复应用系统的数据。一旦发生灾难，不用追补或只需追补很少的孤立数据，备份系统可快速接替生产系统运行，恢复营业。优点：恢复时间短，一般几十分钟到数小时，数据完整性与一致性最好，数据丢失可能性最小。缺点：设备投资大，通信费用高，通信环境要求高，平时运行管理较复杂。 在计算机服务器备份和恢复中，冷备份服务器（cold server）是在主服务器丢失的情况下才使用的备份服务器。冷备份服务器基本上只在软件安装和配置的情况下打开，然后关闭直到需要时再打开。 温备份服务器（warm server）一般都是周期性开机，根据主服务器内容进行更新，然后关机。经常用温备份服务器来进行复制和镜像操作。 热备份服务器（hot server）时刻处于开机状态，同主机保持同步。当主机失灵时，可以随时启用热备份服务器来代替。

构建完整灾备方案实现高性能备份灾备

构建完整灾备方案实现高性能备份灾备最近一项针对英国、美国、德国和法国企业的调查研究发现，85％的中小型企业（SMB）都面临成本的障碍，83％的SMB关注数据保护能力，80％的SMB则关心IT系统的复杂性问题。这些挑战基于一定程度上继续尝试使用传统的物理环境的思想，来实现在虚拟环境中的数据保护，而不是采用一种新的方法来实现。然而企业采取新的方法来执行数据保护也会面临不少挑战。例如，55％的中小企业表示，他们打算改变他们的工具来备份虚拟环境，在未来两年。 下面，我们将为大家介绍实现高性能备份的十大最佳实践： 一、关注性能 随着各类数据量的增长，备份窗口保持固定（或者甚至萎缩），高性能应该是选择备份解决方案时最优先考虑的因素。 高性能是关键目标，但是很难实现在虚拟服务器环境中，存在多种可能的存储网络和存储配置选项，而且大多数存储系统都缺乏相应的性能分析和调优。因此，存储系统的性能成了用户最关注的一个问题。虚拟服务器环境的部署存在有很多不确定的因素，用户仍在不断尝试各种方法，希望能够获得更好的性能，同时还能节省成本。 用户如果想为虚拟服务器环境配置更优化的存储架构，或者计划改善现有的服务器虚拟化环境，就必须和存储厂商协作，先在实验室环境中模拟实际生产环境，全面测试各种可能的存储设备配置情况，然后再进行实际部署。 二、融合备份到单一系统 在主数据中心通过一个系统来扩展容量至数PB，有助于减少大量的成本，减少行政负

担和管理、维护、升级系统的复杂性。 传统的单点解决方案直接从生产环境中通过磁带备份连续写入的方式，显然难以应对数据量激增给IT环境带来的超负荷处理挑战，其效率的不足使其“吃力”表现愈加明显。海量数据卷导致备份时间延长，企业往往不得不采用人工或复杂的快照和脚本方法，这使得恢复操作极其复杂、耗时：陈旧的备份方法、笨拙的人工方式，漫长的等待。 更让人崩溃的是，传统的备份方法不能全局性地解决冗余数据激增的问题，这一问题会导致对网络、存储和管理资源的过度消耗。这些都限制了企业恢复和使用受保护数据的能力，增加了数据恢复和查找所需的时间。最后，传统的备份解决方案往往基于一系列松散集成的工具，绝不是理想之选。 三、使用企业级优化重复数据删除 使用这种企业级的重复数据删除技术优化，可以在不影响备份性能的基础上，实现字节级的重复数据删除。对于需要快速增长的大型企业来说，高性能是很必要的，并在有限的备份窗口内，确保大规模数据量备份环境的安全。了解每个重复数据删除技术的性能差异，（特别是随着时间的变化）是特定环境选取最合适的技术的关键。有些重复数据删除技术软件包在重复数据删除TSM渐进的增量备份中和将数据分成碎片的应用程序中备份效率较低，优化重复数据删除技术 企业数据保护环境可能有特殊的重复删除技术要求的数据类型。寻找解决方案，使IT 能够选择他们想要的重复数据删除，通过备份政策，数据类型和那些自动检测被备份和执行的数据类型。选择技术使IT能够应用针对每个数据类型都最有效的重复数据删除方法。 四、重复数据删除复用，多数据流数据库 确保使用快速多路复用/多数据流，而无需关闭重复数据删除就可以备份Oracle，SQL

DR容灾网关--技术方案(本地灾备 简要)

为满足核心业务、数据的保护，本次灾备建设方案主要对多台Windows、Linux服务器及虚拟机服务器镜像保护。采用基于柏科DR容灾网关系统实现数据灾备解决方案：使用DR容灾网关对核心数据进行镜像，采用快照实现数据的逻辑错误恢复，采用一键式P2V启动功能实现操作系统的快速恢复；在本地信息中心，使用数据容灾网关特有的备份、归档功能对数据进行离线保护，最大程度对数据进行全方位的保护。 数据镜像 FC-SAN 数据镜像 部署说明 在生产中心部署一套DR3300容灾网关，利用DR3300容灾网关的数据镜像、智能快照、CDP持续数据保护、远程复制等技术实现本地应用级灾难接管。 ●架构规划 在生产中心增配一台DR容灾网关系统，DR容灾网关采用旁路非侵入式部署，只需加入FCSAN存储网络，即可以对生产中心多台服务器本地硬盘的操作系统、应用及核心存储数据进行保护，实现本地数据容灾保护。 在生产中心配备用虚拟化平台，可在本地系统出现故障时，5分钟内实现P2V 应用级业务接管。 ●业务及数据保护 客户端代理：在生产中心受保护服务器上安装客户端磁盘Agent映像代理软

件，将中心服务器硬盘数据或磁盘阵列数据镜像到DR容灾网关中。DR容灾网关通过磁盘Agent代理软件与这些应用程序集成或被直接调用，有相关的代理程序驱动数据库进入静止状态来做快照，来保证数据的一致性。 数据镜像：将DR容灾网关分别与应用服务器连接并分配相应的保护数据卷，满足各应用服务器数据的保护需求。平时对核心服务器的系统卷和数据卷均做镜像（MIRROR），通过磁盘镜像技术可以防止核心磁盘存储系统或服务器磁盘故障，发生故障时可以直接用DR容灾网关接替工作，对外提供服务，数据零丢失快照保护：通过对镜像的数据快照保护，保证了一体化保护设备上面保存了各应用服务器关键数据的多个历史副本，从而在发生逻辑错误（人为误删除、病毒感染、软件故障等）时可以快速恢复数据，重新起用应用。 数据的一致性保证： Oracle、MSSQL等都是结构化数据库，DR容灾网关快照与这些应用程序集成或被直接调用，有相关的代理程序驱动数据库进入静止状态来做快照，来保证数据的一致性。 持续I/O数据保护：对每个I/O操作进行持续“录像”保护，如果发生的是误删除、数据文件病毒感染、数据库损坏、数据不一致等情况，可恢复最近任意时间点的数据，数据丢失量（RPO）达到秒级。 远程数据复制：可以通过IP网络采用加密压缩和精简复制技术，将本地生产中心数据完整地复制到异地的DR容灾网关设备上，实现真正的异地容灾系统，使用精简灾备和数据压缩等传输技术，数据传输带宽只需要传统灾备1/8-1/32，传输成本大为降低。（后期可升级建设灾备站点） 灾难恢复 对数据存储的保护：如果本地生产中心核心磁盘存储系统故障，可以直接用DR容灾网关接替工作，对外提供服务，在数据“零”丢失的同时保证业务的连续性，避免了原有存储系统的单点故障。 远程启动功能：如果本地服务器操作系统故障，可用通过DR容灾网关SAN BOOT功能实现远程启动恢复操作系统和应用系统，防止操作系统和应用系统的故障。