企业备份方案设计干货参考：典型场景、典型问题及案例

水深无声 2022-06-16 06:28 344阅读 0赞

随着企业的发展，IT信息中心会出现越来越多的业务系统，这些业务系统也会越来越复杂。单从使用者的角度看，可能也就几个业务模块。但仔细一梳理，会发现其组成部分包含存储、SAN网络、主机、数据库、中间件等，可能还会有一些云平台。数据越多，业务越复杂，数据的保护工作越值得规划。数据规模到一定的程度后，就需要专门的备份软件来做这些事情，相对各个业务系统各自分散的备份，采用备份软件有以下优势：

1. 集中式管理，将所有的备份需求统一进行管理。

2. 全自动备份，可以设置调度作业。所有的备份任务自动进行，简化管理维护过程。

3. 支持各种应用和数据库备份和恢复，备份软件几乎支持目前市面上所有的主流企业应用。可以完美的和现有的应用程序契合。

4. 在线式索引，通过集中的控制台查看备份任务及备份内容。

5. 归档管理，应对基于法律法规的存档保存。

6. 有效的介质管理，可以将不同的备份介质统一管理起来，包括磁盘存储、虚拟带库、物理带库等设备。并且根据保留策略自动维护所有的备份介质。

7. hsm分级存储管理，可以基于生命周期或者数据热度来对用户的数据进行分层管理，降低成本。

8. 系统灾难恢复，可以基于现有的备份系统涉及容灾，达到异地恢复的目的。

9. 具备良好的扩展性，满足系统不断增加的要求。

备份软件能否良好的运行，前期的规划设计非常重要，本文整理了一些方案设计和最佳实践方面的知识，以及一些典型的案例场景来供读者参考。

典型场景、典型问题

## 1. 如何界定备份和归档这两者的区别，并使之匹配自己企业当前的需求？ ##

有些用户经常容易把备份和归档混淆，最初的需求不明确就会导致后期的实施方案走样，用起来各种问题，后期维护也是非常麻烦。

1. 先从对应场景来说吧

一般情况下，我们把用于恢复目的数据保留称作备份。这类数据一般变化较大，保留时限较短。仅仅是为了应对数据丢失来设计的。

而归档，一般对应的是长期存放，数据变化量相对较小，比较多的场景是基于法律法规要求的以年为单位的数据保留，应对的数据审查等操作。

2. 再从备份软件设计的角度来看

从备份软件的角度来看，各个备份软件在各自的系统中都有备份和归档一说，而且主要还是针对文件系统备份的时候提及的较多，就TSM和NBU对比来看，TSM有backup和archive这样的名词，而NBU也有user backup和user archive这样的备份类型。

这里以TSM为例，如果是数据备份，备份软件里对应的有数据保留的活动版本、非活动版本、删除版本以及非活动版本和删除版本的保存期限等参数（copygroup的verexistes、verdelete、retextra、retonly四个参数）。能比较灵活的应对备份数据的各种需求点。

对应归档来说，没有非活动版本的概念，每个版本都是活动的，只能以时间来界定（copygroup的retver参数）。

针对刚刚谈到的归档和备份的区别，根据第一点提到的需求差别，可以灵活的选择即可，比如：

对于大多数的普通文件、sql数据库、IBM domino、MS exchange等数据保留都可以通过上面说的副本组参数来灵活配置。

对于db2和oracle分别由程序自身来控制，db2使用db2adutl，oracle使用rman。

当然，也有一些特殊情况，比如db2的归档日志存放，或者sap的数据保留也会用的归档模式，这里根据备份和归档的设计差别，也可以解释的通。

3. 最后从数据的特点来看

一般情况下数据变化大的建议用户选用备份；而数据基本不变化，且需要长期保留的数据我建议用户一次或者定期归档长时间保留。

## 2. 针对企业现有的数据规模，如何规划存储类型、容量并设计合适的调度作业？ ##

见过不少客户的备份环境，用起来资源紧张，捉襟见肘。有的是备份空间不足，被迫修改保留策略。有的是受限客观环境，通道不足导致备份窗口加长，最后备份失败。总而言之，大都是是初始规划设计方面准备不足，导致后期维护困难。可以从以下几个点来考虑：

1. 存储空间确认

首先应该先汇总，看看当前要需要备份的系统有多少套，每套大概有多少数据量，最终得到1个初步的数据总量；

其次，应该了解并估算整个备份环境的增长量，以及规划的年数。比如，初步估算所有的备份数据总量为5T，每年增长20%，规划5年周期。最后的总量应该是12.5T左右；

最后，要确认保存的周期或保存的版本数。比如，初步按3个版本保存，40T的容量应该是没问题的。

2. 根据存储空间初步确定设备选型

