备份对于企业业务来说至关重要，但备份建设中常出现一些认识盲区和误区，以及一些难点和坑点，以下内容来自社区日常交流探讨，整理于此供大家参考。来自社区会员李志刚、Jerry Lee等分享。
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、用双机、阵列复制等系统冗余替代数据备份
双机双柜可实现服务器和存储的高可用性，保障业务持续运行，但绝不能替代备份，因为双机双柜能解决数据的物理错误，例如：服务器或存储故障，但解决不了数据的逻辑错误，例如：病毒，人为误删除数据（rm–f）等。
4、写脚本备份数据库代替数据备份软件
1个2个数据库还能操作过来，假如有100个数据库呢？除了数据库，其他的都要写脚本吗（除非是要开发个备份软件）？非常不建议这样操作，因为这样做问题太多了，如果有条件，就不要再人为写脚本备份了，我碰到过一个内部同行，一直用脚本备份的Oracle数据库，等恢复的时候发现每天备份的都是0KB，这才开会讨论脚本备份的没有数据验证功能。需要一套专业的备份软件来做这件事情，否则可能灾难重现。
5、操作系统不用备份？
有人说，系统备份什么？坏了就重装呗，数据不丢就行，首先大家应该都用过Ghost软件，容易不?太容易了！其实Unix、Linux、Windows等系统备份恢复如果学会使用不比Ghost难多少，光盘启动，找到想恢复的时间点，分分钟系统就恢复到备份时的状态，但我们想一想，如果没有系统备份工具，我们要重装系统，然后找驱动，安装软件，系统优化，测试，这要多久，一个资深的运维技术6个小时你敢承诺系统能上线吗？我想没有人敢保证，我曾经看过一个工程师为了一个网卡驱动（非常老的服务器）花了一上午的时间。而且有的时候当时部署系统的工程师已经不在了，系统装上了，应用没人会装。想想现在我们的技术人员是不是大半夜的还有在机房维护操作系统的？运维人员忙的要死，天天救火，但技术又没什么长进，想想时间都去哪了。
6、想用CDP（数据保护）代替备份
不论是True CDP还是CDP（就是业内说的真假CDP）都代替不了备份。我们都知道备份都是放在系统空闲时做，除了游戏企业外其他大多数企业都会选择在夜里备份，因为备份会占用大量系统资源，系统繁忙的时候是不可以备份的，（除非你想让用户骂）。CDP顾名思义持续数据保护，不论真假CDP，24小时不间断对系统IO读取，对系统的性能影响可想而知，CDP通常嵌入数据中心关键业务应用的I/O路径中，是一个I/O聚散点，其任何不稳定都可能导致关键业务停顿。所以CDP只能用在部分业务上，增强备份软件RPO的指标参数，而不是替代备份软件，不会有企业傻到所有业务都采用CDP保护，而且CDP一定要测试后方能使用，如果遇到产品问题或兼容性问题，你的业务系统可能宕机。
7、领导不重视数据备份
既然不重视，必然有几方面的原因。
一种情况是外行领导内行，对于数据备份的认识不够，或者认为投资高，而有没有回报，导致轻视或者减少数据备份方面的投资。只有真正经历过数据事故的人和企业才会真切的体会到数据的重要性，没出过事自然不知切肤之痛。
一种情况是难以争取数据安全方面的费用，因为没有相关文件的明文规定，所以较难获得这方面的投资，如果有，那就是不做为了。大部分现在都有指导建议，只是备份的规模可能和投入有不少差距。做好合理的数据备份规划，提交审批都算尽责了。现在不重视的人越来越少了，还是乌纱帽要紧。
如果你多次申请都没有得到回复，那能做的就是尽量自保吧。作为运维人员，数据安全上你是第一责任人，出了问题肯定不会找领导，先找到你。如果真恢复不了，你就是替罪羊。所以数据备份不备份完全是运维人员的事。即使没有条件，你也应该自己有后路，有办法将损失降到最低，这是你的职责。
1.首先，利用手头的资源尽可能的做备份。做好安全，是竭尽权利的做好这些。
2.把提交的报告形成书面的文档。得到书面的回复。出了问题。没有你的责任。
3.准备好应急方案，出现问题后哪些可以补救，哪些补救不了。出问题之后领导知道痛了需要提交怎样的申请。
8、不知道如何选择备份软件
在今天，主流的备份软件功能同质化，均能承担数据中心绝大部分数据备份工作。对于备份管理员，挑选一款适合自己使用习惯的备份软件尤为重要。在长期的备份系统设计与实施中，建议从三个方面考量：
1，基于个人维护习惯。适合个人维护习惯的软件，能够最大程度的契合对该软件的学习和使用成本，简单点说就是——上手难度。
2，基于方案需求。建议按照项目首要、次要、必要需求来定性挑选备份软件。再好的软件，无法解决当前问题那也白搭。备份系统相对复杂，且是一个成长型系统，在每个时期均有里程碑目标，只有一步一个脚印，系统才能健壮成长。因为涉及的方方面面多，在其建设初期需要收纳汇总各系统的情况和需求，最后集中考虑。作为备份系统的最终维护管理者，一定要明确当前的需求并分清层次，哪些是急需解决的，哪些是可以凑合的，哪些是不用着重考虑的。
3，基于产品售后。对于产品售后的定位，就和备份系统一样，一辈子都可能用不上几次，但要有用的时候若是没有，也是麻烦。对于主流的备份软件售后服务口碑也要了然于心，哪家服务不错哪家服务欠佳，任君挑选。
4、一切均以实际效果为准。挑选备份软件不能单纯依靠产品参数，不能听着吹得天花乱坠的性能就偏听偏信，综合而言，是骡子是马，拉出来溜溜。火车不是靠推的，牛皮也不是靠吹的。
9、针对企业现有的数据规模，不知道如何规划存储类型、容量并设计合适的调度作业
见过不少客户的备份环境，用起来资源紧张，捉襟见肘。有的是备份空间不足，被迫修改保留策略。有的是受限客观环境，通道不足导致备份窗口加长，最后备份失败。总而言之，大都是是初始规划设计方面准备不足，导致后期维护困难。可以从以下几个点来考虑：
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.做好备份恢复测试，并设计相应的制度，定期进行备份演练。
这个反而是最关键的，搞了半天备份，关键的时候恢复不了，这个就要命了，这样血的教训太多了。
10、不知道如何如何评估备份策略
对于备份策略的制定，一是保持高效，尽量在最短的时间完成备份恢复，为其他任务节省时间窗口；二是尽量降低网间压力，降低备份恢复对系统的压力……
举个例子，简化下环境因素，比如影像服务器上的保单影像件，数据量约500GB，千兆以太网络，如何评估备份？
首先从高效方面考虑，影像件通常是碎片文件，不满足集中备份的数据特征，因此就需要评估影像件是否接受压缩打包之类的处理，将碎片文件聚合成大文件。压缩打包之后对精确恢复又增加了难度，最小的恢复单位变成了一个压缩包，所以平衡备份高效性和恢复难易度就成了一个平衡的博弈；对于网络压力来说，若是500GB的碎片文件，备份速度和效率不会很大，但耗时特长，影像服务器压力不高时可接受；若是多个压缩包汇集的500GB文件，那备份速度明显增加，可能对影像服务器的网络负载构成一定影响，这个时候就需要考虑是否增加agent去分担影像服务器的压力了……
当然，影像件的备份需要考虑的远不止这些，影像件的文件类型也是要重点考虑的，若是把这些都带入这个问题，那就无比麻烦了…
备份策略的优化需要长期的经验积累，同时也需要根据实际情况因地制宜。
11.数据备份在关键时刻无法恢复
此前在运营商闯荡的时候，遇到过一起很典型的掉链子例子：
运营商的好多客户数据都是需要长期保存的，而且不能丢，遇到重大刑侦案件的时候往往要调取这些数据协助调查，如果提供不出来，会对公司当年的考核影响很大。有一次呢，遇到了一个大案，上头发文让协助调查，需要恢复指定的通话记录和部分内容，在系统里很快就查到当年数据的所在业务系统，定位到了数据所在的服务器，随后确定了数据的时间，接着就让备份管理员开始着手恢复数据，检查恢复环境，检查数据备份状态，确认数据时间版本，一切OK，开始恢复，恢复完了都傻眼了……恢复了一堆数据，里面压根没有需要的数据。
后来查证，原来因为系统的某个需求变更，一部分业务数据被独立出来，存取路径变更了，变更也没告知备份管理员，同时这部分业务数据体量又很小，整个系统数据备份的体量远大于这部分数据，备份软件的监控上备份任务详情里无论从备份数据量、备份时间都在正常范围内。更不幸的是，这个系统从来都没被抽到进行数据恢复演练……因此独立出来的数据，这几年都没备份……
实践是检验真理的唯一标准，对于备份恢复也是如此。智者千虑必有一失，作为数据保护的最后一道防线，其核心本质就是可靠、完整、安全。不管是思路、策略还是配置上的疏漏，在演练中均可暴露出来，让管理员及时查漏补缺。
