バックアップデータの圧縮と最適化方法（gzip・zstd・xzの使い分けと容量の減らし方）

バックアップの容量と所要時間を減らすには、圧縮方式を選ぶことよりも先に、「圧縮が効くデータか」「そもそも取る必要があるデータか」を見極めるのが近道です。そのうえで、データベースのダンプのような文字のデータには圧縮を効かせ、画像のような圧縮済みのデータには余計なCPUを使わないようにします。この記事では、gzip・zstd・xz などの特徴と選び方、tar やダンプとの組み合わせ方、除外すべきファイル、重複排除型のツールへの切り替え、圧縮後の検証までを説明します。

圧縮が効くデータと効かないデータ

WordPressのバックアップは、性質の違うデータの集まりです。

• データベースのダンプ（SQL）：文字のデータで、同じ構文や繰り返しが多いため、よく縮みます。数分の1になることも珍しくありません。
• テーマ・プラグインのファイル：PHP・CSS・JavaScriptなど文字のファイルが中心で、よく縮みます。
• アップロードされた画像・動画・PDF：JPEG、PNG、WebP、MP4 などは、ファイル形式の時点で圧縮されています。さらに圧縮してもほとんど小さくならず、CPUの時間だけを使います。
• ZIPなどのアーカイブ：同様に、ほぼ縮みません。

多くのサイトで容量の大半を占めるのは wp-content/uploads です。この部分の圧縮率を上げようとレベルを最大にしても、時間がかかるだけで結果はほとんど変わりません。まず du で、どこが容量を占めているかを確認してください。