比如，如果使用物理带库，按LTO6的磁带来算，14盘磁带就够了，但是考虑到并置组、存储池以及其他考虑等冗余要求，需要再多设计一些磁带，比如20盘。然后再考虑到是否要需要需求磁带循环使用，那么磁带库的槽位数量必须要多于20个。

如果是虚拟磁带库，考虑到产品的重删功能，可以对应的降低有效容量的配置要求。或者如果是磁盘存储池并启用重删功能，也可以根据测试对应的降低要求。

3. 备份窗口的确定

和业务系统的负责人沟通，了解每个要备份的业务系统的最大备份窗口，根据备份窗口选择合适的备份方式。通过合理的配置优化备份窗口，比如，使用lanfree备份，增加驱动器等备份通道、使用性能更改的备份设备等方式。一般来讲，核心系统和数据量大的非核心系统要求要配置lanfree备份。并且，如果配置lanfree也要做好规划设计，比如，做好san规划，使得备份zone和普通存储zone分开，并且备份系统都要使用独立的hba卡或独立的hba卡接口。

4. 备份调度的确定

根据RPO和RTO和设计合理的备份调度周期，根据各个系统的备份窗口，合理的设计各个系统的备份时间。

5. 做好备份恢复测试，并设计相应的制度，定期进行备份演练。

这个反而是最关键的，搞了半天备份，关键的时候恢复不了，这个就要命了，这样血的教训太多了。

## 3. D2D2T是个什么东西？有哪些好处？什么情况下使用？ ##

是不是经常听到什么虚拟带库、D2D2T等各种术语。虚拟带库有哪些好处？为什么不直接备到磁盘存储上。所谓的D2D2T又是个啥? 适合哪些场景？

数据由磁盘到磁盘再到磁带，我们一般称之为d2d2t，第二个D也可以理解为虚拟磁带库。第一个D近线存储，生产数据；第二个D离线存储，备份数据；T磁带库设备，离线数据。

传统的备份软件最初大都基于磁带库设计的，基于传统备份软件的备份架构已经非常成熟了，而且最近几年也再与时俱进，功能、性能及稳定性上都有了很大的进步。但是现有的企业环境数据量越来越大，业务类型也越来越复杂。对于物理磁带库来讲，最新的LTO7在容量和性能上有了很大的提升，顺序读写速度已经超过了sata磁盘，并且在离线保存方面还有很大的优势。但是在其他方面还有一些先天的劣势，比如数据恢复时的随机读写速度非常慢、重复数据删除、异地复制等等。

在这种情况下，作为中间层出现的磁盘或虚拟带库弥补了这个缺陷。D2D2T架构有如下好处：

1. 数据备份可以先到磁盘或虚拟带库上，在这一层可以得到良好的备份恢复速度，优化了备份恢复窗口，使用户得到一个非常好的RTO和RPO；

2. 备份到磁盘或vtl上的数据可以通过重复数据删除功能节省空间。重删可以由tsm来做，也可以直接基于vtl硬件来实现。

3. 可以实现其他一些基于硬件的高级功能，比如基于vtl的备份容灾（可参考liulei\_oracle兄的案例分享1）。

4. 满足数据离线保存或出库需求，备份数据可以得到更高的冗余保护。可以将虚拟磁带库上的数据再次迁移或复制到物理磁带库一份。备份数据到物理带库这个操作可以基于备份软件来做，也可以基于虚拟磁带库本身来做，使用起来非常灵活。

综上，D2D2T在一些数据量大，备份要求高等需求场景下，有非常好的表现，可以考虑在对应的场景下使用。。

## 4. 如何设计磁带出库保存或异地恢复？ ##

长时间的磁带保存方案如何设计，如果异地恢复又有什么值得注意的?

我们以NBU和两TSM款典型的备份软件来举例：

1. 如果使用NBU

方案1：VAULT， 对数据集备份到磁带中，然后从带库中弹出，做离线保存，可以把关键的数据运输到异地做导入恢复。

优点：便宜

缺点：要带库支持一定功能，并要长期人为去维护拿带子等

方案2：AIR（Automatic Image Replicate），AIR要求两个MSDP之间做数据的同步，这要求要一定的带宽和相应的磁盘做MSDP池。

优点：重复数据删除功能，同步效率高，可实现1对多，多对1的数据同步，自动化程度高。

缺点：价格贵，架构较复杂，处理问题也比较麻烦。

2. 如果使用TSM

TSM的出库有以下几种类型：

A. 普通的出库，即超长时间的保留导致的磁带数量越放越多，超出了磁带库的槽位数，所以需要定期的将已满的磁带取出。对应的命令：

update volume volume\_name access=readonly  
checkout libvolume library\_name volume\_name

