下面以4个常见的场景为例，介绍如何规划备份方案。备份方案没有标准答案，需要根据实现情况来制定，也和管理员的个人使用习惯有很大相关性。

1 交易型数据库备份

以银行的交易系统为例，除了前一章节提到的关于RPO和RTO的指标外，很多企业内部或着其它相关监管也会有不同的要求。例如人民银行对商业银行数据备份的要求：1）有RPO要求≤4小时；2）RTO要求≤4小时。备份的策略：数据库打开归档模式，分别设置全量备份、增量备份和日志备份。
1） 全量备份耗时较长，选择在周末的业务空闲的时间段进行，每周一次。之前也接触过一些更密集的备份频率，3天一次全量备份，也遇到过每天1次全量备份的策略。就目前的主流备份系统性能来看，数据量在1TB以下的数据库，基本可以保证在半小时内完成备份。结合现有的备份系统的性能，以及数据量因素，首先制定测试计划。经过几次测试后，最终确定全量备份的频率。
我经历过最大的交易型数据库，约50TB，在数据库服务器、存储资源，以及备份系统性能卓越的环境下，整体备份耗时11小时，仅供参考。
2） 除全量备份执行的日期之外的日期，每天一次，在业务空闲的时间段进行增量备份。打开BCT功能，提升备份速度。
3） 按照RPO要求，4小时等间隔进行日志备份。在运行初期，不必直接设置成4小时间隔，可以从12小时开始间隔开始试运行。运行期间收集数据库性能信息，确定日志备份对数据库的影响。如果日志备份对数据库性能影响较大，说明现有业务环境不能胜任4小时RPO。需要对业务系统的性能进行升级，再逐步提升日志备份的频率。
4） 计算恢复速度
恢复速度与备份速度有很大相关性，在前几个步骤进行备份测试的同时，也要进行恢复测试，来检测备份计划对应的恢复方法是否满足RTO要求。恢复由两部分组成，第一部分是恢复数据文件和归档文件，第二部分是应用归档日志。需要恢复的归档日志数据量，与整个数据文件备份的耗时相关。在前面的一致性备份章节，我们介绍过，如果要使数据库恢复到一致状态，最小要求是保证所有数据文件一致。如果数据文件备份耗时2小时（从每1个数据文件备份开始到最后一个数据文件备份结束），那基本上恢复的归档跨度也大约是2小时。根据不同的业务情况，归档的数据量变化范围较大，不能推算时间，必须进行测试。
举例说明：一套数据库全量约5TB，在工作时间段每小时的归档量约10GB，其它时间段归档每小时约1GB。采用的策略是每周日一次全量备份，每天进行增量备份（共6次），时间都在每天的零点，在些基础上每4小时一次归档备份（满足RPO4小时要求）。全量备份耗时约2小时；增量备份耗时约15分钟，归档日志备份耗时约20分钟。一次全量数据文件恢复需要2.5小时，一次增量数据文件需要20分钟，恢复4小时的归档大约需要20分钟。按照最严重的情况来计算，假设周六增量备份结束后的晚上10点发现故障，需要全库恢复到最新的时间点，耗时计算如下：
一次全量恢复，约2.5小时；六次增量恢复约2小时；22小时的归档恢复+应用约1小时；整体耗时约5.5小时。显然这超出了RTO要求的4小时。我们按照最严重的情况来计算，当然我们也必须要按照最严重的情况来计算，因为RTO指标就是要求在任何情况下都能满足。所以我们要对备份方案进行优化。
总体恢复时间的5.5小时，这里面归档的恢复和应用耗时1小时，可提升的空间不大，这是由业务特性决定的，所以要优化的就是全量和增量的恢复速度。全量恢复要2.5小时，需要通过系统环境综合分析。限制恢复速度的因素包括：参数设置、数据库磁盘性能、备份存储性能、网络传输速度。除了参数设置的调整外，其它因素都和成本相关。不必疑惑，RTO和RPO本来就是决定着备份系统成本的关键因素，在做架构设计的时候就应该考虑到这些问题。但是成本问题在短期内往往无法解决，我们可以把焦点放到其它层面，分析是否可以暂时地解决问题，给成本问题的彻底解决赢得更多时间。
1） 方法一：增量可以使用积累方式，这样不论是恢复哪一天的数据，最多只需要恢复一次增量备份数据。修改后，增量的恢复速度从20分钟到1小时不等。在上述的场景下，恢复速度可从5.5小时降低到4.5小时。
2） 方法二：备份周期由一周缩短为3天，即一次全量备份，后续2天进行增量备份。在相同的场景中，恢复速度可从5.5小时降低到4小时以下。这肯定是可以满足RTO≤4小时要求，但是也带来了新的问题，就是每三天一次全量备份，这会增大备份对系统的性能影响。是否选择这个方案，要考虑每天凌晨是否有大量的业务交易。如果每天凌晨的交易量都很小，选择这个方案是可以满足要求的。貌似这个方法可以满足需求，其实还存在很大的风险。方案虽然满足了4小时恢复的要求，但是不具备扩展能力，没有预留缓冲的时间。并且，数据量如果继续增长，后续将很难满足要求。
3） 方法三：目前恢复耗时大的首要因素是数据量大，关键是要设计出方案来提升速度，或者减少数据量，才能更可靠的满足要求。
提升速度的办法：
恢复的过程，是数据从备份存储读出，写入数据库生产存储中。以目前的存储技术，生产库后端的设备写速度完全可以满足5TB/小时，特别是目前SSD作为主流的时代。备份的存储，即便是普通的NAS，也能满足5TB/小时的读速度。因此，速度的瓶颈肯定在于网络。从单纯的带宽计算来看，至少要满足2条万兆链路才能满足5TB/小时的要求。考虑到交换机层面的问题，如果数据库部署了4条万兆，网络资源是足够使用的。但是有些企业对于硬件资源的调整阻力较大，优化网络带宽可能短期无法实现。我们可以考虑其它方法，利用现有资源。例如，数据库连接生成存储通常会使用多条SAN链路，这些链路仅是为了高可用（MPIO）设计，带宽消耗其实不高，可以用于备份服务。一些主流的备份软件，支持数据库通过SAN网络连接备份设备，数据流不通过LAN网络，大大提升备份速度。
减少数据量的办法：
这听起来不现实，难道有些数据不备份了吗？事实是极有可能的，特别是在大数据量场景下。交易型数据，如果数据量大很有可能是存在大量的历史数据。最佳实践是要求交易库和历史库分离的，但是现实中很多场景由于各种原因，特别是历史原因、责任原因没有进行分离，导致数据库越来越大。我曾经遇到过交易库50T，支持多套应用，并且有超过40T是历史数据。改造的逻辑很简单，首先尽可以为应用部署独立的数据库（或者尽量少的应用共享一套数据库）；其次，部署单独的数据仓库来保存历史数据。这样改造的结果，每个交易库的数据量控制在2、3T，备份将无压力。但是改造方案阻力很大，有历史原因，也有责任划分原因。
在我看来，方法三才是解决问题的根本办法，其它方法只能是过渡。

