# Add option to disable backup compression **URL:** \ **Category:** Feature\ **Created:** [December 30, 2015, 10:43pm UTC](https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288 "2015-12-30T22:43:36Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![Koinu](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/koinu/32/120781_2.png) [@Koinu](https://meta.discourse.org/u/Koinu)\ **Post date:** [January 12, 2016, 7:48am UTC](https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288/12 "2016-01-12T07:48:03Z")
The concern about time just reminded me that [pigz](http://zlib.net/pigz/) exists. It even has `--rsyncable`! (pigz produces output that’s compatible with gzip, using multiple cores to do the compression and resulting in much shorter wall clock time vs ordinary gzip.) It’d probably be a good idea to run it niced into oblivion, since its many threads could have a much bigger impact on a running instance’s peformance than gzip’s one thread. Might be worth checking out, especially for that large instance. 🙂 Edit: I did some quick tests on my not-so-huge backup. At the default compression level, `pigz --rsyncable` output is very slightly bigger than `gzip --rsyncable` output. It deduplicates just as well. The size cost of `pigz --rsyncable` is a ~0.736% gain versus plain `gzip` for my data. (For comparison, `gzip --rsyncable` is a ~0.281% gain.) The wall clock time improvement is impressively linear. With 4 real cores on my laptop, `pigz --rsyncable` takes ~0.568 seconds (wall clock time), compared to ~2.222 seconds for plain `gzip`. There may be a sweet spot where you can “have your cake and eat it too” with shorter wall clock time and smaller but dedup-friendly output, by combining a switch to pigz (+ `--rsyncable`) with a bump in the compression level. --- _[View the full topic](https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288)._