因为影像文件比较多，备份窗口比较小，如何解决影像备份问题？

感谢samsondows的分享。关于这个问题，补充一点个人的经验。

       关于大量碎片文件的备份，目前行业内没有特别直接有效的方法，即使是成本较高的存储级别复制，也难以达到长期保留的目的。此前借交流会和国外的容灾和业务专家谈及这一点的时候，他们也表示在国外过去的十几年里也存在这种问题，但现在已经想办法规避了，规避的原则是正规化业务、优化小文件的存取方式，减少小文件的数量。国内之所以这个有问题尤为明显，很大原因是业务模式不规范且固定，很难整体优化改善，加上是历史问题，动刀起来很麻烦。

       个人维护过的备份容灾系统，也有财大气粗的大企业直接拿存储来做复制，利用两套存储来达到长期保留的目的。但一般类似影像录音文件或者话单文件，几乎都是要永久保存的。从长远眼光来看，这种做法维护成本高，且效率不是特别理想，属于高投入低回报的措施，可总归是一种解决办法吧。

       再者，很多公司考虑NDMP备份，虽然说这个做法屏蔽了一部分影响备份效率的因素，但归根到底，根本原因没有完全改善。相对于直接拿存储做复制来说，算的上一种低廉但有效的措施。

       最次，一些对安全性完整性要求不太高的公司，干脆搞一套NAS让这些头疼的碎片文件自个儿乐，不备份！这一种做法，哈哈，算破罐子破摔了。

      最后说说我推荐的做法，我们先从根本讲起：

1，海量小文件为什么让人头疼？

      望文知意，文件小、数量多，那么读写效率必然低，积少成多之后问题越放越大，最后就是一块烫手的山芋。

2，常规的三种做法问题在哪儿？

      存储复制，成本高，效率低，文件系统大了，仅这一项保存方案就是一笔不小的开支，但高投入也并没有带来多大的回报，勉强是完成了任务。

      NDMP备份，治标不治本，但成本较低，对于中小型公司来说，不失为一种有效的做法。

      NAS保存，数据的安全性完整性低，用句调侃的话来说--“你就自个儿偷着乐吧，乐出事来就拜拜了”。

3，改善方向？

     从根本原因入手，小文件，那就聚合成大文件；海量，那就分门别类方便读写，然后尽可能避免和减少数量。说到底海量小文件还是早期业务不规范导致，现在规模大了也不好改善。但对于这个问题改善的方向，只可能是优化文件的存取方式，尽可能减少其规模。

4，个人推荐的折中做法

      此前一直接触运营商的业务系统比较多，运营商的话单、录音和保险里的影像文件差不多，所以基本可以混为一谈。

      运营商的话单和录音文件，大的话一天上TB，小的也有500G上下，存取方式也没有规律。后来建议客户改善存取方式，话单按天按系统类别存放、录音按业务系统通道划分。备份方面，当天备份昨天的话单和录音文件，因为优化了存取方式，所以备份前对各类文件tar打包。相比与直接备份小文件，利用主机的高性能来tar包形成大文件，大大降低了备份和恢复的时间，提升整体效率。备份完成了tar就可以删除，也不会额外占用空间。恢复时，只要定位了系统类别就可以快速找到需要的文件，恢复整个tar包的速度会非常快，解压的效率全压在主机上，相对于传统做法也改善不少。

      解决整个问题的思路，源于二叉树的快速存取模型。参考二叉树模型，把海量小文件细分，方便查询和业务复验要求。然后从最高深度将一定规模的二叉树父节点和子节点全部打包，这样就能形成一定数量大小的二叉树节点，这样在不改变业务系统整体架构的情况下，也改善了海量文件的备份容灾问题。

     有兴趣的话，可以参考一下，个人认为还是比较物美价廉的解决方案。

我们也有相同的问题，现在没有找到较好的备份方案。当前的做法是：

1.录音小文件：

分层架构，从本地磁盘（多份）---中端存储---归档存储---磁带，周期设置中有重复多份数据，保护任何一个节点数据丢失用户数据不丢失。

备份目前采用ndmp方案备份，计划向下边的方案方向发展。

2. 影像小文件：

影像文件一般不采用实时备份，这样对业务影响较大。同时由于影像文件保存的期限较长（30年），一般都采用近线存储和离线存储的方式进行备份。

我用了两套自建nas 每天凌晨做rsycn的增量备份。自建的nas服务器插满市场上最大容量的企业级sata磁盘＋256G SSD(做高速缓存)，仅仅用来做备份，没有做去重，因为去重的CPU占用太高，磁盘I/O太低，节约的磁盘空间非常有限.