バックアップの冗長なgzip化を避けてローカルディスク容量を節約する

バックアッププロセスでは、まずtarファイルを作成し、次にgzipを適用します。tarファイルには、すでにgzip圧縮されたSQLダンプと、アップロードの内容(要求された場合)の2種類のものが含まれます。私の場合は、すべてのアップロードファイルはすでに圧縮されています(gz、gzip、gif、jpeg、png、zip)。そのため、最終的なgzip圧縮によるサイズ削減はわずか1%です。

より少ない空き容量で済むようにすべきだと考えます。

2016年の以前のトピックでは、バックアップ圧縮の無効化について言及されていますが、当時のSQLダンプは圧縮されていなかったようで、トレードオフが変わっています。

バックアップ圧縮を無効にするオプションを追加

「いいね!」 10

二重圧縮を削除する新しいバックアップ形式をすでに開発中です。1、2か月以内に完成する見込みです。

「いいね!」 13

素晴らしいですね、@gerhard さん!

「いいね!」 2

これについてのアップデートはありますか?よろしくお願いします。

「いいね!」 1

あまりしつこくお聞きしたくありませんが、これはどの程度進んでいますか?

その機能の開発は現在一時停止されており、現在のロードマップには含まれていません。2024年中に着手できることを願っています。

「いいね!」 4

gzipを無効にするために圧縮率に0を受け入れるパッチを書いた場合、受け入れられますか?

「いいね!」 1

(そのようにCPU時間を節約できると思いますが、gzip圧縮されたtarファイルは作成されるため、スペースは節約できません。)

CPU時間を節約したいのです。実際、0をフラグとして使用してコードパスを変更し、gzipを使用しないようにすることを考えていました(残念ながら、ゼロは私が知る限り、すべてのgzipバージョンでサポートされている有効な圧縮レベルではありません)。

それは全く役に立ちませんでした! (ディスク容量が限られているという同じ問題を抱えていた他の人も同様です。)

tar が使用されていた場合、z または j オプションと共に使用できます。サブシェルが使用されていた場合、tar の出力を gzip にパイプできます。しかし、実際には、より高レベルの Ruby 関数が使用されている可能性があると思います。

「いいね!」 1

「いいね!」 2

バックアップと復元の変更は慎重に行う必要があることは理解していますが、圧縮をインライン化するだけで、互換性の問題なく、多くのスペース要件を節約できると思います。

tar --help より

-a, --auto-compress アーカイブの接尾辞を使用して圧縮を決定します
-z, --gzip, --gunzip, --ungzip アーカイブをgzipでフィルタリングします

「いいね!」 1

-z は実際にインプレース圧縮を行いますか?tar ファイルが完了した後に gzip を実行するだけだといつも思っていました。

この場合は賢明ではありませんでした!非圧縮tarファイルを表すバイトはディスクにヒットしません。

「いいね!」 2

\"--gzip\",」を追加するだけで、データが実際に使用するスペースの2倍を必要としなくなるということですか?

「いいね!」 1

【quote=“MentalNomad, post:15, topic:245763”】
あなたは言っているのですか
[/quote]

はい、それがtarコマンドへの変更です。

「いいね!」 1