我们有一个系统，每天生成5k – 10k的XML文件。 这是一个很长的故事，但这个系统不会改变一段时间。
无论如何，系统将这些XML文件（每个3k-20k）转储到一个文件夹中。 所以想象一下这个文件夹开始变得有多快。
我写了一个程序，把文件和组织成年/月/日格式的层次结构。 然后另一个程序进入并删除任何超过90天的文件。
这是问题。 我们的备份系统（又是一些无法更改的function）需要HOURS来备份这些存档的文件夹，因为有近100万个文件。 备份做了完整的备份（再次，我们不能改变），发生的事情是备份必须打开并检查每个XML文件。 所以备份速度非常慢，以至于在第二天晚上的备份之前，备份速度并没有完成！
所以我一直在做每月文件夹和创build一个7z档案。 这很好。 200k文件下载到一个文件。 但是，我必须手动执行此操作。
另外还有一个问题。 我们无法存档当前月份。 所以总是需要30天（x 5k – 10k）的文件即时“search”。
有关如何更好地处理此问题的任何build议？
以下是我的头：
1）编写一个前一天的程序并转储到SQL。 然后将该文件添加到档案。
2）XML可以移动到的某种types的“活动归档”文件系统。
谢谢。
如果它们是XML，在压缩它们之前是否可以将它们连接起来？ 然后，他们应该压缩得更好（更好的共享符号字典）如果将每个月末的date文件连接成一个大月XML文件，或者甚至进一步连接数年，甚至连续数年所有的历史，除了-这-为期一个月。 在所有情况下，你压缩他们，是的。
这听起来不像是你做得太糟糕了，真的，除了需要编写一些脚本来自动为你做事之外。
你有没有logrotate？ 这主要是用于日志归档，但它可以为你的情况。
关于你的情况，你有什么数据库？ 它可以支持你提到的明文的数量吗？
另外为什么你必须手动执行7zip压缩文件？ 你为什么不使用cron来为你做？
你没有提到你的平台，如果它是linux，为什么不编写一个sorting位（你已经做好了），将它们分成更小的目录，然后运行7z命令行压缩文件，将这些目录压缩到一个文件，然后回到那些？
或者，您可以创build一个“备份服务器”，通过IP镜像转储的目录（类似drdb或rsync），然后您可以从该服务器上执行备份，并且可以释放您负担过重的服务器上的一些资源。
实际上，除了想方设法减less你创build的文件数量之外，你的select还是有限的。 每一个你说出名字的砖墙上都贴上了标签，说明什么都不能做或者改变。
如果您的月份数据必须立即可search，那么您可能需要查看数据库解决scheme或将其与数据库集成的方法。 从它的声音，你已经使用文件系统作为临时数据库，实际上把信息放入数据库应该提高你的性能（和备份能力）。
我知道你提到你不能改变你的备份系统，但是由于你遇到了麻烦，可能还是值得重新开始。
还有可用的rsnapshot。 这使用rsync将只备份更改的文件。 在你的情况下，如果你每天运行它，它只会备份5K到10K的文件，你也可以把它限制到最新的月份。
如果您需要可search的内容，我同意Bart Silverstrim将内容放入数据库，因为备份和数据库应被视为两个独立的系统。
你可以尝试使用不同的文件系统（xfs）并调整它的参数。
例如： http : //everything2.com/title/Filesystem+performance+tweaking+with+XFS+on+Linux
您也可以添加一些磁盘驱动器和/或configuration更快的RAID级别来提高性能，因为它看起来像是IOPS的瓶颈。