考虑性能的前提是满足业务的诉求，可以根据业务的实际情况来评估存储的性能要求。海量小文件是一个典型的IO密集型模型，可以考虑从文件的数量，大小等方面进行评估。

海量小文件存储（简称LOSF，lots of small files）出现后，就一直是业界的难题，许多互联网公司也针对自己的具体场景研发了自己的存储方案（如taobao开源的TFS，facebook自主研发的Haystack），还有一些公司在现有开源项目(如hbase，fastdfs，mfs等)基础上做针对性改造优化以满足业务存储需求；...

海量小文件的问题，现在一直没有根本性解决，能够完美解决海量文件备份效率的方案，成本都不低，入不敷出……Windows下的那就更麻烦了，Windows下有两类问题是最头痛的，一个是海量文件问题，另一个就是巨型MSSQL的问题，经历了很多项目都没有找到很彻底的解决方案，只能逐步去优化，改善备...

我们选择的解决方案是NetAPP的NAS存储，提供非结构化数据的集中管理，去重，提供高并发能力。当然检索的技术，各个厂商不同，但是他们的类型是非结构化的，所以可以集中考虑非结构化存储。...

NBU通过Accelerator技术对大量小文件的高效备份，提供备份加速技术，提高数据备份的效率。Accelerator技术使用了集中技术手段1.永久的增量,合成备份.2.记录哪些数据发生了变化,下次备份的时候不用全部数据扫描,只备份变化或增加的数据3.前端数据重删技术....

这是个大多数客户都比较头疼的问题。tsm下有以下几种参考方式：先打包再备份，这个其实不算tsm的特性，而是一种通用的解决方案。需要和业务部门合作，对小文件的产生进行分析，看看是按业务类型还是按时间，在固定的时间对小文件进行打包，打包完成再备份走。打包可以通过脚本来实现，也...

推荐采用分布式对象存储俩存储海量小文件。对象存储的出现就是为了解决海量文件的存储问题，其存储结构key-value 方式的扁平价格，metadata 可以做的非常大，存储海量小文件比NAS存储更合适。...

摘一段我以前的回复，供参考关于大量碎片文件的备份，目前行业内没有特别直接有效的方法，即使是成本较高的存储级别复制，也难以达到长期保留的目的。此前借交流会和国外的容灾和业务专家谈及这一点的时候，他们也表示在国外过去的十几年里也存在这种问题，但现在已经想办法规避了，规...

这里引用下另一个相似的问题：针对这种情况，可以采用snapshot Backup和BBB Backup，不过snapshot Backup和BBB Backup需要存储产品开放接口给备份软件，也就是备份软件支持不支持某产品的问题。BBB Backup是近些年才推出的备份解决方案，BBB Backup对存储和备份介质以及备份软件都...

我们现在也面临这样的问题。数百万个小文件。备份的时候效率非常低，全盘备份应该是可以加快备份和恢复的过程。只是应该没办法做到细颗粒度的备份和恢复，之前我发的帖子里有人回复关于这种文件的管理，你也可以参考一下。...