# Reduzieren Sie den Platzbedarf auf der lokalen Festplatte, indem Sie Backups nicht (redundant) gzippieren

**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 um 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:** 20
**Page:** 1

<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: [16. November 2022 um 12:38 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/1 "2022-11-16T12:38:03Z")

</div>

Der Backup-Prozess erstellt eine Tar-Datei und wendet dann gzip darauf an. Es gibt zwei Arten von Dingen in der Tar-Datei: einen bereits mit gzip komprimierten SQL-Dump und den Inhalt von Uploads (falls angefordert). In meinem Fall ist jede Upload-Datei bereits komprimiert: gz, gzip, gif, jpeg, png, zip. Das abschließende Gzipping spart also nur 1 % an Größe.

> [@pfaffman](#):
>
> Um ein Backup zu erstellen, benötigen Sie fast die doppelte Größe Ihrer Datenbank + Uploads, um das Backup erstellen zu können…

Ich glaube, es wäre besser, weniger freien Speicherplatz zu verlangen.

Ein früheres Thema aus dem Jahr 2016 erwähnt das Deaktivieren der Backup-Komprimierung, aber es sieht so aus, als ob der SQL-Dump zu dieser Zeit nicht komprimiert war, was die Kompromisse verschoben hat.

[Option zum Deaktivieren der Backup-Komprimierung hinzufügen](https://meta.discourse.org/t/add-option-to-disable-backup-compression/37288)

---

<div class="post-metadata">

### Author: ![gerhard](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/gerhard/32/119479_2.png) [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [17. November 2022 um 14:50 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/2 "2022-11-17T14:50:45Z")

</div>

Ich arbeite bereits an einem neuen Sicherungsformat, das die doppelte Komprimierung entfernt. Ich hoffe, dass es in ein oder zwei Monaten fertig sein wird.

---

<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: [17. November 2022 um 15:45 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/3 "2022-11-17T15:45:41Z")

</div>

Klingt super @gerhard!

---

<div class="post-metadata">

### Author: ![tumbano](https://avatars.discourse-cdn.com/v4/letter/t/7ea924/32.png) [@tumbano](https://meta.discourse.org/u/tumbano)
#### Post date: [20. April 2023 um 07:52 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/4 "2023-04-20T07:52:51Z")

</div>

Gibt es Neuigkeiten dazu? Danke

---

<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: [4. Oktober 2023 um 09:11 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/5 "2023-10-04T09:11:10Z")

</div>

> [@gerhard](#):
>
> Arbeite an einem neuen Sicherungsformat, das die doppelte Komprimierung entfernt

Ich will dich nicht zu sehr stören, aber wie schreitet das voran?

---

<div class="post-metadata">

### Author: ![gerhard](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/gerhard/32/119479_2.png) [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [4. Oktober 2023 um 09:22 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/6 "2023-10-04T09:22:21Z")

</div>

Die Entwicklung dieser Funktion ist derzeit pausiert und sie steht nicht auf unserer aktuellen Roadmap. Ich hoffe, wir werden uns 2024 damit befassen.

---

<div class="post-metadata">

### Author: ![Isambard](https://avatars.discourse-cdn.com/v4/letter/i/858c86/32.png) [@Isambard](https://meta.discourse.org/u/Isambard)
#### Post date: [30. August 2024 um 18:44 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/7 "2024-08-30T18:44:57Z")

</div>

Wenn ich einen Patch schreiben würde, um eine 0 für die Kompressionsrate zu akzeptieren, um gzip zu deaktivieren, wäre das etwas, das Sie akzeptieren würden?

---

<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: [30. August 2024 um 19:00 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/8 "2024-08-30T19:00:39Z")

</div>

(Ich vermute, dass Sie auf diese Weise CPU-Zeit sparen würden, aber keinen Speicherplatz, da die komprimierte Tar-Datei trotzdem erstellt würde.)

---

<div class="post-metadata">

### Author: ![Isambard](https://avatars.discourse-cdn.com/v4/letter/i/858c86/32.png) [@Isambard](https://meta.discourse.org/u/Isambard)
#### Post date: [30. August 2024 um 19:08 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/9 "2024-08-30T19:08:53Z")

</div>

Ich möchte CPU-Zeit sparen. Tatsächlich dachte ich daran, die 0 als Flag zu verwenden, das den Code-Pfad ändert, sodass nicht gegzip-t wird (traurigerweise ist Null kein gültiger Kompressionslevel, der afaik bei allen Gzip-Versionen unterstützt wird).

---

<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: [30. August 2024 um 20:02 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/10 "2024-08-30T20:02:15Z")

</div>

Das würde mir überhaupt nicht helfen! (Ebenso wie andere, die dasselbe Problem mit begrenztem Speicherplatz hatten.)

Wenn tar verwendet würde, könnte es mit den Optionen z oder j verwendet werden. Wenn eine Subshell verwendet würde, könnte die Ausgabe von tar in gzip geleitet werden. Aber ich denke, tatsächlich werden möglicherweise einige Ruby-Funktionen auf höherer Ebene verwendet.

---

<div class="post-metadata">

### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [30. August 2024 um 22:06 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/11 "2024-08-30T22:06:33Z")

</div>

> [@Ed\_S](#):
>
> Wenn eine Subshell verwendet würde, könnte die Ausgabe von tar in gzip geleitet werden. Aber ich glaube, dass tatsächlich einige Ruby-Funktionen auf höherer Ebene verwendet werden könnten.

_hust_

> <https://github.com/discourse/discourse/blob/7b89fdead98606d4f47ceb0a1d240d0f6e5f589e/lib/compression/tar.rb#L13-L21>

---

<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: [31. August 2024 um 07:27 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/12 "2024-08-31T07:27:44Z")

</div>

Vielleicht sollte es nicht allzu schwierig sein… Ich verstehe, dass Änderungen an Backup und Restore mit großer Sorgfalt vorgenommen werden müssen, aber ich denke, das direkte Einbinden der Komprimierung würde den Speicherbedarf erheblich reduzieren, ohne Kompatibilitätsfragen aufzuwerfen.

Von `tar --help`

> -a, --auto-compress use archive suffix to determine the compression  
> -z, --gzip, --gunzip, --ungzip filter the archive through gzip

---

<div class="post-metadata">

### Author: ![Isambard](https://avatars.discourse-cdn.com/v4/letter/i/858c86/32.png) [@Isambard](https://meta.discourse.org/u/Isambard)
#### Post date: [1. September 2024 um 22:49 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/13 "2024-09-01T22:49:23Z")

</div>

Komprimiert -z tatsächlich direkt? Ich ging immer davon aus, dass es nur gzip ausführt, nachdem die Tar-Datei fertiggestellt ist.

---

<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: [2. September 2024 um 08:34 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/14 "2024-09-02T08:34:24Z")

</div>

> [@Isambard](#):
>
> Ich ging immer davon aus…

In diesem Fall unklug! Die Bytes, die die unkomprimierte Tar-Datei darstellen, landen nie auf der Festplatte.

---

<div class="post-metadata">

### Author: ![MentalNomad](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mentalnomad/32/95159_2.png) [@MentalNomad](https://meta.discourse.org/u/MentalNomad)
#### Post date: [6. Mai 2025 um 14:35 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/15 "2025-05-06T14:35:07Z")

</div>

> [@Ed\_S](#):
>
> –gzip

Sagen Sie damit, dass wir einfach hinzufügen können  
`"--gzip",`

Und es wird aufhören, doppelt so viel Speicherplatz wie die tatsächlich genutzten Daten zu benötigen?

---

<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: [6. Mai 2025 um 15:38 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/16 "2025-05-06T15:38:33Z")

</div>

> [@MentalNomad](#):
>
> Meinst du

Ja, das ist die Änderung am tar-Befehl.

---

<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 um 16:58 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/17 "2026-04-23T16:58:51Z")

</div>

> [@MentalNomad](#):
>
> Meinst du, wir können einfach  
> `"--gzip",`  
> hinzufügen?

Es sieht so aus, als wäre `--zstd` eine noch bessere Wahl, aber dann müssten wir auch das Paket ‘zstd’ im Docker-Image installiert haben.

---

<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 um 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>

Vielleicht ist ein besserer Ansatz, der die Dinge vereinfachen könnte – die Fähigkeit, mit bestehenden Backups umzugehen, die \*.gz oder \*.zst sein könnten – die automatische Erkennung von tar zu nutzen:

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

```

Noch wichtiger ist natürlich das Entpacken, wo wir möglicherweise nicht wissen, was uns erwartet.

Derzeit macht der Ruby-Code viele Dinge, die tar selbst erledigen kann. Hoffentlich lässt sich dies vereinfachen, anstatt komplexer zu werden.

---

<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: [24. April 2026 um 18:34 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/19 "2026-04-24T18:34:02Z")

</div>

`zstd` ist auch deutlich schneller – was es weniger problematisch macht, dass wir Zeit damit verbringen, fast nicht komprimierbare Daten zu komprimieren.

(Wenn zstd auch für den SQL-Dump verwendet würde, wäre er in meinem Fall um 10 % kleiner.)

---

<div class="post-metadata">

### Author: ![CT075](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ct075/32/375367_2.png) [@CT075](https://meta.discourse.org/u/CT075)
#### Post date: [7. Juli 2026 um 17:29 UTC](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/20 "2026-07-07T17:29:26Z")

</div>

Hi, gibt es dazu Neuigkeiten? Aus [dieser Antwort](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763/15?u=ct075) scheint hervorzugehen, dass wir seit über einem Jahr wissen, dass dies mit einer einzigen Codezeile behoben werden kann. Es ist also ziemlich frustrierend, morgens weiterhin „Backup fehlgeschlagen“-DMs zu erhalten, obwohl auf dem Server noch fast 30 GB frei sind.

Ich würde den PR selbst einreichen, wenn das Unterzeichnen der CLA nicht die Angabe einer physischen postalischen Adresse erfordern würde.

[Next page](https://meta.discourse.org/t/reduce-local-disk-space-needs-by-not-redundantly-gzipping-backups/245763.md?page=2)
