随着信息系统的不断发展，企业的IT架构日渐复杂，数据量也越来越大。为了确保数据的可靠安全，各大企业都上线了自己的备份系统，来位数据中心保驾护航。但是备份软件因为自身的基因问题，涉及的方面比较广杂，在运维和故障处理过程中，常常遇到各种问题，本文基于以下几个方面进行讨论：

一. 备份系统设计相关

在备份软件的日常运维中，大多数问题的根本原因源自于初期设计问题。比如备份空间不足、备份窗口不够等等。因为设计缺陷导致的问题，解决起来也非常麻烦。需要明白的是，备份软件只是种种数据保护手段的一种，如下图所示：

在备份设计的时候，首先要考虑的是应用系统的RTO和RPO

RTO：Recovery Time Objective，故障发生后，要求恢复应用的时间窗口限制。

RPO：Recovery Time Objective，故障发生后，恢复出来的数据可以到应用的哪个时间点。

基于RTO和RPO这两个指标，需要确认以下几个设计因素：

备份存储空间设计

　　首先应该先汇总，看看当前要需要备份的系统有多少套，每套大概有多少数据量，最终得到1个初步的数据总量；
　　其次，应该了解并估算整个备份环境的增长量，以及规划的年数。比如，初步估算所有的备份数据总量为5T，每年增长20%，规划5年周期。最后的总量应该是12.5T左右；
　　最后，要确认保存的周期或保存的版本数。比如，初步按3个版本保存，40T的容量应该是没问题的。

备份存储空间对应的设备选型设计

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

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

备份窗口设计

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

备份调度的设计

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

备份恢复测试设计

并设计相应的制度，定期进行备份恢复演练。这个反而是最关键的，搞了半天备份，关键的时候恢复不了，这个就要命了，这样血的教训太多了。

相关问题如下：
问题1：企业数据备份体系需要怎么规划（我们使用的vm平台、Oracle数据库）？
很多企业信息化随着时间推移各种软件、服务器、网络架构不断调整，关心的问题一个是不同系统数据集成，最关心的是各平台数据的有效备份。平时做了逻辑备份，由于很多windows系统，为防止勒索病毒每天手工上传到Linux一份，再做离线备份一份。对数据备份最近一直也是在思考，感谢平台提供这个机会一起讨论数据备份。
请问各位老师：
①企业数据备份体系需要怎么规划（我们使用的vm平台、Oracle数据库）？如：备份环境的网络、备份硬件资源。
②大家都是这么检查备份的数据是否有效？
③是否经常做灾备演练？
④做恢复的话，大家是怎么规划的？搭建另一个相同环境恢复吗？

答：1. 这个话题比较大，可以根据rpo和rto来反推。比如1个2T的数据库，如果要求1个小时内备份或恢复完毕，就必须达到583M/S的速度。如果是磁带设备，单个LTO7的速度为300M/s左右，理论上，2个lto7的磁带机并发可完成。这只是最简单的场景，实际还有很多其他因素，如网络环境，千兆网的传输50-80M/s左右，肯定是完不成的，需要考虑万兆专网或者san网络，还比如，备份到去重池结合Oracle的proxy copy，去重率90%以上，会使得备份时间大幅缩短。 这些在方案设计时都是需要考虑的因素。

2.一般有两种，一是利用备份软件或应用软件来检查，如nbu的bpverify；二是搭建测试环境，定期进行恢复测试，推荐2

3.有必要。

4.如果仅验证数据，恢复环境不要求和备份环境的硬件配置一模一样，但是软件环境需要一样。

二. 应用备份相关

备份系统备份数据时，不同的应用有不同的备份要求。比如数据库备份和文件备份相比就有很大的不同，需要保证备份数据的一致性。如果单纯的将运行中的数据库文件拷贝出来，根本就无法正常运行。需要采用备份软件专门位应用软件开发的备份代理程序。

1). 备份软件选型的时候需要尽量覆盖到当前数据中心的应用程序。

2). 在备份软件支持自己应用的基础上，可以优先考虑一些高级特性的加分项。比如同样是备份VMware，如果结合去重技术可以使得备份时间和备份存储空间占用大幅度减少。

