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.
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.
Ich arbeite bereits an einem neuen Sicherungsformat, das die doppelte Komprimierung entfernt. Ich hoffe, dass es in ein oder zwei Monaten fertig sein wird.
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?
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).
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.
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