du -sh /var/www/html/wp-content/* | sort -h

圧縮方式の特徴と選び方

Linuxでよく使われる圧縮方式の傾向は次のとおりです。実際の速さと縮み方はデータとCPUによって変わるので、手元のデータで試して決めてください。

gzip は古くから使われていて、展開できない環境がほとんどないのが利点です。ただし1つのCPUコアしか使いません。pigz は gzip と互換の形式で、複数のコアを使って圧縮します。

zstd は、速さと圧縮率のバランスがよく、レベル（1〜19、--ultra でさらに上）で調整できます。低いレベルなら gzip より速く同等以上に縮み、高いレベルにすると xz に近い圧縮率になる、というのがよく見られる傾向です。-T0 で利用できるコアを使って並列に圧縮します。日常のバックアップで迷ったら zstd を選ぶとよいでしょう。

xz は圧縮率が高い代わりに、圧縮に時間がかかり、メモリも多く使います。毎日のバックアップよりも、月次の長期保管などに向いています。

各ツールのバージョンによって使えるオプションが違うことがあるため、zstd --version などで手元の環境を確認してください（2026年10月現在）。

tar と組み合わせる

ファイルをまとめる tar に、圧縮プログラムを指定して使います。GNU tar では -I（--use-compress-program）で圧縮プログラムとオプションを指定できます。

# zstd（全コア使用・レベル10）
tar -I 'zstd -T0 -10' -cf files-20261018.tar.zst \
  -C /var/www/html wp-content wp-config.php

# pigz（gzip 形式を並列で）
tar -I pigz -cf files-20261018.tar.gz -C /var/www/html wp-content wp-config.php

# 展開（zstd の場合）
tar -I zstd -xf files-20261018.tar.zst -C /tmp/restore-test

新しめの GNU tar なら --zstd という指定もありますが、古い環境では使えないことがあるため、-I のほうが互換性の面で無難です。

データベースのダンプを圧縮する

ダンプはファイルに書き出してから圧縮するのではなく、パイプでそのまま圧縮すると、一時的なディスクの使用量を抑えられます。

set -o pipefail
mysqldump --defaults-extra-file=/root/.wp-backup.cnf \
  --single-transaction --quick wordpress \
  | zstd -T0 -6 -o db-20261018.sql.zst

pipefail を付けておかないと、mysqldump が失敗しても zstd が成功すれば全体が成功扱いになり、中身の欠けたファイルが残ります。

なお、mysqldump の --compress は、データベースサーバーとの通信を圧縮するためのオプションで、出力ファイルは圧縮されません。名前から誤解しやすい点です。

取る必要のないファイルを除外する

圧縮より効果が大きいのが、不要なファイルを最初から含めないことです。WordPressでよく除外されるのは次のようなディレクトリです。

• キャッシュ用プラグインが作るキャッシュ（wp-content/cache など）
• バックアップ用プラグインの保存先（例：UpdraftPlus の wp-content/updraft、All-in-One WP Migration の wp-content/ai1wm-backups）。含めると、バックアップの中にバックアップが入り、回を追うごとに膨らみます
• 更新作業の一時ディレクトリ（wp-content/upgrade）
• ログファイル（debug.log など。調査に必要なら別に保管）

tar -I 'zstd -T0 -10' -cf files-20261018.tar.zst \
  --exclude='wp-content/cache' \
  --exclude='wp-content/updraft' \
  --exclude='wp-content/ai1wm-backups' \
  --exclude='wp-content/upgrade' \
  -C /var/www/html wp-content wp-config.php

ディレクトリ名はプラグインやその設定によって違うため、du の結果と照らし合わせて実際の名前を確認してください。除外しすぎると、戻したときに必要なファイルが欠けます。プラグインの独自テーブルに設定を持つものもあるので、データベースは丸ごと取るのが基本です。

毎回の全体圧縮をやめる

画像が多いサイトでは、毎日 tar で全体を固めて圧縮する方式そのものが、容量と時間のむだになります。前回から変わっていない画像を毎回読み込み、毎回保存しているからです。

restic や BorgBackup のような重複排除型のツールは、データを小さな単位に分けて、すでに保存済みの部分は保存し直しません。2回目以降は変更分だけが増えるので、毎日取っても容量はゆるやかにしか増えません。どちらも圧縮に対応しています。

# restic：圧縮の指定（リポジトリ形式のバージョン2以降で有効）
restic backup --compression auto /var/www/html

# BorgBackup：zstd のレベル3で圧縮
borg create --compression zstd,3 /path/to/repo::web-{now} /var/www/html

restic の圧縮は 0.14 以降で、新しい形式のリポジトリに対して使えます。古い形式で作ったリポジトリでは、移行の手順が必要です。BorgBackup の例は 1.x 系の書き方で、2.x 系ではリポジトリの指定方法などが変わっています。どちらのツールも、リポジトリ作成時の設定で暗号化を行えます。

圧縮と暗号化の順番

バックアップを暗号化する場合は、圧縮を先に行います。暗号化されたデータは不規則なデータになるため、あとから圧縮してもほとんど縮みません。restic や BorgBackup は内部でこの順に処理します。

サイトへの影響を抑える

圧縮はCPUを使うため、本番サーバーでの実行中はサイトの応答が遅くなることがあります。-T0 で全コアを使うと速く終わる代わりに、その間の負荷は高くなります。

nice -n 10 ionice -c3 tar -I 'zstd -T2 -6' -cf files.tar.zst -C /var/www/html wp-content

nice でCPUの優先度を、ionice -c3 でI/Oの優先度を下げ、-T2 で使うコアを2つに限っています。サイトの規模とアクセスの少ない時間帯に合わせて調整してください。

圧縮したファイルを検証する

圧縮ファイルは、途中で壊れると、それ以降が読めなくなることがあります。作成したら、展開せずに整合性を検査できます。

zstd -t db-20261018.sql.zst
gzip -t files-20261018.tar.gz
xz -t archive.tar.xz
tar -I zstd -tf files-20261018.tar.zst > /dev/null

-t は圧縮データの検査、tar -tf は中身の一覧を最後まで読めるかの確認です。どちらも、中身が正しく戻せるかまでは保証しないため、ときどきは実際に展開して、WordPressがステージング環境で表示できることを確認してください。

まとめ

• 容量の大半を占める画像は、圧縮してもほとんど縮まない。まず du で内訳を確認する
• 日常のバックアップは zstd、互換性重視なら gzip（速くするなら pigz）、長期保管なら xz
• ダンプはパイプで圧縮し、pipefail で失敗を見逃さない。mysqldump --compress はファイル圧縮ではない
• キャッシュやプラグインのバックアップ保存先を除外し、画像が多いなら重複排除型のツールに切り替える
• 圧縮は暗号化の前に行い、作成後は -t で検査、定期的に展開して確認する

• tarでバックアップスクリプトを作る方法
• rsyncで差分バックアップを取る方法