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.容灾备份的区别

容灾 （Disaster Tolerance）：就是在上述的灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。

容错 （Fault Tolerance）：指在计算机系统的软件、硬件发生故障时，保证计算机系统中仍能工作的能力。

区别 ：容错可以通过硬件冗余、错误检查和热交换 再加上特殊的软件来实现，而容灾必须通过系统冗余、灾难检测和系统迁移等技术来实现。当设备故障不能通过容错机制解决而导致系统宕机时，这种故障的解决就属于容灾的范畴。

什么是灾难恢复 （Disaster Recovery）：指的是在灾难发生后，将系统恢复到正常运作的能力。

区别 ：容灾强调的是在灾难发生时，保证系统业务持续不 间断地运行的能力，而灾难恢复强调的灾难之后，系统的恢复能力。现在的容灾系统都包含着灾难恢复的功能，所以本文的讨论除了包括容灾方面的内容，还包括了 灾难恢复的部分内容。

容灾系统在企业中给与数据安全系数相当高的保障，但是容灾系统倒是是什么，他们是什么意思？恐怕连正在使用容灾备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释容灾备份到底是什么。

2．容灾和备份的目的不同

容灾系统的目的在于保证系统数据和服务的“在线性”，即当系统发生故障时，仍然能够正常地向网络系统提供数据和服务，以使系统不致停顿。

而容灾备份技术的目的与此并不相同，备份是“将在线数据转移成离线数据的过程”，其目的在于应付系统数据中的逻辑错误和历史数据保存。

所以，在各种容错技术非常丰富的今天，备份系统仍然是不可替代的。

3．备份是基石

备份是指为防止系统出现操作失误或系统故障导致数据丢失，而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。

备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够恢复数据。

4．容灾不可少

那么建设了备份系统，是否就不需要容灾备份系统？这还要看业务部门对RTO（恢复所需的时间指标）/RPO（能够恢复到的最新状态）指标的 期望值，如果允许1TB的数据库RTO＝8小时，RPO＝1天，那备份系统就能满足要求。同时，备份的目的在于应付系统数据中的逻辑错误和历史数据保存。只能够满足数据丢失、数据破坏时的数据恢复目的，而不能提供实时的业务接管功能。

因此容灾系统对于某些关键业务而言也是必不可少的。人们谈及容灾备份往往是针对当生产系统，不能正常工作时，其业务可由容灾系统接替这些业务，继续进行正常的工作。

能够提供很好的RTO和RPO指标。同时远程容灾系统具备应付各种灾难，特别是区域性与毁灭性灾难的能力，具备较为完善的数据保护与灾难恢复功能，保证灾难降临时数据的完整性及业务的连续性，并在最短时间内恢复业务系统的正常运行，将损失降到最小。

5．容灾不能替换备份

容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的 用户信息表也会被完整地删除。如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份，来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。

6．规划企业安全保障体系考虑的因素

对于企业而言到底应该如何建设自己的灾备系统，是只建设备份系统、还是只建设容灾系统、还是需要二者同时建设、或者是分步骤的建设，谁先谁后等问题，主要根据业务的需求而定：

（1）需要防范的灾难类型：

企业信息系统可能遇到的灾难类型及其发生的比例如下：

对于“人为错误”、“软件损坏和程序错误”加上“病毒”等这些都称为逻辑错误，占总故障的 56%，这些错误只能通过备份系统才能防范；

对于“硬件和系统故障”以及“自然灾难”等故障可以通过在容灾系统（或者异地备份）来防范，占总故障率的44%。

（2）允许的RTO和RPO指标

从技术上看，衡量容灾系统有两个主要指标：RPO（Recovery Point Object）和RTO（Recovery Time Object），其中RPO代表了当灾难发生时允许丢失的数据量；而RTO则代表了系统恢复的时间。

一般而言：容灾系统能够提供较好的RTO和RPO指标。

（3）系统投资

总的说来，建设备份系统的投资远比建设标准意义的容灾系统的投资小得多：

备份系统的投资规模一般在几百万；

而最节省的一套容灾系统投资都将上千万；

7．常用的灾备组合方式

基于以上原因，业界在灾备系统的建设上一般按照以下几种方式：

 建设机房内的本地备份系统

 建设异地的备份系统

该方式可以备份系统的价格满足备份和异地容灾功能，能够避免主生产中心由于地震、火灾或其他灾害造成的数据丢失。

 备份系统＋异地容灾系统

这是一个较为理想化的容灾系统一体化解决方案，能够在很大程度上避免各种可能的错误