2 大型数据库（VLDB）备份

当数据量到达几十TB后，备份耗时会很长，通常可以达到10到20小时（取决于备份系统环境的性能），恢复速度比备份速度会更长，用户很难接受。必须使用更为优化的方式提升备份速度。目前，已经使用的比较成熟的方式是借助存储快照。
这里需要先介绍一下数据库的BACKUP MODE。首先，它不需要关闭数据库，应用可正常写入数据库。开启BACKUP MODE，数据库会进行一次Checkpoint，将全部数据写入到数据文件。此后，应用写入的数据只保存到REDO日志中，并不会写入数据文件，数据文件始终处于一致状态。
打开BACKUP MODE，对数据文件在存储层对应的卷进行快照。快照完成后，关闭BACKUP MODE，数据库恢复正常运转。还需要手工备份控制文件。将存储快照挂载到数据库服务之外的操作系统中（此步骤是避免备份对数据库服务器性能产生影响），将数据文件进行备份。由于是在BACKUP MODE状态下拷贝的数据，因此它们具备一致性。操作过程举例，
1） 打开备份模式

RMAN> alter database begin backup;

2） 创建存储快照
在存储设备，或操作系统中对数据卷进行快照。
3） 关闭备份模式

RMAN> alter database end backup;

4） 备份控制文件
控制文件需要使用RMAN来备份

RMAN> backup format ‘/bk/ctrl_%U’ current controlfile;

5） 备份参数文件

RMAN> backup format ‘/bk/spfile_%U’ spfile;

