如何避免你的备份“掉链子”
备份恢复软件系统在各大企业中表现出的“水土不服”，很大原因均是选型设计的问题。虽然备份恢复系统在众多企业的信息化建设内是一个小体量项目，但项目的隐藏难度却并不小——设计者不仅仅要对备份恢复软件系统了如指掌，还需熟悉企业业务系统架构，并对数据中心内业务系统软件和基础资源体系拥有足够的了解，缺一不可。本文由金融行业备份专家Jerry整理分析了几个避免备份“掉链子”的方式方法。
1. 你的备份掉链子过吗？都遇到过哪些数据备份在关键时刻无法恢复的情况？
@hufeng719 某制造集团 系统工程师：
目前备份只有DB2数据库用到过，没有遇到过硬件无法启动、数据库无法启动等大的故障，只是误删除表数据，误删除某个或几个表。这个时候数据库还能运行，只是丢失部分数据，直接从备份中还原即可。
SQLServer数据库只做过测试，通过数据库备份和事物日志备份能够在新机器上还原到事物日志最后备份的时间点数据库状态。
Oracle数据库RMAN恢复未做过测试，只是用exp、imp做过导出导入的还原操作，这种肯定会丢失部分数据。
Mysql数据库也是用sqldump备份 source还原过。
所以，Mysql和Oracle如何能够还原到故障点发生时的数据库状态，还需各位大侠一起分享经验。
@Jerry 某保险公司 系统架构师：
此前在运营商闯荡的时候，遇到过一起很典型的掉链子例子：
运营商的好多客户数据都是需要长期保存的，而且不能丢，遇到重大刑侦案件的时候往往要调取这些数据协助调查，如果提供不出来，会对公司当年的考核影响很大。有一次呢，遇到了一个大案，上头发文让协助调查，需要恢复指定的通话记录和部分内容，在系统里很快就查到当年数据的所在业务系统，定位到了数据所在的服务器，随后确定了数据的时间，接着就让备份管理员开始着手恢复数据，检查恢复环境，检查数据备份状态，确认数据时间版本，一切OK，开始恢复，恢复完了都傻眼了……恢复了一堆数据，里面压根没有需要的数据。
后来查证，原来因为系统的某个需求变更，一部分业务数据被独立出来，存取路径变更了，变更也没告知备份管理员，同时这部分业务数据体量又很小，整个系统数据备份的体量远大于这部分数据，备份软件的监控上备份任务详情里无论从备份数据量、备份时间都在正常范围内。更不幸的是，这个系统从来都没被抽到进行数据恢复演练……因此独立出来的数据，这几年都没备份……
简评：实践是检验真理的唯一标准，对于备份恢复也是如此。智者千虑必有一失，作为数据保护的最后一道防线，其核心本质就是可靠、完整、安全。不管是思路、策略还是配置上的疏漏，在演练中均可暴露出来，让管理员及时查漏补缺。
2. 随着业务系统的增加，备份恢复网络负载逐渐走高，有哪些技术能够帮助减少备份网络压力？
@Jerry 某保险公司 系统架构师：
对于备份网络负载的优化并不是一朝一夕的事，但一般情况下最简单的方式便是采用重复数据删除技术，大幅减少备份网络上的数据传输以及后端备份存储的压力。
不少企业在备份恢复系统建立之初，也采用了重复数据删除技术进行备份恢复，为什么重删效率不理想，网络压力依旧高呢？重删技术的实际性能表现主要由两大方面决定：首先是数据源的数据类型，其次是重删配置参数的调优。对于重复数据删除技术，本人在此前的交流活动中分享了非常完善的原理剖析，若有兴趣可进行拓展，文章地址http://www.talkwithtrend.com/Document/detail/tid/413365
@潘延晟 系统工程师：
目前最常用有效的应该就是LANFREE了。另外如果没有SAN架构。也可以去采用独立的网卡搭建一个专门的备份网络。减少对正式业务网络的影响。
简评：备份恢复流量影响生产系统、造成网络负载高是一个常见场景，所以现今的设计内备份网络一般是独立网络，走单独的网卡或者HBA卡。对于给备份网络减压，结合实施成本与实际效果综合考量，最优解就是重复数据删除技术，重删有源端和目标端两种形式，可根据业务情况进行选择。
3. 备份系统如何实现快速的备份和恢复？
【问题描述】现有的环境是NBU+虚拟带库，整体架构比较老式。需求是：想实现对一些近60TB的零散的大量文件进行备份，而且经常需要进行数据库的备份恢复。是否有新的备份体系，可以实现无需通过恢复的方式，就可以对备份的数据进行读取和抽取。
@某集团 系统架构师：
1、备份：
NBU和Commvault都能实现备份快，但实现原理不同。
NBU是通过在文件系统中使用tracking file来做文件级别的备份，因此无法避免首次备份慢的问题，后续还是看变化情况，如果变化量不大，是OK的，除此之外，还需要定期进行force rescan，否则会出问题。以前7.0时代曾经用过flash backup技术，但需要有专门的快照卷，而且备份大小是卷的大小，后面此技术被前面这种基于tracking file的accelerator技术取代。
Commvault是通过块级别的备份，首次全备份和后续增量备份可以很快，结合合成全备份可以实现永久增量备份。块级备份对生产影响小，不用担心扫描和备份海量文件对生产的影响。Commvault还可以在同一个任务里实现备份和归档，可选择留或者不留存根文件，有存根文件就可以实现用户无感知的访问已归档走的文件。
2、恢复：
NBU基于tracking file的accelerator只能用于备份加速，遇到还原的时候，还得实打实的恢复，相当于首次备份的速度。
Commvault的还原可以从块级别备份中还原单个文件，还原整个卷到源卷、不同卷和异机均可，规避了还原小文件慢的问题，还可以按需挂载成一个路径，支持挂载到原机和异机，比较灵活。
@Jerry 某保险公司 系统架构师：
60TB的文件不知道是小量的零碎文件还是大规格的数据文件，如果是海量小文件的问题，只能想办法改善备份慢的问题，能够完美解决海量文件备份效率的方案，成本都不低，入不敷出。
利用块级别备份备份海量文件，虽然可以解决备份效率慢问题，但是恢复的时候无法精确恢复单个文件，因此在备份的时候需要更多规划，包括数据存取，数据结构等。往往这更多规划，难以实施，海量小文件的形成必然是长时间的积累，为了备份恢复去大刀阔斧的改造，很多企业都下不了狠手。
海量小文件的问题，更多的可以从两个方面入手，第一个是优化海量小文件的文件结构，想办法把小文件聚合成大文件，提高备份恢复效率，减少文件扫描的时间成本，常见的做法就是进行打包压缩。第二个就是改变海量小文件的存储方式，海量小文件备份恢复慢，绝大部分是对文件的扫描、备份时因为数量庞大导致open files、close files的次数特别多，如果不是以小文件方式直接备份恢复文件、直接从系统底层直接抽取数据进行备份恢复……在这点上不少企业使用了对象存储，需要注意的是对象存储的备份接口引擎，可能需要定制化。
数据库的场景，可以采用CDM技术进行，CDM备份只要条件满足，可以直接抽取备份副本直接拉起数据库，这点在很多场景比传统恢复方便，但同时你也要接受这种方案的高成本和高环境要求。
简评：直接从备份存储拉起数据，这是CDM类产品擅长的，传统备份恢复系统起初并不是遵循瞬时恢复而设计，而是考虑长期数据保护，两者的出发点就已经不一样。对于核心数据，恢复要求较高的，建议采用CDM方案，基本都能做到瞬时恢复直接拉起，但其成本与要求较高，还得根据实际情况来确定。
4. 对于长期数据保留，是采用大容量去重磁盘设备好？还是磁带库好？
@潘延晟 系统工程师：
因为有过教训。所以对于数据的备份。我一向秉承着在我资金允许的范围内尽可能多的备份。短期数据备份用磁盘。长久保存用磁带。磁带要定期更换。
另外还有一点就是你能承受数据丢失的程度和你备份的投入的比例。如果数据不算太重要。那么有个基本备份就好。随着数据越来越重要。这部分备份的投入也要不断的增加。方式也要多种多样。
@Jerry 某保险公司 系统架构师：
长期保留数据，采用大容量去重磁盘设备和磁带库均可，主要有几方面需求因素影响最终选择：
1，是否需要离线？异地保存？
如果有这方面的要求，基本只有磁带库选择。
2，综合能耗成本考虑
采用大容量去重磁盘设备的综合能耗成本基本远大于磁带库的能耗，另外需要注意的是磁盘的故障率比磁带高很多，磁带如果保存条件良好可以保存十年之久，而磁盘很难。如果没有这方面考虑，两者都是不错的选择。
3，管理难度
一般来说磁盘设备的管理难度小于磁带库，磁带库的磁带机、机械臂都属于高精密仪器，高频度使用耗损还是很严重的，出问题了进行更换后往往还涉及一系列的配置问题。磁盘设备不管是基于虚拟磁带库还是高级文件系统，在这方面的配置都比磁带库方便的多。
4，恢复效率
这一部分两种存储介质的区别并不是很大，多个磁带机并行也能达到磁盘控制器相近的速度。
@luo_x_f 某软件集团 系统架构师：
对于长期数据保留，首先看数据类型（是结构化数据还是非结构化数据），其次看其数据的使用频率（经常使用还是偶尔使用），最后就是你的投入预算。
对于大容量磁盘，一般都是做虚拟带库。需要考虑磁盘的电子元器件老化（硬盘使用寿命一般不超过8年），同时只要运行就需要用电，后续的成本投入会比较高。
对于磁带库需要考虑备份速度和备份时间窗口，电费应该能省不少。磁带放置在电子防潮柜，恒温恒湿环境理论是30年，一般是10年进行换代（存取速度、介质容量、驱动器都有几倍提升）。如果数据量比较小，那可以直接买个较大容量的磁带库，所用磁带直接放到磁带库中。如果数据量大或者是需要异地存放，那就要考虑电子防潮柜建设及维护。另外，如果是保存非结构化数据，磁带库的LTFS技术配合磁带厂商的软件可以把磁带库直接当成NAS使用。
简评：备份数据存储的选择需要诸多方面的权衡，以数据为重？以成本为重？还是以效率为重？一般对于数据长期保留需求，建议以磁带为主，可以辅助其他方式存储作为备用介质。磁带，无论是出入库异地保存，备份恢复速度，还是综合使用成本，相较而言合适得多。
5. 如何增加海量小文件的非结构化数据备份的速度？
@Jerry 某保险公司 系统架构师：
海量小文件的问题，现在一直没有根本性解决，能够完美解决海量文件备份效率的方案，成本都不低，入不敷出……
海量小文件的问题，可以从两个方面入手，第一个是优化海量小文件的文件结构，想办法把小文件聚合成大文件，提高备份恢复效率，减少文件扫描的时间成本，常见的做法就是进行打包压缩。第二个就是改变海量小文件的存储方式，海量小文件备份恢复慢，绝大部分是对文件的扫描、备份时因为数量庞大导致open files、close files的次数特别多，如果不是以小文件方式直接备份恢复文件、直接从系统底层直接抽取数据进行备份恢复……在这点上不少企业使用了对象存储，需要注意的是对象存储的备份接口引擎，可能需要定制化。
简评：海量非结构化小文件备份恢复问题，一直是容灾上的难题。在海量非结构化文件的备份恢复过程中，非结构化文件的扫描将消耗大量时间成本，碎片性质更一步降低了系统效率。这是文件特征，也是文件结构类型决定的，即使采用存储级快照技术解决了备份效率问题，恢复时精度又得不到保证，投入和产出比低，效果也不尽如人意。因此，对于此类问题建议折中处理，减少海量、小文件的产生，以少聚多，以小变大，将海量、小的问题转变为适量、适中的方向来解决。
6. 如何评估备份策略？
@Jerry 某保险公司 系统架构师：
对于备份策略的制定，一是保持高效，尽量在最短的时间完成备份恢复，为其他任务节省时间窗口；二是尽量降低网间压力，降低备份恢复对系统的压力……
举个例子，简化下环境因素，比如影像服务器上的保单影像件，数据量约500GB，千兆以太网络，如何评估备份？
首先从高效方面考虑，影像件通常是碎片文件，不满足集中备份的数据特征，因此就需要评估影像件是否接受压缩打包之类的处理，将碎片文件聚合成大文件。压缩打包之后对精确恢复又增加了难度，最小的恢复单位变成了一个压缩包，所以平衡备份高效性和恢复难易度就成了一个平衡的博弈；对于网络压力来说，若是500GB的碎片文件，备份速度和效率不会很大，但耗时特长，影像服务器压力不高时可接受；若是多个压缩包汇集的500GB文件，那备份速度明显增加，可能对影像服务器的网络负载构成一定影响，这个时候就需要考虑是否增加agent去分担影像服务器的压力了……
当然，影像件的备份需要考虑的远不止这些，影像件的文件类型也是要重点考虑的，若是把这些都带入这个问题，那就无比麻烦了…
简评：备份策略的优化需要长期的经验积累，同时也需要根据实际情况因地制宜。
如有任何问题，可点击文末阅读原文到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
几个关于企业备份系统建设及运维的问题
http://www.talkwithtrend.com/Article/219961
欢迎关注社区 “数据备份”技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/45
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场