バックアッププロセスでは、まずtarファイルを作成し、次にgzipを適用します。tarファイルには、すでにgzip圧縮されたSQLダンプと、アップロードの内容（要求された場合）の2種類のものが含まれます。私の場合は、すべてのアップロードファイルはすでに圧縮されています（gz、gzip、gif、jpeg、png、zip）。そのため、最終的なgzip圧縮によるサイズ削減はわずか1%です。
より少ない空き容量で済むようにすべきだと考えます。
2016年の以前のトピックでは、バックアップ圧縮の無効化について言及されていますが、当時のSQLダンプは圧縮されていなかったようで、トレードオフが変わっています。
二重圧縮を削除する新しいバックアップ形式をすでに開発中です。1、2か月以内に完成する見込みです。
素晴らしいですね、@gerhard さん！
これについてのアップデートはありますか？よろしくお願いします。
あまりしつこくお聞きしたくありませんが、これはどの程度進んでいますか？
その機能の開発は現在一時停止されており、現在のロードマップには含まれていません。2024年中に着手できることを願っています。
gzipを無効にするために圧縮率に0を受け入れるパッチを書いた場合、受け入れられますか？
（そのようにCPU時間を節約できると思いますが、gzip圧縮されたtarファイルは作成されるため、スペースは節約できません。）
CPU時間を節約したいのです。実際、0をフラグとして使用してコードパスを変更し、gzipを使用しないようにすることを考えていました（残念ながら、ゼロは私が知る限り、すべてのgzipバージョンでサポートされている有効な圧縮レベルではありません）。
それは全く役に立ちませんでした！ (ディスク容量が限られているという同じ問題を抱えていた他の人も同様です。)
tar が使用されていた場合、z または j オプションと共に使用できます。サブシェルが使用されていた場合、tar の出力を gzip にパイプできます。しかし、実際には、より高レベルの Ruby 関数が使用されている可能性があると思います。
咳
バックアップと復元の変更は慎重に行う必要があることは理解していますが、圧縮をインライン化するだけで、互換性の問題なく、多くのスペース要件を節約できると思います。
tar --help より
-a, --auto-compress アーカイブの接尾辞を使用して圧縮を決定します
-z, --gzip, --gunzip, --ungzip アーカイブをgzipでフィルタリングします
-z は実際にインプレース圧縮を行いますか？tar ファイルが完了した後に gzip を実行するだけだといつも思っていました。
この場合は賢明ではありませんでした！非圧縮tarファイルを表すバイトはディスクにヒットしません。
「\"--gzip\",」を追加するだけで、データが実際に使用するスペースの2倍を必要としなくなるということですか？
【quote=“MentalNomad, post:15, topic:245763”】
あなたは言っているのですか
[/quote]
はい、それがtarコマンドへの変更です。
より良い選択肢は --zstd のようですが、その場合は Docker イメージ内に ‘zstd’ パッケージもインストールする必要があります。
既存のバックアップ（*.gz または *.zst）を処理できるようにし、処理を簡素化するより良いアプローチとしては、tar の自動検出機能を使用することが考えられます。
tar --auto-compress -c -f ../file.tar.gz .
tar --auto-compress -c -f ../file.tar.zst .
もちろん、より重要なのは展開側です。ここでは、どのようなファイルが現れるか事前にわからない可能性があります。
現在、Ruby のコードは tar 自体が処理できることを多数行っているようです。複雑化するのではなく、これを簡素化できることを願っています。
zstd ははるかに高速です。そのため、圧縮がほとんど効かないデータを圧縮するのにかける時間が問題になりにくくなります。
（もし SQL ダンプにも zstd が使われていれば、私の場合、サイズが 10% ほど小さくなります。）