I have never tested it, but from my feeling I would not recommend it under any circumstances...

LMS does have a lot of I/O for all its jobs and typically the user experience with performance of the Web GUI is also not the best. So why do you want to burden the CPU to do this extra step of uncompression and compression of nearly any task of LMS ? Not only the user tasks are affected by this step it is also the system tasks which suffer.

If you want to do it because you have disk space problems, think about some steps to reduce it:

- add a new HDD and move the db backups there

- point the log backups to this new HDD

- purge job histories and job backups,

- do the job purge periodically (can be configured)

- if enabled, disable syslog backup for purged syslog messages (not the raw syslog.log file) 

- if databases are very big, think about what can be the reason and try to adopt to it (especiall the job thing)

- for the syslog-xxxx.db,  you could us the DBSpaceReclaimer.pl described in the online doc (I assume ;-) ) and also here:

     LMS 4.1 (not just) for Dummies

So my short answer would be:

    just don't do it :-)