checkout后取出存放即可。不用太在意标签的问题，如果后期有恢复或回调需求，直接做即可，会提示需要哪盘磁带，找到后checkin即可即可。

B. 长期保存为目的，不影响当前备份数据。

对于普通文件：generate backupset

对于Oracle、db2等数据库：export node到磁带即可

C. 基于多重保护目的。将磁带库设置为副本存储池。定期将主池的数据备份到副本池。然后按照步骤A来取带子，保存好即可。

D. 使用drm，相对于有个单独的数据库来记录出库磁带

关于磁带的保存，不管采用那种技术做磁带出库，都建议如下：

1，环境要求，避光防潮忌消磁，温度湿度适中，专柜存放。

2，存放标签要求，分门别类，标签写明：什么时间备份的什么系统的什么数据，保留至多久，用于什么目的。磁带编码有哪些，对应原备份系统哪些备份配置。

3，磁带出入库登记，没有的话弄丢磁带或找磁带的时候就只能哭了。

如果是基于TSM的异机恢复，分以下几种：

A. 普通恢复，从tsm中取出的磁带，需要tsm server才能读取。所以，需要先在异地恢复tsm server，需要用到tsm db备份，卷历史文件、设备配置文件等。恢复完tsm server后，才可以正常读取磁带

B. 仅异地恢复数据。只支持export和备份集方式的备份。上面出库步骤1和3类型的不支持。

## 5. 数据爆发导致的备份窗口不足，备份软件如何优化备份环境？ ##

关于这个问题，我的看法是先按两种情况来分析：

第一种情况是，现有的备份架构不变，在架构内进行分析。首先， 抛开数据量大小，我们先来梳理一下影响备份速度的几个因素

A. 备份服务器的性能，也就是处理能力。备份服务器是整个备份环境的核心，备份数据的元数据索引、备份介质管理、客户端调度管理都需要服务器处理能力来支持，如果再有数据重删，远端复制等附加功能，对服务器的性能要求会更高。

B.客户端的IO处理能力。网络传输类型（san or lan），网络传输速度（lan的十百千兆速率选择，光纤2/4/8/16GB速率选择等）、IO并发度（磁盘卷或磁带机数量）等等都会影响IO速度。

C.备份对象的数据类型，是海量小文件，还是常规文件。

D.备份介质的质量。比如同样是物理磁带备份，从早期的LTO3到最新的LTO7，速度和容量差别巨大，参考以下图片（图片来做www.lto.org）

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

备注：图片中的容量和速率都是按压缩后的最大值来算的。

经过上面的分析，我们可以提出基于以下几点的备份优化：

1.基础架构的优化

提高IT基础建设，从服务器性能，网卡，光纤卡，san交换机，带库方面入手，找到瓶颈，另外选择合适的备份架构，lan,lan-free, server-free。这里举个例子，比如1个2T的数据库，如果以LTO3的单驱动器按80M/s来算，需要7个小时左右，但是如果是LTO7单驱动器按300M/s来算，只需要2个小时。如果再以多个驱动器来做多通道的话，时间都可以控制在1个小时以内。

现在大多数企业都开始使用虚拟带库，虚拟带库在速度、驱动器的并发性上更加灵活，并且在数据恢复上，有更大的性能优势。也可以结合物理带库来做d2d2t使用。

2.备份优化

可以使用并发，重复数据删除，永久增量备份等方式，减少数据传输，提高备份速度。

3.应用优化，如sql server的数据库分离等。  
　　  
第二种情况下，数据的增长达到了一个质的增长。通过调整备份环境的软件和参数已经无法满足备份窗口。一般可以考虑如下方案：

A.配合现有存储的硬件特性来做，比如IBM的fcm就可以和大多数的主流存储配合，以存储硬件快照和tsm离线保存相结合的方式来提供备份解决方案。可以把备份窗口缩短到分钟级，并且通过tsm进行管理，还可以将备份的数据存放到磁带库中。其他备份厂商也有类似的解决方案。

B.采用新的备份架构，比如飞康的cdp、veeam的备份解决方案等，在某些细分领域都做的非常好。

## 6. 备份环境中的压缩和重删，都有哪些使用经验？ ##

数据现在重复率越来越高，备份软件和磁带库好多都支持压缩和重删功能，在哪些场景下使用过什么样的压缩和重删功能，取得了比较好的效果，在什么场景下使用过压缩或者重删，不但没有效果，反而效果更糟？

以tsm为例，其他的原理都差不多。

tsm的重删包含源端重删和服务端端重删两类，tsm从v6版本开始支持重删，最早只支持服务端重删，后来开始支持源端重删。v7版本的7.1.3开始新增在线的重复数据删除功能，7.1.5新增了在线的压缩功能。重删可以有效的利用空间，但会以牺牲部分主机的性能为代价，因此：

