Should you use NTFS compression on Exchange Server files?

Serdar Yegulalp
01.10.2007

The sheer size of many Exchange Server files -- the database, mainly, but
also the log files -- can eat up a lot of disk space. Any hard drive that's
over 75% to 80% capacity is going to be hard to defragment (especially if
it's already badly fragmented), and will experience other performance
degradations on top of that.
To alleviate the problem, some Exchange Server administrators have debated
using NTFS's native file-compression system on some Exchange Server files to
save hard drive space -- but this is generally not a good idea..
When people think of NTFS file compression (which allows files to be
compressed and decompressed on the fly), they think of technologies like
Stacker or Disk Doubler -- which were not terribly stable and caused at
least as many problems as they solved.
Back when disk space was at a premium, these NTFS compression solutions were
at least provisionally attractive. But now that disk space is so much
cheaper, it makes more sense to simply buy the storage you need instead of
wrestling with a software solution.
Granted, NTFS file compression is a lot more dependable now than the
technologies that were available back in the days of DOS and 16-bit/32-bit
Windows. Even so, I would still be reluctant to use it to compress live data
on any production machine, especially data used by Exchange Server.
The main reason for not using NTFS file compression on Exchange Server is
performance. There's a certain amount of overhead involved in compressing
and decompressing data. If you multiply that overhead by the number of
concurrent I/O requests made to such data, you have a recipe for an Exchange
server that's going to take a performance hit -- no matter how many cores
you have in it. The Exchange Server databases themselves (and the binaries)
should never be compressed.
The only Exchange Server files that I would feel comfortable setting as
NTFS-compressed would be Exchange Server log files -- not the transaction
logs -- but logs generated by SMTP logging.
SMTP log files do compress very well -- 75% or better, since they're
essentially plaintext. But if they're not really needed, they can simply be
archived using a third-party archiving tool that yields better compression
than NTFS on-disk compression; or you could just delete them entirely.