# Add option to disable backup compression

**URL:** <https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288>\
**Category:** Feature\
**Created:** [30.Декабрь.2015 22:43:36 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:** 13

<div class="post-metadata">

**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\
**Post date:** [13.Январь.2016 00:46:03 UTC](https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288/13 "2016-01-13T00:46:03Z")

</div>

Whilst using (niced-to-oblivion) `pigz` will give you a shorter compression time, I think it’s somewhat orthogonal to the decision to enable `--rsyncable` (modulo compressed size differences), because any benefit you get from using `pigz` is equally applicable to both `--rsyncable` and normal compression. Trading off more CPU time for better compression is an interesting idea, since you’ll still (presumably) get wall clock benefits. Still, though, since it’s a background process, conserving wall clock time isn’t as big a deal as it would be otherwise. I wonder if using `gzip` for background jobs, but `pigz` for interactive backups, would be a worthwhile complication…

---

_[View the full topic](https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288)._