# Why are backups so large?

**URL:** <https://meta.discourse.org/t/why-are-backups-so-large/31401>\
**Category:** Feature\
**Created:** [24 Luglio 2015, 5:54pm UTC](https://meta.discourse.org/t/why-are-backups-so-large/31401 "2015-07-24T17:54:30Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [24 Luglio 2015, 7:09pm UTC](https://meta.discourse.org/t/why-are-backups-so-large/31401/2 "2015-07-24T19:09:30Z")

</div>

pg\_dump supports compression:

`-Z, --compress=0-9`

You just need to balance between time spent VS file-size.

Maybe patch [this file](https://github.com/discourse/discourse/blob/9ce66038647bc4ff63167fe9c74857a01acc0875/lib/backup_restore/backuper.rb#L188) and add a small compression level (2~3) and measure the impact on your workload.

In my starting database (10 posts, 50 users) I see the following:

`-rw-r--r-- 1 postgres postgres 2,2M Jul 24 16:04 back_Z_2 -rw-r--r-- 1 postgres postgres 11M Jul 24 16:04 back_no_compression`

`  
Compression (Z=2)  
real 0m0.557s  
user 0m0.072s  
sys 0m0.032s

No Compression  
real 0m0.837s  
user 0m0.280s  
sys 0m0.036s  
`

But you need to use some real data to really commit to this. Using Meta would be a good example.

---

_[View the full topic](https://meta.discourse.org/t/why-are-backups-so-large/31401)._