3). 在配置或运维过程中，不同的备份软件对不同应用的不同模式都有特殊的要求，配置和使用过程中，要养成仔细阅读官方文档的习惯，很多问题都是不看官方手册，自己想当然的做，做出了问题。

以下是活动中几个典型的应用备份问题：

问题1: 影像系统中的小文件备份速度慢，如何解决，有什么好方法？
我们医院的影像系统有非常多的小文件存放在netapp的存储上， 现在备份是通过主机端以nfs和cifs的方式来备份，备份速度特别慢，有时候一次备份两三天，最后还失败了，请问有什么好办法吗？备份软件是nbu

答：从主机端挂载cifs或nfs，以nbu客户端的方式备份，确实非常低效，再加上是海量小文件，备份效率低下是难免的。海量小文件的备份是个老大难，不好做。 不过你的环境还好，有nas设备，建议直接使用ndmp来备份，注意如下几点：

ndmp需要单独的license，确保已购买并添加激活

ndmp的备份原理是通过ndmp协议将nas上的卷备份到nbu里，恢复的时候可以以单个文件的方式恢复。 备份前nas会给备份的卷打个快照。

nbu for ndmp支持3种模式
1） local模式，就是直接将磁带库挂到nas上，只能使用磁带库或虚拟磁带库
2） remote模式，备份通过网络备份到media server上，可以是磁盘也可以是磁带。 一般推荐使用msdp去重池。
3） 3-way模式： 把nas数据备份到其他连接带库的nas上

针对netapp的存储，nbu的policy支持accelerator加速备份， 也就是备份时会将变化的数据记录到master和media的traklog里，下次只备份变化的数据，可以大幅度缩短备份时间。

配置过程比较简单，通过java console为netapp设备添加凭据，然后创建policy的时候直接勾选对应的volume进行备份即可。

限制： 只能做基于卷的备份，不能细化到卷之下的目录。

**问题2: 存储空间比较紧张的情况下，如何提升Oracle备份的去重率？
有个问题请教下，我们使用nbu的系统做备份虚拟机和数据库，备份到msdp去重池里，发现备份VMware的去重率特别高，Oracle备份就比较低，才50%左右，我们的存储空间比较紧张，有没有什么比较好的办法把去重率提上来？**

答：nbu配置Oracle备份，有两种方式：

传统脚本方式， 就是创建1个备份脚本，policy调用这个脚本来备份

智能策略： 先从java console注册Oracle实例，在创建策略的时候直接通过注册的Oracle实例，勾选要备份的数据库即可。

这两者的区别，当目的地为msdp时，默认情况下基于脚本的备份产生的是普通备份集，基于智能策略的备份使用的是proxy copy的方式， 通过解析，抓取智能策略的脚本如下：

RUN {
ALLOCATE CHANNEL ch00

TYPE 'SBT_TAPE'
PARMS 'SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so64';

BACKUP

INCREMENTAL LEVEL=0 PROXY
FORMAT 'bk_d%d_u%u_s%s_p%p_t%t'
DATABASE

RELEASE CHANNEL ch00;
}

所以，proxy copy的去重率会特别高，通常会高于90%， 所以，如果像提高Oracle的去重率：

1.采用智能策略
2.采用传统脚本策略+proxy copy类型的备份脚本

**问题3：nbu支持alwayson的集群环境吗？在备份sql 2017 alwayson集群时，老是备份失败，请问什么原因？
我们一直在使用nbu 7.7.3备份sql server 2012，最近计划升级到sql server2017， 就做了一套sql 2017 alwayson集群的测试环境，发现老是备份失败，作业信息的失败代码是2，请问什么原因，nbu支持alwayson的集群环境吗？**

答：nbu是支持sql alwayson架构的， 但是根据兼容手册，sql2017要求的最低版本是nbu8.1.1 建议先将nbu升级到8.1.1或更高

nbu对sql alwayson的支持是有严格要求的，备份失败大部分都是没按要求来做，参考以下过程：

