在我们的生产环境中，我们有一个自定义的Windows服务，用于审计和诊断，在文件系统中生成日志文件。 日志文件非常详细（必要时），每天产生大约100 Mb的输出。 日志内容必须保留12个月，但高度可压缩。
我们正在考虑在这个文件夹上启用O / S压缩来节省空间 – 这在服务器上已经很重要了。
我们可能会遇到什么潜在的陷阱或问题？ 是否有任何性能，兼容性或稳定性问题需要考虑？ 如果有，我们如何确定这对我们来说是一个好主意？
我个人不会configuration任何“实时”日志logging到一个压缩或encryption的文件夹。 我将创build一个存档文件夹，并在应用程序完成写入后，将日志文件从应用程序的日志文件夹移动到这个压缩的存档文件夹。 我假设日志文件每天都“滚动”，所以今天的日志文件处于活动状态，并且正在被写入应用程序的日志文件夹，当应用程序启动新的日志文件时，以前的日志文件将被移动到压缩夹。
我亲自在我负责的一台Windows服务器上完成了这项工作。 我认为这是一个好主意。 正如你所提到的，日志文件中的重复纯文本压缩得非常好。 涉及压缩的开销似乎很小。 我用它作为防火墙日志，每天轻松抛出100MB +。 （虽然我把它分成了20MB的文件）除非你的CPU是固定的开始，我不认为这会是一个问题。 你将基本上交易一点CPU的能力，为大量的磁盘空间。 有时候，这是一个非常好的折衷。 其他时候，不是。
显然，testing是一个好主意。 但是我没有遇到太多麻烦。 只是build议压缩是不可转让的，就像一个老式的zip文件。 所以如果你通过FTP / CIFS / etc来移动它，那么你正在移动未压缩的数量。 如果您将它们复制到压缩文件夹之外，则将移动未压缩的数量。 如果您使用备份软件，则会备份未压缩的数量。 等等。
可能值得注意的是，当你实际翻转这个文件夹的标志时，有初始压缩。 所以你可能想一次压缩一个子集，所以当压缩你的日志一个小时的时候，你不要把你的服务器放在它的膝盖上。 这可能是重要的，取决于你有多less日志信息，以及你的应用程序有多重要。 但是，所有这一切，你总是可以逆转过程，并解压目录一样容易。 所以如果你觉得performance太糟糕了，那么你总是可以把它翻转回来。
正如其他人所说的那样，压缩长期存档的日志并不是一个坏主意。 如果您想在解决scheme中多付出一点努力，您可以随时在这些日志上自动执行压缩过程，并通过操作系统省去这些操作。
**没有“总是”在IT工作。 ;）*
– 克里斯托弗·卡雷尔
如果你已经没有繁重的CPU负载，你可能会受益于压缩你的日志文件。