3、备份、容灾如何去选择？

数据备份，是只针对业务数据进行备份，实时的也好，调度的也好，都备份的是业务中的数据或环境，用来在系统发生故障，硬件损坏，误操作等情况下恢复正确的数据或者业务环境的一种手段。数据备份一般会保存一定的周期，数据容灾是指建立一个异地的数据系统，为了保护数据安全和提高数据的持续可用性，两者其实实现的效果并不相同，一个是用来保证数据的安全性和正确性，一个是用来保证业务的实时性。如果你对你的业务和数据足够重视，那么至少线从数据备份做起，保证数据的基本安全，根据业务特点搭建容灾环境来保证业务的连续性，其实两者并不矛盾。

根据合规性检查的相关要求，比如财务系统是必须容灾加备份的，有的还要求备份到独立介质，异地存放等等，大部分容灾指的是异地数据备份，还未到自动业务切换，要达到业务级的容灾，倒不如做双活或者多活的数据中心，反而投入比单纯的容灾要值得。


4、备份数据保存多久？

需要根据业务而确定，如分为活跃数据，查询数据，冷数据等。备份策略是指综合备份类型和备份频率。如年度备份，季度备份策略，月度备份，周备份，天备份。

如果存储够，而且数据又不能确定是否有用，建议一直保存，如果不够，建议封存，如果需要找回以前的老数据，那就恢复一下。


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

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

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. 做好备份恢复测试，并设计相应的制度，定期进行备份演练。

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


6、如何选择备份软件？

在今天，主流的备份软件功能同质化，均能承担数据中心绝大部分数据备份工作。对于备份管理员，挑选一款适合自己使用习惯的备份软件尤为重要。在长期的备份系统设计与实施中，建议从三个方面考量：

1，基于个人维护习惯。适合个人维护习惯的软件，能够最大程度的契合对该软件的学习和使用成本，简单点说就是——上手难度。

2，基于方案需求。建议按照项目首要、次要、必要需求来定性挑选备份软件。再好的软件，无法解决当前问题那也白搭。备份系统相对复杂，且是一个成长型系统，在每个时期均有里程碑目标，只有一步一个脚印，系统才能健壮成长。因为涉及的方方面面多，在其建设初期需要收纳汇总各系统的情况和需求，最后集中考虑。作为备份系统的最终维护管理者，一定要明确当前的需求并分清层次，哪些是急需解决的，哪些是可以凑合的，哪些是不用着重考虑的。

3，基于产品售后。对于产品售后的定位，就和备份系统一样，一辈子都可能用不上几次，但要有用的时候若是没有，也是麻烦。对于主流的备份软件售后服务口碑也要了然于心，哪家服务不错哪家服务欠佳，任君挑选。

4、一切均以实际效果为准。挑选备份软件不能单纯依靠产品参数，不能听着吹得天花乱坠的性能就偏听偏信，综合而言，是骡子是马，拉出来溜溜。火车不是靠推的，牛皮也不是靠吹的。


7、如何设计磁带出库保存或异地恢复？

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

以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类型的不支持。


8、最后，领导不重视数据备份怎么办？

既然不重视，必然有几方面的原因。

一种情况是外行领导内行，对于数据备份的认识不够，或者认为投资高，而有没有回报，导致轻视或者减少数据备份方面的投资。只有真正经历过数据事故的人和企业才会真切的体会到数据的重要性，没出过事自然不知切肤之痛。

一种情况是难以争取数据安全方面的费用，因为没有相关文件的明文规定，所以较难获得这方面的投资，如果有，那就是不做为了。大部分现在都有指导建议，只是备份的规模可能和投入有不少差距。做好合理的数据备份规划，提交审批都算尽责了。现在不重视的人越来越少了，还是乌纱帽要紧。

如果你多次申请都没有得到回复，那能做的就是尽量自保吧。作为运维人员，数据安全上你是第一责任人，出了问题肯定不会找领导，先找到你。如果真恢复不了，你就是替罪羊。所以数据备份不备份完全是运维人员的事。即使没有条件，你也应该自己有后路，有办法将损失降到最低，这是你的职责。

1.首先，利用手头的资源尽可能的做备份。做好安全，是竭尽权利的做好这些。

2.把提交的报告形成书面的文档。得到书面的回复。出了问题。没有你的责任。

3.准备好应急方案，出现问题后哪些可以补救，哪些补救不了。出问题之后领导知道痛了需要提交怎样的申请。