关于用户权限
1） 登陆用户必须加入本地administrators组（Computer Management -> Local Users and Groups ->Groups ->Administrator - 需要加上SQL Server的账户）
2）必须通过sql management工具，将登陆用户加入sysadmin角色（通过sql server management studio---安全性-> 登录名 - 登录属性 - 服务器角色 - 勾选 sysadmin）
3） NetBackup Client service NetBackup Legacy service和NetBackup Legacy Network service更改为当前登陆用户，重启服务 4）nbu 客户端的域账户需要配置组策略：本地安全策略---本地策略---用户权限分配
---通过身份验证后模拟客户端（Impersonate a client after authentication）
---替换一个进程及令牌（ Replace a process level token） ---作为服务登录（logon as service）

运行组策略更新命令(组策略更新)使此项更改生效：

  gpupdate /Force

加入always on的db，采用集群方式备份，使用一个单独的策略。没加入的采用本地方式备份即可

关于always on类型db的策略设置
1）加入always on的db，只能采用脚本方式备份，并且需要将db包含的所有节点都添加到策略里
2）各节点所用的脚本必须起相同的名字，放到相同的目录下面
3）执行策略备份时，backup image所属节点实际上是failover cluster的节点名，必须可以被解析

关于脚本配置:
需要使用nbu sql gui，以本地名称添加sql链接，然后通过backup 生成脚本，将下面的一行增加到脚本里。
PREFERREDREPLICA TRUE
备份的时候，同时两个节点发起，根据always on的策略，不备份的那个节点会自动退出。参与备份的节点开始备份。

关于日志截断：
1）加入ag的db到底从哪个节点发起备份，是由sql server always on的属性（通过sql server management studio）决定的，默认从备库，可以更改。
2）从备库发起备份的限制：只能做全备份，不能做增量和日志备份
3）完全备份和差异备份不会截断日志，只有日志备份才会截断
所以如果想实现日志截断，需要配置ag备份从主节点备份，且额外配置一个policy来备份事务日志。生成日志备份脚本的方式参考步骤4

关于恢复：
1）恢复时要使用nbu ms sql client，恢复always on包含的db时，必须使用Failover cluster的名称，否则刷不出备份信息。
2）因为涉及不同节点，master server端必须要创建No.Restrictions文件。

    Windows平台：
    install_path\\Veritas\\NetBackup\\db\\altnames\\No.Restrictions
    unix平台：
    /usr/openv/netbackup/db/altnames/No.Restrictions

3）恢复时，必须先把要恢复的db从ag里移出来并删除
4） 然后通过nbu ms sql gui创建恢复脚本，脚本类型为create a move template，recoverred，保存为脚本名称
5） 修改脚本，指定恢复数据库的名字 数据文件和日志文件的位置 执行恢复，将恢复到本地节点
6）通过sql server management studio界面，允许ag添加db的向导，把db重新加入到ag即可

三.备份技术和方案相关

备份软件的知识结构中，除了和应用相关的知识外，备份软件自身的知识也挺多的。比如磁带库相关技术、公有云技术、加密技术、重复数据删除技术等。

下面是相关的几个问题：

问题1：企业核心数据库数十TB且日益数据量增长，数据备份有啥好解决方案？
随着数字化信息时代的到来，企业传统数据库、虚拟化环境、云上数据以及OA、邮件基本上都配齐了，一般核心数据库都是数十TB，而且日增数据量非常大，用传统的备份软件和虚拟带库进行备份，做一次全备份的时间窗口相当长，恢复演练的时间也耗时太长。另外工作中经常要克隆生产环境到测试环境进行开发与测试。
如何更好地管理和利用备份数据，有什么更好的解决方案？
1、当前主流的虚拟带库产品有哪些？能同时支持FC和ISCSI方式稳定备份，磁带写入速度与磁盘阵列无太大性能差异，能有效缩短备份时间窗口。
2、有哪些能同时实现上述数据管理功能的备份一体机方案？

答：从高可用的角度来说，应该采用多种方式，比如分库、双活、基于应用或者存储的双活，这个是题外话，传统备份还是有一定的不可替代性，数据量大了确实是个问题. 下面是和备份相关的.

在原有架构上下功夫提升备份速度，比如加大备份恢复任务的并行数（如果是带库，增加磁带机），选用高速存储介质，如lto4更换lto7磁带机。 4G FC环境升级到16GB环境，千兆改万兆等，采用单独的备份网络

