海量小文件备份

看到一篇公众号文章：海量小文件备份为何这么难？如何应对？

部署基本没有遇到过整合后的文件，倒是各种奇怪的场景，比如单目录下上百万文件，十几层目录下面放个文件等。

poc测试也是基本要测试海量小文件的性能。

并且有点数据量的非结构化数据一般都存储在NAS、CIFS、hdfs、S3 上，从存储测进行磁盘级的块备份不现实，基本上是存储厂商的业务，轮不到备份厂商来做。

之前的日常工作中一般是采用方案1 和方案3 的结合，也要根据不同情况来区分具体方案。

比如在某项目遇到一个特殊的S3，文件元数据是在缓存处理，多进程读取的时候会导致缓存没有命中，不停的加载数据到缓存，这个过程又相当慢，直接导致S3消息超时。

如果只是备份而非同步数据，打包成大数据传输写入能显著提高性能。

全量备份还好，如何快速在海量文件中找到变化的文件进行增量备份才是最头疼问题。

公众号随后也提出了一些解决方案：海量小文件备份为何这么难（二）？如何应对增量？

实际处理也是多方案结合，时间对比是最基本的解决方案，用户需要可靠的备份数据时会加上md5等校验，文中所提到的时间比对缺陷都很容易解决。

比如没必要直接比对备份系统的文件信息，这样会影响性能，可以采用类似方案一的元数据tree 来处理。

存储的snap能力和用户提供变化文件列表都是能快速获取变化文件好方案，但是需要对接相关的存储和应用。