# Lokale schijfruimtebehoeften verminderen door back-ups niet (redundant) te gzippen

**URL:** https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763
**Category:** Feature
**Tags:** backups
**Created:** [16 november 2022 om 12:38 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763 "2022-11-16T12:38:03Z")
**Posts on this page:** 1
**Showing post:** 18

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [23 april 2026 om 20:58 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/18 "2026-04-23T20:58:46Z")

</div>

Possibly a better approach which might simplify things - being able to deal with existing backups which might be \*.gz or \*.zst - is to use tar’s automatic detection:

```plaintext
tar --auto-compress -c -f ../file.tar.gz .
tar --auto-compress -c -f ../file.tar.zst .

```

More important for the unpacking, of course, where we might not know what we’re going to see.

Presently the ruby code seems to do lots of things which tar itself can do. Hopefully this can be simplified, rather than becoming more complex.

---

_[View the full topic](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763)._