2.采用重删技术。 有基于软件和基于硬件的去重。基于软件的一般为备份软件自带，如tsm的目录池，nbu的msdp。 基于硬件典型的有集成到虚拟磁带库里的，或者其他存储集成方案，如emc的boost和nbu的ost集成。 从去重操作端来看，有源端去重和目标端去重。 源端的发送数据少，占用客户端资源多些，目标端去重传输量大些，客户端压力小些，具体需要根据自己的情况。

其他和应用集成的备份技术，简单列举几个
---比如和存储快照集成的，IBM的fcm方案。 和存储快照集成，可以到分钟级别
---或者nbu的accelerator加速，备份VMware是全备也可以利用cbt，备份时间特别短。
---Oracle的proxy copy备份和其他备份软件去重技术结合，去重率可以达到90%以上，备份时间也会大幅度缩短。

一体机方面，nbu、cv、国内的爱数、火星等都有相关的一体机

问题2：用tsm备份db2数据库和用nbu备份db2数据库，在操作上有什么区别？
答：区别比较大，说实话如果环境里db2多，干脆用tsm得了，因为tsm和db2都是IBM产品，集成度特别高，操作也比较简单

一. 先说数据备份吧

tsm配置步骤：

1. db2开启归档， 开启归档需要做脱机备份

如果需要增量，设置trackmod参数为on

执行节点验证：/home/db2inst1/sqllib/adsm/dsmapipw 需要tsm服务端先注册节点

直接备份即可

db2 "backup db xxx online use tsm open 4 sessions include logs"

nbu配置步骤：

db2开启归档， 开启归档需要做脱机备份

如果需要增量，设置trackmod参数为on

添加db2实例 /usr/openv/netbackup/bin/db2_config

根据/usr/openv/netbackup/ext/db_ext/db2/scripts/下的示例修改备份脚本

在java console配置policy

配置db2.conf文件，参考内容如下：
DATABASE xxxdb
OBJECTTYPE DATABASE
POLICY xxxdb_backup_policyname
SCHEDULE Default-Application-Backup
ENDOPER

二. 日志备份

db2最恶心的就是日志备份，都是通过修改LOGARCHMETH1参数实现的

tsm配置：

使用tsm，日志切换有两种
1.使用tsm，日志直接切换到tsm里
db2 update db cfg for xxx using logarchmeth1 TSM

2 使用disk，日志切换到磁盘上，可以使用tsm归档走， 也可以使用tsm备份走，然后通过脚本删除日志 db2 update db cfg for testdb2 using logarchmeth1 DISK:/db2data/archlog

nbu配置：
四种方式：
1.使用disk，日志切换到磁盘上，可以使用user archive备份走， 也可以使用普通的文件备份policy备份，然后通过脚本删除日志
db2 update db cfg for testdb2 using logarchmeth1 DISK:/db2data/archlog

2.vendor方式： 直接切到nbu里
db2 update db cfg for testdb1 using logarchmeth1 VENDOR:/usr/openv/netbackup/bin/nbdb2.so64

然后通过db2.conf控制
DATABASE testdb1
OBJECTTYPE ARCHIVE
POLICY db2_testdb1_full
SCHEDULE db2log_vendor
ENDOPER

3.arcfunc save方式 save方式的直接将日志切到nbu里，通过nbu里的user backup类型的策略备份归档日志。前滚的时候无需人工干预，直接通过出口程序找日志。
db2 update db cfg for testdb3 using logarchmeth1 userexit

然后通过db2.conf指定
DATABASE testdb3
OBJECTTYPE ARCHIVE
POLICY db2_testdb3_logsave
SCHEDULE user
ARCFUNC SAVE
ENDOPER

4.arcfunc copy 方式会先将日志归档到arcdir里，归档成功后删除，日志是通过user archive策略来备份的
db2 update db cfg for testdb4 using logarchmeth1 userexit

再通过db2.conf控制
DATABASE testdb4
OBJECTTYPE ARCHIVE
POLICY db2_testdb4_logcopy
SCHEDULE user
ARCFUNC COPY
ARCDIR /db2data/db2inst2/arcdir
RETDIR /db2data/db2inst2/arcdir
ENDOPER

日志总结：
小库使用vendor或者tsm都可以，管理方便。 大库建议放本地，如果备份服务器繁忙或者备份服务器offline，db2数据库容易hang住