如果备份服务器的配置很高，处理能力很强，可以选择目标端的重删和压缩。比如对于tsm v7，内存原本建议最低12g，但如果采用重删，则建议最低16g；

如果源端的应用服务器配置很高，处理能力强，反而网络带宽不理想的情况下，可以选择源端重删和压缩。看怎么取舍了。

除此之外，现在大多数的虚拟磁带库本身是支持重删的，而且基于硬件的重删不损耗源端和目标端的性能。目前使用的也比较多。

案例

## 1. 使用EMC NW实现异地站点容灾 ##

两台EMC datadomain各自在各自的backup zone中且由各自的EMC Networker的备份服务器进行管理。在执行本地备份时候各自管各自的事情，同时又由于使用了EMC ddboost技术，使得在备份的同时备份软件还可以向异地的站点的DD 发送克隆数据达到备份内容异地容灾的效果。

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1][]

这里说明下 ,ddboost是EMC备份软件和硬件独有的协议需要购买相应的许可，它可以使得备份源端消重。

下面呢，开始进入正题啦。

如果任何一端的备份设备和备份服务器完全毁掉了，那么该怎么办？基础东西请看EMC NW的DR教程。

假设一端全毁了，那么

(1) 使用scanner -B 找到克隆过来pool最后一个完整的booststrap

scanner -B networker\_indexclone to find out the laster bootstrap SSID

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 1][]

（2）使用临时服务器和软件许可在幸存活的站点构建临时备份服务器

nsrdr to rebuild res on the remote temporary nw server

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 2][]

（3）在临时备份服务器上找到之前克隆过来的对方站点的备份pool的信息

scanner -ivp can help your new networker server recongize that only clone pool has data

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 3][]

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 4][]

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 5][]

（4）如果以上都是正常的那么下面将使用一个简单的例子来表示下恢复的过程,以下的恢复过程将使用EMC NW的NMM工具恢复异地站点的sqlserver数据库,登陆EMC NMM选择需要恢复的客户端

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 6][]

确定需要恢复的数据都是从对方站点克隆过来的数据

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 7][]  
![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 8][]

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 9][]

那么开始在异地恢复原来的sqlserver

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 10][]

登陆sqlserver发现数据库已经恢复完成

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 11][]

其实EMC NW的DDBOOST在这里起了远端消重的作用，这样在两个异地站点克隆数据的时候传输的数据量就不是很大了。

## 2. 集群环境下的备份调度设计 ##

现在越来越多的系统建设是双机，而系统在未发生切换或者漂移的时候备份是正常运行的，那么如果当发生切换的漂移后另外的服务器的备份该如何设计呢？

还是以tsm为例，先说备份节点的，在tsm中，把备份节点做成共享节点即可。有两种方式：

1. hacmp的两个节点各种注册1个本地节点，再注册1个共享节点，然后做成授权代理节点即可。

2. hacmp的两个节点各种注册1个本地节点，再注册1个共享节点。直接用即可。tsm只认节点名，如果看actlog，节点切换时，属性会发生变化。

再说调度，也是两种方式：

1. 做成集群资源，关联到资源组里。对于Windows集群，以服务的方式做即可。对于hacmp，把调度对应的命令写到起停脚本里即可。ha这个有的缺点，进程异常死掉后，备份就停止了。

2. 通过脚本来实现，我比较喜欢的。写好脚本，脚本里包含判断，根据主服务进程来判断调度进程是不是应该启动。扔到crontab里定期执行检查即可。

放个例子，db2双机下的tsm调度进程小脚本

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1][]

[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220616/0579f58d07ba4ed38d4c3c6dfb61c28f.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220616/5b83a5e3ac6243a7acddfe13f62b38a3.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 1]: /images/20220616/e42be163b105400b92a850d542b4a6c1.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 2]: /images/20220616/9b83720c4dd74c1c97b5c656cfb6251e.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 3]: /images/20220616/2cfdf3eb59bd4fa0abe4cacf822cac0e.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 4]: /images/20220616/28df9f549dc64b3da6e16b9841fe4171.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 5]: /images/20220616/5c8eab9719944b36ab0918b3504a2986.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 6]: /images/20220616/9e9484b61ef94103a80a7045b3822c71.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 7]: /images/20220616/69d3af41e695402abfcaabdc686f3497.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 8]: /images/20220616/e0476c8d910e404b87abc7dc532c90e6.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 9]: /images/20220616/eb5f0de113304ed986a5d901d487361a.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 10]: /images/20220616/a805408ef72143e892943ee480770cf1.png
[640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1 11]: /images/20220616/edaf35a27d3044d59a01c0c246a66544.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1]: /images/20220616/d7b45915a6d743c0af1a1eeb1e61e981.png