前面转载了两篇海量小文件备份的文章，正好做了几年这方面的工作，总结一下经验教训。
文件备份是备份软件的基本功能，从rsync到大型备份软件，几乎所有的用户都需要相关功能。
看上去是比较简单的打开文件、读取数据、关闭文件，传输到目标端介质，创建文件、写入文件、关闭文件，但是文件数量如果上升到千万级别、上亿级别呢。如果这个还不算什么，那么文件大小下降到几十K大小呢，并且要求中时间窗口内完成备份。现实中确实遇到百万级别1K左右大小的文件。
海量文件的备份方案并不是某单一的方案，而是多种优化方案整合在一起的结果。
一、比较容易想到的就是多并发，采用多线程、多进程备份。这里的多并发分为两部分，多并发的扫描和多并发成传输。但是并不是并发越多越好，有可能会存在缓存命中的问题。
二、 减少读文件次数。海量非结构化数据一般存储在nas、cifs、hdfs、S3上面，小文件的网络io会有很大影响，尽量要做到一次读取所有信息缓存在本地使用。
三、 增加写入性能。对于小文件打包，将读取到的小文件合并成一个大文件传输、写入。
四、 备份文件元数据单独写入备份集。元数据信息包括文件的属性、权限、时间、md5、打包信息、备份集信息等，单独写入一份在备份集中虽然占有了部分空间，但是有很多好处。文件比对时减少介质端读io，归档、远程复制后可以直接使用， 恢复浏览检索可以直接处理元数据。
五、增量文件比对时目录级别处理。文件元数据比对是比较通用的方案，默认都会支持。比对的时候先比对目录的信息，发现目录变化则再比较子节点，会大量减少读取文件比对的次数。
海量小文件又如何快速恢复？转载文章并没有提及，这里说下我的处理方案：
一、备份集合成。每次备份的时候直接合成最新的全量备份，需要全量数据恢复时直接恢复合成后的备份集。合成的方法很多，比如直接使用备份集的元数据信息逻辑合成。 合成后的备份集也可以永久增量备份，节省全备的时间窗口。
二、细粒度恢复。只恢复需要恢复的文件，避免恢复整个备份集。要支持细粒度恢复就必须支持获取备份文件列表以及能快速检索备份文件的信息。如果单独保存了文件元数据，可以利用元数据快速处理。
三、挂载恢复。 可以使用网络文件系统等方式直接将备份集挂载出来使用，无需完全恢复整个备份集。如果是打包数据，也可以利用元数据进行处理。
有更好的方案欢迎大家交流。