我们的生产环境中有一个自定义 Windows 服务，出于审计和诊断原因，它会在文件系统中生成日志文件。日志文件非常冗长（这是必然的），每天产生大约 100 Mb 的输出。日志内容必须保留 12 个月，但可高度压缩。
我们正在考虑对此文件夹启用 O/S 压缩以节省空间 - 这在该服务器上已经非常宝贵。
这样做会不会遇到任何潜在的陷阱或问题？是否有任何性能、兼容性或稳定性问题需要考虑？如果有，我们如何确定这对我们来说是否是个好主意？
答案1
我个人在我负责的一台 Windows 服务器上做过这个。我认为这是个好主意。正如你提到的，日志文件中重复的纯文本压缩效果非常好。压缩所涉及的开销似乎很小。我用它来处理防火墙日志，每天很容易转储 100MB 以上。（尽管我把它分成了 20MB 的文件）除非你的 CPU 从一开始就被限制了，否则我认为这不会是个问题。你基本上会用一点 CPU 能力来换取大量的磁盘空间。有时，这是一个非常好的权衡。其他时候，就不那么好了。
显然，测试是个好主意。但我没有遇到太多麻烦。只是请注意，压缩文件无法传输，就像老式的 zip 文件一样。因此，如果您通过 FTP/CIFS/等移动它，那么您移动的是未压缩的部分。如果您将它们复制到压缩文件夹之外，那么您移动的是未压缩的部分。如果您使用备份软件，那么您备份的是未压缩的部分。等等。
值得注意的是，当您实际翻转此文件夹的标志时，会进行初始压缩。因此，您可能希望一次压缩一个子集，这样您的服务器就不会在压缩日志一小时时陷入瘫痪。这可能很重要，具体取决于您拥有的日志信息量以及应用程序的重要性。但话虽如此，您始终可以逆转该过程，并同样轻松地解压缩目录。因此，如果您发现性能太差，那么您可以随时*将其翻转回来。
正如其他人提到的，只压缩长期存档的日志并不是一个坏主意。如果您想在解决方案上多花点功夫，您可以随时自动对这些日志进行压缩，而无需通过操作系统进行压缩。
**在 IT 领域，没有什么是“永远”有效的。;)*
--Christopher Karel
答案2
就我个人而言，我不会将任何“实时”日志配置为记录到压缩或加密文件夹中。我会创建一个存档文件夹，并在应用程序完成写入后将日志文件从应用程序的日志文件夹移动到此压缩存档文件夹。我假设日志文件每天都会“滚动”，因此今天的日志文件处于活动状态并以未压缩的形式写入应用程序的日志文件夹，而当应用程序启动新的日志文件时，上一个日志文件将移动到压缩文件夹。
答案3
当这里推荐压缩时，我没有看到来自 MS 的任何警告：https://docs.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/managing-iis-log-file-storage
答案4
如果您的 CPU 负载还不算太重，那么压缩日志文件可能会对您有所帮助。