1585人阅读
【SQL Server 数据库】（17）
第七章 数据库恢复技术
　　一、选择题
1．一个事务的执行，要么全部完成，要么全部不做，一个事务中对数据库的所有操作都是一个不可分割的操作序列的属性是（A）。
原子性&&&&
&B. 一致性　& C.独立性 &&&&&D.持久性
2．表示两个或多个事务可以同时运行而不互相影响的是（C）。
原子性&&&&& &B.一致性 &C.独立性&&&&&&D.持久性
事务的持续性是指（B）
A.事务中包括的所有操作要么都做，要么都不做。
B.事务一旦提交，对数据库的改变是永久的。
C.一个事务内部的操作对并发的其他事务是隔离的。
D.事务必须是使数据库从一个一致性状态变到另一个一致性状态。
4．SQL语言中的COMMIT语句的主要作用是（C）。
结束程序 &&&&B.
返回系统C. 提交事务&&&&&&D.
5．SQL语言中用（B）语句实现事务的回滚
A. CREATE TABLE&&&&&&B. ROLLBACK
C. GRANT和REVOKE &&&D. COMMIT
6．若系统在运行过程中，由于某种硬件故障，使存储在外存上的数据部分损失或全部损失，这种情况称为（A）。
介质故障&&&&
&B. 运行故障　& C.系统故障 &&&&&&D.事务故障
7．在DBMS中实现事务持久性的子系统是（D.）。
安全管理子系统&&& &B.
完整性管理子系统
并发控制子系统 &&&&D.恢复管理子系统
后援副本的作用是（C）。
保障安全性 &&&&B.
一致性控制　C. 故障后的恢复&&&&D.数据的转储
9．事务日志用于保存（C）。
程序运行过程 &&&&&&&&B.程序的执行结果
对数据的更新操作 &&&&D.数据操作
10．数据库恢复的基础是利用转储的冗余数据。这些转储的冗余数据包括（C）。
数据字典、应用程序、审计档案、数据库后备副本
数据字典、应用程序、审计档案、日志文件
日志文件、数据库后备副本
数据字典、应用程序、数据库后备副本
　　二、简答题
1.试述事务的概念及事务的四个特性。
答：事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。
事务具有四个特性：原子性（Atomicity）、一致性(Consistency)、隔离性（Isolation）和持续性（Durability）。这四个特性也简称为ACID特性。
原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性：事务执行的结构必须是使数据库从一个一致性状态变到另一个一致性状态。
隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
持续性：持续性也称永久性（Permanence），指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
2.为什么事务非正常结束时会影响数据库数据的正确性，请列举一例说明之。
答：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。
例如某工厂的库存管理系统中，要把数量为Q的某种零件从仓库1移到仓库2存放。
　　则可以定义一个事务T，T包括两个操作；Q1=Q1-Q，Q2=Q2+Q。如果T非正常终止时只做了第一个操作，则数据库就处于不一致性状态，库存量无缘无故少了Q。
3.数据库中为什么要有恢复子系统？它的功能是什么？
答：因为计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此必须要有恢复子系统。
恢复子系统的功能是：把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）。
4．数据库运行中可能产生的故障有哪几类？哪些故障影响事务的正常执行？哪些故障破坏数据库数据？
答：大致可以分为以下几类：
（1）&&&&事务内部的故障。
（2）&&&&系统故障。
（3）&&&&介质故障。
（4）&&&&计算机病毒。
事务故障、系统故障和介质故障影响事务的正常执行；介质故障和计算机病毒破坏数据库数据。
5．据库恢复的基本技术有哪些？
答：数据转储和登录日志文件时数据库恢复的基本技术。
当系统运行过程中发生故障，利用转储的数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。
数据库转储的意义是什么？试比较各种数据转储方法。
　　数据转储是数据库恢复中采用的基本技术。所谓转储即DBA定期地将数据库复制到磁带或另一个磁盘上保存起来的过程。当数据库遭到破坏后可以将后备副本重新装入，将数据库恢复到转储时的状态。
　　静态转储：在系统中无运行事务时进行的转储操作。静态转储简单，但必须等待正运行的用户事务结束才能进行。同样，新的事务必须等待转储结束才能执行。显然，这会降低数据库的可用性。
　　动态转储：指转储期间允许对数据库进行存取或修改。动态转储可克服静态转储的缺点，它不用等待正在运行的用户事务结束，也不会影响新事务的运行。但是，转储结束时后援副本上的数据并不能保证正确有效。因为转储期间运行的事务可能修改了某些数据，使得后援副本上的数据不是数据库的一致版本。
　　为此，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件（log file）。这样，后援副本加上日志文件就能得到数据库某一时刻的正确状态。
　　转储还可以分为海量转储和增量转储两种方式。
　　海量转储是指每次转储全部数据库。增量转储则指每次只转储上一次转储后更新过的数据。从恢复角度看，使用海量转储得到的后备副本进行恢复一般说来更简单些。但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。
什么是日志文件？为什么要设立日志文件？
答：（1）日志文件时用来记录事务对数据库的更新操作的文件。
&&&&&&&&&&&&&（2）设立日志文件的目的是：进行事务故障恢复；进行系统障碍恢复；协助后背副本进行介质故障恢复。
登记日志文件时为什么必须先写日志文件，后写数据库？
　　把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。
　　如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，在恢复时只不过是多执行一次UNDO操作，并不会影响数据库的正确性。所以一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。
针对不同的故障，试给出恢复的策略和方法。（即如何进行事务故障的恢复？系统故障的恢复？介质故障恢复？）
　　事务故障的恢复：
　　事务故障的恢复是由DBMS自动完成的，对用户是透明的。
DBMS执行恢复步骤是：
　　（1）反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
　　（2）对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。
　　（3）继续反向扫描日志文件，做同样处理。
　　（4）如此处理下去，直至读到此事务的开始标记，该事务故障的恢复就完成了。
　　系统故障的恢复：
　　系统故障可能会造成数据库处于不一致状态：
　　一是未完成事务对数据库的更新可能已写入数据库；
　　二是已提交事务对数据库的更新可能还留在缓冲区，没来得及写入数据库。
　　因此恢复操作就是要撤销(UNDO)故障发生时未完成的事务，重做(REDO)已完成的事务。
　　系统的恢复步骤是：
　　（1）正向扫描日志文件，找出在故障发生前已经提交的事务队列（REDO队列）和未完成的事务队列（UNDO队列）。
　　（2）对撤销队列中的各个事务进行UNDO处理。
　　进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”（Before
Image）写入数据库。
　　（3）对重做队列中的各个事务进行REDO处理。
　　进行REDO处理的方法是：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”（After
Image）写入数据库。
　　在第（1）步中如何找出REDO队列和UNDO队列？请大家思考一下。
　　下面给出一个算法：
1）建立两个事务队列:
· UNDO-LIST:需要执行undo操作的事务集合；
· REDO-LIST:需要执行redo操作的事务集合；
　　两个事务队列初始均为空。
2）从日志文件头开始，正向扫描日志文件
· 如有新开始（遇到Begin Transaction）的事务Ti，把Ti暂时放入UNDO-LIST队列；
· 如有提交的事务（遇到EndTransaction）Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列；
　　直到日志文件结束
　　介质故障的恢复：
　　介质故障是最严重的一种故障。
　　恢复方法是重装数据库，然后重做已完成的事务。具体过程是：
　　（1）DBA装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到转储时的一致性状态。
　　（2）DBA装入转储结束时刻的日志文件副本
　　（3）DBA启动系统恢复命令，由DBMS完成恢复功能，即重做已完成的事务。
1）我们假定采用的是静态转储，因此第（1）步装入数据库后备副本便可以了。
2）如果采用的是静动态转储，第（1）步装入数据库后备副本还不够，还需同时装入转储开始时刻的日志文件副本，经过处理后才能得到正确的数据库后备副本。
3）第（2）步重做已完成的事务的算法是：
正向扫描日志文件，找出故障发生前已提交的事务的标识，将其记入重做队列
再一次正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。
具有检查点的恢复技术有什么优点？
答：利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要REDO，哪些事务需要UNDO。一般来说，需要检查所有日志记录。这样做有两个问题：
　　一是搜索整个日志将耗费大量的时间。
　　二是很多需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了，恢复子系统又重新执行了这些操作，浪费了大量时间。
　　检查点技术就是为了解决这些问题。
试述使用检查点方法进行恢复的步骤。
①从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。
②由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。
　　这里建立两个事务队列:
· UNDO-LIST:需要执行undo操作的事务集合；
· REDO-LIST:需要执行redo操作的事务集合；
　　把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
③从检查点开始正向扫描日志文件
· 如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列；
· 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列，直到日志文件结束；
④对UNDO-LIST中的每个事务执行UNDO操作,对REDO-LIST中的每个事务执行REDO操作。
什么是数据库镜像？它有什么用途？
　　数据库镜像即根据DBA的要求，自动把整个数据库或者其中的部分关键数据复制到另一个磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。
　　数据库镜像的用途有：
　　一是用于数据库恢复。当出现介质故障时，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。
　　二是提高数据库的可用性。在没有出现故障时，当一个用户对某个数据加排它锁进行修改时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3554090次
积分：36050
积分：36050
排名：第86名
原创：639篇
转载：81篇
评论：2483条
文章：27篇
阅读：50006
阅读：74378
阅读：48192
文章：14篇
阅读：274625
文章：11篇
阅读：151591
文章：10篇
阅读：71211
文章：13篇
阅读：34198
文章：13篇
阅读：353760
微信公众号：wwjblog
微信号：whatswwj
移动开发者狂热群：注明入群理由，里面有一群热爱分享的开发者
高品质课堂推荐：
(3)(3)(2)(3)(5)(9)(3)(6)(2)(2)(2)(8)(5)(10)(3)(2)(3)(4)(12)(1)(5)(5)(6)(7)(2)(13)(11)(11)(8)(14)(10)(16)(8)(15)(23)(13)(12)(12)(11)(17)(28)(18)(20)(8)(11)(20)(13)(14)(10)(23)(18)(15)(36)(27)(47)(16)(3)(28)(33)(14)(13)
从入门到成长到成熟再到优秀，大多数程序员走了前面一段相似的道路，而有些人却走得更远一些！！！！数据中心解决方案之灾备方案设计（上）
数据中心解决方案之灾备方案设计（上）
1.数据中心容灾备份解决方案
随着社会的发展和科技的进步，政府日常工作越来越依赖于数据处理来进行，政务系统的连续性依赖于数据中心系统的稳定运行。然而，灾难就像灰尘一样伏击在运营环境周围，政务系统的数据中心可能正在一个充满风险和威胁的环境下运行。如果不能对这些风险采取有效治理，一旦数据由于某种原因丢失，就很有可能对政府的日常工作造成严重的影响。如果核心数据丢失，将会使得某些核心功能陷入瘫痪，造成不可估量的损失。因此，保证政务的连续性和数据的高可靠性和可用性，已经成为政府部门在数据中心建设中，必须要考虑的问题。
1.1灾备解决方案原则
首先，在制定容灾系统方案的过程中要考虑的就是容灾系统建设对原有业务系统带来的影响。比如，采用数据复制技术对系统I/O带来的延迟，应用数据同步对日常业务处理系统带来的压力等。因此，企业要通过周密的测试和分析来规避容灾系统建设时带来的这些风险，以保证业务系统不会因容灾系统的建设而出现在处理性能上下降的问题。
第二，数据状态要保持同步。为保证在灾难发生时，业务可以成功地切换到备份中心，就必须保证容灾系统数据同步机制的可靠性。因此，建立可靠的数据同步校验机制是必须的; 同时，还要考虑建立定时的、自动的数据同步核查对比机制，以检验两个中心数据的一致性，这是数据容灾工作中非常重要的一部分。
第三，容灾系统的日常维护工作要尽可能轻，并能承担部分业务处理和测试的工作。容灾系统的维护和管理是容灾切换成功的重要保证，在系统建设中，就必须要考虑系统的维护管理流程。生产中心任何业务处理过程的改变都必须完整地复制到备份中心; 所有新业务系统上线时，必须通知备份中心，并在备份中心配置好数据同步机制; 对原程序的改动也必须保证两个中心同时上线。
第四，系统恢复时间要尽可能短。容灾系统主要是为了实现在主中心系统发生灾难时，可以在规定时间切换到备份中心，保证数据不会丢失，并且继续向用户提供服务。但往往在灾难发生时，主要技术人员不能及时到达现场，为了顺利实现系统间的切换，应该让系统切换操作尽可能地简单; 并建立固定化的、标准化的切换流程，要求维护人员在切换演习时严格按照流程的指导步骤进行操作。
第五，可实现部分业务子系统的切换和回切。当人事变动、业务变化、IT设施变化以及其他可能引起恢复规划文档失效的变化发生时，应及时更新各恢复规划文档，并在必要时启动模拟测试或演习，确保业务连续性系统的工作能力。
第六，技术方案选择要遵循成熟稳定、高可靠性、可扩展性、透明性的原则。目前，国际上比较成熟的容灾技术包括： SAN/NAS技术、远程镜像技术、虚拟存储、基于IP的SAN互连技术以及快照技术等。其中基于IP的SAN远程数据容灾备份技术应用比较广泛，其是利用基于IP的SAN的互连协议，将主数据中心SAN中的信息通过现有的TCP/IP网络，远程复制到备份中心的SAN中的。当备份中心存储的数据量过大时，可利用快照技术将其备份到磁带库或光盘库。这种基于IP的SAN远程容灾备份，可以跨越LAN、MAN和WAN，成本低、可扩展性好。基于IP的互连协议主要包括FCIP、iFCP、InfiniBand、iSCSI等。
第七，构建系统方案可以选择多种技术组合方式。目前，业内应用较多的容灾方案是基于智能存储系统的远程数据复制技术，它是由智能存储系统自身实现的数据远程复制和同步，即智能存储系统将对该系统中的存储器I/O操作请求复制到远端的存储系统中并执行。由于在这种方式下，数据复制软件运行在存储系统内，因此较容易实现主中心和容灾备份中心的操作系统、数据库、系统库和目录的实时拷贝及维护能力，且不会影响主中心主机系统的性能。如果在系统恢复场具备了实时数据，那么就可以做到在灾难发生时，及时开始应用处理过程的恢复。但这种方案也有开放性差(不同厂家的存储设备系统一般不能配合使用)、对于主、备中心之间的网络条件(稳定性、带宽、链路空间距离)要求较苛刻等缺点。
1.2灾备解决方案设计需要考虑的因素
1.2.1 RTO和RPO
RTO（RecoveryTime Object）：是指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段成为RTO。RTO是反映业务恢复及时性的指标，表示业务从中断到回复正常所需要的时间。RTO值越小，代表容灾系统的数据恢复能力越强。各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。
RPO（Recovery Point Objective），是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输延迟的时间；在异步数据复制下，RPO基本为异步传输数据排队的时间。在实际应用中，考虑导数据传输的因素，业务数据库与容灾备份数据库的一致性（SCN）是不同的，RPO表示业务数据库与容灾备份数据库SCN的时间差。发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。
设计容灾系统不能只看RTO和RPO，对于不同的业务系统和用户特殊的要求，其它一些指标有可能成为选择容灾解决方案的主要因素。例如，某些地区为了防范一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。
1.2.2数据安全
数据的完整性，一致性是保证业务连续的关键。在本地，数据安全需要使用RAID技术来保证。在灾备方案的设计中，数据复制方案的设计是整个设计的基础。目前业界主流的数据复制技术有：基于数据库本身的复制技术，基于操作系统的数据复制，基于虚拟存储的复制技术和基于存储的复制技术。在方案所用技术的选择时，应当根据客户的预算，现场的条件，综合来进行考量。后续在1.6.1数据同步章节，将会有这4类数据复制技术的综合对比，可以作为选择的参考。
1.2.3网络安全
通信网络是容灾系统的组成部分，通信线路的质量也是容灾系统的性能指标之一，其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平（网络年中断率）。如果容灾系统使用的通信网络是确定的，为了比较不同容灾解决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。
1.2.4业务连续性
业务连续性是灾备方案的最终目标，是方案的价值所在。为了保证业务的连续，首先需要数据的连续，之前我们讨论了数据安全相关的内容。其次，在数据连续的基础上，出现灾难时，系统需要能够满足（1）网络切换（2）应用切换。以此，来保证系统能够顺利切换到灾备地，继续安全运营，最大化保证客户利益。
1.3国标系统灾备等级划分及应对措施
国家《信息系统灾难恢复规范》（GB/T ）规定了六个级别的容灾，下表分别针对每个级别给出了相应的应对措施。
数据零丢失和远程集群支持
实现远程数据实时备份，实现零丢失；
应用软件可以实现实时无缝切换；
远程集群系统的实时监控和自动切换能力；
实时数据传输及完整设备支持
实现远程数据复制技术；
备用网络也具备字哦那个或集中切换能力；
电子传输及完整设备支持
配置所需要的全部数据和通讯线路及网络设备，并处于就绪状态；
7*24运行；更高的技术支持和运维管理；
电子传输和部分设备支持
配置部分数据，通信线路和网络设备；
每天实现多次的数据电子传输；
备用场地配置专制的运行管理人员；
备用场地支持
预定时间调配数据，通信线路和网络设备；
备用场地管理制度；
设备及网络紧急供货协议；
每周至少做一次完全数据备份；
制定介质存取／验证和转储的管理制度；
完整测试和演练的灾难恢复计划；
1.4容灾技术分析
1.4.1备份方式
备份系统未安装或未配置成与当前使用的系统相同或相似的运行环境, 应用系统数据没有及时装入备份系统。一旦发生灾难，需安装配置所需的运行环境，用数据备份介质（磁带或光盘）恢复应用数据，手工逐笔或自动批量追补孤立数据，将终端用户通过通讯线路切换到备份系统，恢复业务运行。优点：设备投资较少，节省通信费用，通信环境要求不高。缺点：恢复时间较长，一般要数天至1周，数据完整性与一致性较差。
将备份系统已安装配置成与当前使用的系统相同或相似的系统和网络运行环境，安装了应用系统业务定期备份数据。一旦发生灾难，直接使用定期备份数据，手工逐笔或自动批量追补孤立数据或将终端用户通过通讯线路切换到备份系统，恢复业务运行。优点：设备投资较少，通信环境要求不高。缺点：恢复时间长，一般要十几个小时至数天，数据完整性与一致性较差。
备份处于联机状态，当前应用系统通过高速通信线路将数据实时传送到备份系统，保持备份系统与当前应用系统数据的同步；也可定时在备份系统上恢复应用系统的数据。一旦发生灾难，不用追补或只需追补很少的孤立数据，备份系统可快速接替生产系统运行，恢复营业。优点：恢复时间短，一般几十分钟到数小时，数据完整性与一致性最好，数据丢失可能性最小。缺点：设备投资大，通信费用高，通信环境要求高，平时运行管理较复杂。
在计算机服务器备份和恢复中，冷备份服务器（cold server）是在主服务器丢失的情况下才使用的备份服务器。冷备份服务器基本上只在软件安装和配置的情况下打开，然后关闭直到需要时再打开。
温备份服务器（warm server）一般都是周期性开机，根据主服务器内容进行更新，然后关机。经常用温备份服务器来进行复制和镜像操作。
热备份服务器（hot server）时刻处于开机状态，同主机保持同步。当主机失灵时，可以随时启用热备份服务器来代替。
对于关键的业务，Primeton建议采用同城热备＋异地热备的方式进行部署，对于一般性的业务，建议采用同城热备＋异地温备（应用不启动，数据保持异步复制）的方式进行部署。
1.4.2数据复制技术
目前数据复制技术主要有如下表所列4种，基于红色字体部分的要求，结合客户的需要，Primeton推荐采用基于存储或者基于应用程序的数据复制技术来进行数据同步。
系统数据复制
操作系统层数据复制
应用程序层数据复制
基于存储的
虚拟存储技术
数据的复制过程通过本地的存储系统和远端的存储系统之间的通信完成。
复制技术是伴随着存储局域网的出现引入的，通过构建虚拟存储上实现数据复制。
通过操作系统或者数据卷管理器来实现对数据的远程复制。
数据库的异地复制技术，通常采用日志复制功能，依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。
与平台无关，
需要增加专有的复制服务器或带有复制功能的SAN交换机
同构主机、异构存储
与平台无关
对生产系统存储性能有影响
对网络要求高
对生产系统主机性能有影响
占用部分生产系统数据库资源
技术成熟度
成熟度有待提高，非主流复制技术。
高，需要同构存储
较高，需要专有设备
较高，需要同构主机
部分软件免费，如DataGuard
HP CA（Continues Access）
Tapestry DMM
原厂技术：
MirrorDisk
Solaris SVM
专业的复制软件：
GoldenGate
Quest SharePlex
1.4.3重复数据删除技术
重复数据删除技术是指将存储系统中存在的大量内容相同的数据删除，只保留其中一份，从而缩减存储空间的技术。在云灾备中，该技术既能大幅减少灾备中心存储的数据量，降低灾备中心的建设和运维成本，又能大幅减少数据备份和恢复过程中用户和灾备提供商间的数据传输量，提高备份和恢复的性能，是一项十分重要的技术。
随着灾备中心的规模不断增大，存储的数据量和访问量不断增加，单一节点上的重复数据删除方法已不能满足性能和容量的需求。除上述基本重复数据删除技术外，一些优化和改进技术对云灾备是至关重要的，包括高性能、可扩展的、分布式的重复数据删除技术，以及为提高灾备中心数据可靠性的高可靠重复数据删除技术。
1.4.4操作系统虚拟化技术? & &
除了数据级的灾备，还应提供系统级的灾备。即在将数据复制到云端的同时，也将受保护的应用程序的状态复制到云端，当灾难发生时可以立即切换到云端的应用程序运行，保证业务连续性。系统级灾备是通过操作系统虚拟化和检查点实现的。检查点用来捕获进程某一时刻的运行状态，从而实现进程迁移。进程迁移既可以是用户应用程序进程到云灾备中心的迁移，也可以是云灾备中心内部的虚拟机池间进程迁移，以实现根据前端用户的需求自动地调节灾备服务提供商有限的硬件与软件资源，动态地、弹性的反应前端业务对灾备的需求。
当程序因故障中断，如果不能保留其中间运行状态，恢复后从头运行将会带来极大的消耗。检查点技术能够解决这个问题。通过保留各个进程的运行状态，恢复时能够复原到最近一次保留的数据映像。
传统的检查员机制是基于库的检查点机制。例如以静态库的形式实现，或通过加载动态链接库来追踪程序运行过程中的数据变化。也有一些检查点机制实现于内核级别甚至硬件级别。例如通过在文件系统层之上引入一个中间层来实现保留文件系统状态的检查点机制；或者借助Fuse内核模块实现的支持检查点机制的文件系统，通过Fuse侦测、拦截内核级别的文件系统操作并将控制权传递给用户，从而能够在用户空间对文件系统状态进行保留。
随着操作系统虚拟化技术的发展，基于虚拟容器的检查点技术也得到了很好的应用。虚拟容器是通过系统虚拟化技术构建出来的一个进程运行的较独立的上下文环境。虚拟容器检查点技术能够有效保护容器内运行的应用程序和服务而不需要对应用进行修改。
1.5总体架构设计
1.5.1Primeton“两地三中心”容灾解决方案架构设计
结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的“两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。
1.5.1.1“两地三中心”本地高可用和容灾保护策略
（1）本地保护策略：
· 本地高可用
· 本地clone
· 持续数据保护
· B2D／BVTL
· 磁带备份
· Archive Log备份
（2）容灾保护策略
· 应用级或者数据级容灾
· 同级容灾、降级容灾
· 同步数据保护／异步数据保护
· 容灾数据复制技术
· 主备中心运营方式／双主中心运营方式／多中心运营方式
· 短、中、远期容灾策略
1.5.1.2“两地三中心”功能定位
同城备份中心
异地灾备中心
生产（双活或热备）
同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。
异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。
1.5.1.3“两地三中心”容灾架构设计
逻辑架构模型设计：
物理架构设计：
方案特点：
· 同城范围有效保证了数据的安全性和业务连续性；
· 异地复制数据根据灾难情形，尽可能降低数据丢失机率；
· 同城双中心为同步复制，数据实时同步，RPO=0；
· 异地无距离限制，保证数据一致性，保证了数据的有效保护；
· 异地容灾带宽要求低，先进的复制机制提高带宽利用率。
对于本地本级备份，应建立在线、近线、离线等多级存储备份系统，充分利用先进的备份手段和备份策略，形成完整的本地备份管理解决方案；备份的数据包括操作系统、数据文件以及应用服务环境等多个方面；日常访问的重要数据采用磁盘或者虚拟带库方式备份，归档数据和非重要数据采用磁带库方式备份；重要数据应至少保证每周做一个全量备份，平时做增量备份。
对于数据级异地灾备中心，选址上，应进行风险分析，避免异地备份中心与主中心同时遭受同类风险；网络备用系统上，必须在核心网络层面实现热备，保证灾备中心区域内通信的可靠性；数据备份系统上，主中心与备份中心的备份链路应有冗余，并确保2小时内将主中心的增量数据复制或备份到灾备中心；数据处理备用系统上，配备灾难恢复所需的全部数据处理设备，并处于就绪状态或运行状态，与主中心共同承担部分核心应用的查询服务功能。
对于同城应用级灾备中心，选址上，主中心与同城灾备中心距离应小于100KM；网络备用系统上，在核心网络层面实现热备，主中心与应用级灾备中心间通过裸光纤互联或VPLS互联，部署TRILL构建大二层网络，满足虚拟化需求；网络负载均衡上，主中心网络与灾备中心网络的负载均衡，提高灾备网络利用率与灾备网络可用性，正常情况下数据流同时使用两个中心的网络，主中心网络出现故障时，则全部数据流向灾备网络；应用集群切换上，关键业务系统集群实现手动切换，主中心与同城灾备中心之间建立高可用性监控技术，实现灾备中心应用服务器集群与主中心生产服务器集群之间的高可用性切换；云计算技术采用上，采用虚拟化技术对同城灾备中心进行规划建设，同时，根据业务关键程度、对性能的要求，系统平台选择不同档次和不同平台的主机资源池、存储资源池。
1.5.2基于不同服务需求选择不同可靠性“两地三中心”架构
1.5.2.1服务等级划分的可靠性
关键任务服务,需要最高级别的可靠性。高端技术和工具将会被用来满足最高级别的可靠性。如果丢失一个组件，如服务器，一块存储，或者一个通信链接，都将会导致服务不可靠。每个应用和基础服务都会制定性能指标。这些指标都将会被监控，并会通过业务支持的流程以特定格式输出。这个site不仅仅包含基础架构组件。
关键业务服务的运维和tier1一样，但是某些限制非可靠级别的服务可以容忍短时间的不可恢复的影响。高端技术和工具将会尽量（略低于tier1）被用来满足最高级别的可靠性。系统设计和指导里面必须包含——没有单点故障。
高端技术和工具将会尽量（略低于tier1和tier2）被用来满足最高级别的可靠性。允许有多个单点故障。仅仅在计划上有一些伸缩性。
没有关键服务运行，运维和支撑只要能够在一个可以接受的范围内即可。
99.99%的可靠性，数据中性能够切换，厂家支持（小于2小时的响应时间），硬件容错性，没有单点故障，N+1，数据中心的切换选择，硬件冗余
99.5%的可靠性，数据中性能够切换，厂家支持（小于4小时的响应时间），硬件具备容错性，没有单点故障，N+1
95%的可靠性，数据中性能够切换，厂家支持（小于24小时的响应时间）
没有可靠性保证，最低级别的支持
分钟宕机/月
1.5.2.2 Primeton通用的基于服务的“两地三中心”架构
1.5.2.3 Primeton基于不同的服务质量，达到不同级别的整体可靠性（tier）
（1）场景1
主环境如图中A所示，包含了数据库，应用，Web三层服务结构，本地高可用环境P作为同城备份站点，复制100%A中的Web服务，100%的A中的应用在线服务，100%的A中的OLTP事务，异地在数据库/应用／Web层均复制75%A中的服务。那么这套方案整体的可靠性将会达到99.999%。
（2）场景2
主环境如图中A所示，本地高可用环境P复制100%的A中的Web服务，100%的A中的应用在线服务，异地在数据库/应用／Web层均复制75%的A。那么这套方案整体的可靠性将会达到99.99%。
（3）场景3
主环境如图中A所示，本地高可用环境没有即没有同城备份站点，异地在数据库/应用／Web层均有一个可以接受的备份（非和A环境100%相同）。那么这套方案整体的可靠性将会达到99.70%。
（4）场景4
主环境如图中A所示，本地高可用环境没有即没有同城备份站点，异地采用冷备的方式，仅仅在发生灾难的时候采取措施 。那么这套方案整体的可靠性只有99.00%。
发表评论：
TA的最新馆藏[转]&