6） 备份数据库
将快照卷挂载到指定的操作系统中，对数据文件进行备份。
7） 恢复操作
恢复时，首先恢复参数文件和控制文件，如果按照原路径恢复，不需要做任何修改。如果路径或者其它参数变更，需要修改修改参数文件后重建SPFILE；第二步将备份的数据文件拷贝到指定路径下。
有一点需要注意的是，当打开和关闭BACKUP MODE这中间的一段时间内，如果有大量的业务写入数据，在关闭BACKUP MODE后，会产生大量的REDO写数据到数据文件，数据库可能会产生性能下降的现象，持续的时间由REDO中保存的数据量决定。
既然这种备份方式速度快，是不是其它数据库也应该使用它？这种方式有它的弊端，就是需要过多的手工介入。备份时需要手工配置存储，拷贝文件，并记录备份信息。恢复时，要确保备份信息存在，找到备份数据，手工配置存储资源。人工操作的步骤越多，失误的概率越大，因此，非必要不使用这种方法，RMAN的自动备份才是上上之选。

3 数据仓库备份

数据仓库保存着历史数据，通常数据量会很大，但是它又区别前一章节提到的大型数据库（VLDB）场景。数据库仓库的作用是从一个或多个交易型数据库收集并数据，并且进行整理，最终按照业务要求展现结果，如报表等。它定时通过ETL工具写入数据，并非实时更新。有些用户场景中，交易库和仓库使用同一个数据库，这给备份带来很大的麻烦。这样的场景，首先要建议用户“拆库”，也就是交易库和仓库分离，不仅是为了备份，也是数据库厂商和应用厂商给出的最佳实践方案。
数据仓库备份，首先要考虑是归档日志问题。这里有一个矛盾点需要平衡：关闭归档将不支持在线备份，只能将数据库置成MOUNT状态进行备份，所以业务也要停止；打开归档，数据仓库写入海量数据会产生大量的归档日志，而备份又必须包括归档日志，给备份系统带来了很大的压力。
Oracle给出了官方的最佳实践方法：保持数据库处于归档模式，手工关闭用户数据对应的表的归档，这样即可以进行在线备份（不需要关闭数据库），也不会产生过多的日志。这种方案有一个前提，就是需要对SQL语句进行改造，让它跳过REDO，直接写入数据文件。
例如,

SQL> insert /*+ APPEND */ into table2 nologging select * from table1;

看到这儿，是不是会有疑问？关闭了表的日志，那恢复的时候怎么办？不用担心，我们关闭的是表级的归档，不是数据库级的归档，因此可以保护数据库是可以恢复的。ETL软件，按照业务逻辑从交易库中抽取数据，写入数据仓库并进行加工处理，提供报表和查询业务。数据仓库备份作业执行，必须要避开ETL的运行时间窗口，在没有数据写入的时段得到数据一致性。因为数据库级的日志是打开的，因此不用担心数据库不一致而无法恢复。如果在ETL运行期间，也就是有数据写入的时候进行备份，数据库依然可以恢复，但是表会提示有坏块，不能恢复。
在一些用户中，数据仓库创建初期数据量小，因此在设计上没有考虑归档的问题。后期数据量激增，加载速度和备份都暴露出问题，再回过头来对SQL进行改造，阻力非常大。遇到过这样的案例，每天备份的归档量巨大，而且归档日志本身就是压缩格式，很难再进一步压缩或消重，备份存储资源消耗非常严重。数据仓库为什么归档量巨大？试想一下，企业的所有交易库，可能是10几个，也可能是几十上百个，每天定时抽出数据进行加工并写入数据仓库。这么大的数据量写入，必须要产生巨大的归档数据量。有很多企业因此交易库多，仅一套数据仓库根本无法承担，因此部署了多个数据仓库。
因此，在数据仓库初期就规划好，这是非常重要的。后期如果想改造，会遇到很多历史遗留问题，阻力重重。

4 容灾场景备份

Oracle官方提供Data Guard工具，通过REDO的复制，创建备库。备库的设计，是为了解决主库故障时可以快速切换，保证业务的最大连续性。备库在实际使用中，也可以发挥更大的作用。例如，备库在“只读”状态下提供报表功能，也可以作为备份的源，充分的利用资源，同时分担主库的压力。
在Data Guard场景中，建议在备库端进行备份，避免备份操作影响业务的性能。通过RMAN在备库端进行备份，系统自动识别状态，自动与主库联动，不需要人工进行干预，与在主库操作备份完全相同。区别在于，从备库创建的备份集，控制文件状态为Standby，数据库不能直接打开。因此，在进行恢复时，需要管理员将控制文件状态修改为Primary，按照独立的数据库打开。