WordPress のバックアップが大きくなる原因は、たいてい「バックアップに入れなくてよいもの」が混ざっていることです。キャッシュや古いバックアップファイル、肥大化したデータベースを除き、データベースとメディアを分けて扱うだけで、保存容量も作成時間もかなり減らせます。この記事では、容量の内訳を調べる方法から、除外の設定、データベースの整理、圧縮と世代管理までを順に説明します。
まず容量の内訳を調べる
闇雲に削る前に、どこが大きいのかを数字で確認します。SSH で入れるサーバーなら、WordPress のディレクトリで次のコマンドを実行します。
cd /var/www/html
du -sh wp-content/* | sort -h
du -h --max-depth=2 wp-content/uploads | sort -h | tail -15よくあるのは次のパターンです。
wp-contentの中に、バックアッププラグインが作った過去のバックアップが溜まっている- キャッシュプラグインの
wp-content/cacheが数GBになっている uploadsの大半が、画像ごとに自動生成されたサムネイル（中間サイズ）で占められているdebug.logなどのログファイルが長期間消されずに残っている
データベースの大きさは WP-CLI で確認できます。テーブルごとの内訳は SQL で見るのが確実です。
wp db size --human-readable
wp db query "SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY size_mb DESC LIMIT 15;"wp_posts や wp_postmeta が大きいならリビジョンや下書き、wp_options が大きいなら期限切れのトランジェント、プラグイン独自のテーブルが大きいならログや統計データが原因であることが多いです。
作り直せるものはバックアップから外す
容量を減らすうえで最も効果が大きいのが、除外の設定です。次のものは失っても再生成できるか、そもそも復元に不要です。
- キャッシュ（
wp-content/cacheなど） - バックアッププラグイン自身の保存先（UpdraftPlus なら
wp-content/updraft、All-in-One WP Migration ならwp-content/ai1wm-backups） - 更新作業用の一時フォルダ
wp-content/upgrade - ログファイル（
*.log）
特に注意したいのが「バックアップの中にバックアップが入る」状態です。プラグインの保存先をサイト内に置いたままファイル全体をバックアップすると、毎回過去の分まで含まれて雪だるま式に大きくなります。バックアッププラグインを使っている場合は、設定画面にあるディレクトリの除外項目で上記を外し、保存先はクラウドストレージなどサイトの外にしてください。
自前で tar を使う場合は、除外指定をファイル指定より前に書きます。
tar --exclude='wp-content/cache' \
--exclude='wp-content/updraft' \
--exclude='wp-content/ai1wm-backups' \
--exclude='wp-content/upgrade' \
--exclude='*.log' \
-czf /backups/files-$(date +%Y%m%d).tar.gz -C /var/www/html .作成後は tar -tzf ファイル名 | grep cache のように中身を一覧し、除外したはずのものが入っていないかを確認します。
データベースの不要データを整理する
データベースを整理する前に、現時点のエクスポートを取っておきます。削除は元に戻せません。
wp db export before-cleanup.sqlそのうえで、影響の小さいものから順に片付けます。
# 期限切れのトランジェントを削除
wp transient delete --expired
# スパムコメントを削除
wp comment delete $(wp comment list --status=spam --format=ids) --force
# リビジョンを削除（件数が多い場合は xargs で分割）
wp post list --post_type=revision --format=ids | xargs -n 100 wp post delete --forceリビジョンは記事を更新するたびに増えるので、削除と合わせて上限を決めておくと再び増えにくくなります。wp-config.php の /* That's all, stop editing! */ より上に次の1行を加えると、1記事あたり5件までに制限されます。
define( 'WP_POST_REVISIONS', 5 );プラグインのログテーブル（アクセス統計、メール送信履歴、セキュリティログなど）が大きい場合は、テーブルを直接消すのではなく、そのプラグインの設定にある保存期間やログ削除の機能を使ってください。直接削除すると、プラグインが前提にしているデータまで失うことがあります。
なお、mysqldump や wp db export で作るダンプにはデータそのものしか書き出されないため、テーブル内の空き領域はダンプのサイズに影響しません。wp db optimize が効くのは、ディスクの使用量やスナップショット型のバックアップのほうです。
メディアは「増やさない」と「分けて扱う」
uploads は多くのサイトで最大の領域ですが、JPEG や PNG、WebP はすでに圧縮された形式なので、gzip などで固めてもほとんど小さくなりません。ここで効くのは次の2つです。
1つ目は、増えるペースを抑えることです。アップロード前に画像の解像度を必要な大きさに落とす、テーマで使っていない中間サイズを登録しない、といった対策で、1枚あたりの生成ファイル数と容量が減ります。既存のサムネイルを消す作業は表示崩れの原因になるため、整理するなら検証環境で確認してからにしてください。
2つ目は、データベースとメディアを別のバックアップにすることです。データベースは毎日変わり、圧縮もよく効きます。一方でメディアは追加されるだけで、過去のファイルはほとんど変わりません。メディアを毎回フルで固めるのをやめ、rsync などの差分方式で前回から増えた分だけを転送すれば、保存容量も転送時間も大幅に減ります。
圧縮方式と世代管理
データベースのダンプはテキストなので、圧縮するとかなり小さくなります。書き出しと同時に圧縮すれば、圧縮前の巨大なファイルをディスクに置かずに済みます。
wp db export - --single-transaction | gzip > /backups/db-$(date +%Y%m%d).sql.gzgzip より高い圧縮率が欲しい場合は、zstd や xz を使う方法もあります。zstd は圧縮率と速度のバランスがよく、GNU tar の新しい版では --zstd オプションで指定できます。どの方式でも、復元するサーバーに同じ展開ツールがあるかを事前に確認してください。
保存容量を決めるもう1つの要素が世代数です。毎日のバックアップを無期限に残すと、1回分を小さくしても合計は増え続けます。「日次を14日分、月初の分を数か月分」のように保持期間を決め、古いものを消す処理を組み込みます。
# /backups 内の14日より古い圧縮ファイルを削除（先に -delete を外して対象を確認）
find /backups -name '*.gz' -mtime +14 -print
find /backups -name '*.gz' -mtime +14 -delete小さくしたら復元テストをする
除外や整理を進めると、必要なものまで外してしまう危険があります。設定を変えたら、検証用の環境にバックアップを戻し、トップページ・記事・画像・管理画面が正常に表示されるかを確認してください。特に、テーマやプラグインが wp-content 直下に独自のフォルダ（フォントや生成済みCSSなど）を作っている場合、それを除外していないかを見ておきます。
バックアッププラグインの機能名や設定項目の表記は、バージョンによって変わることがあります（2026年10月現在）。画面が本記事の説明と違う場合は、各プラグインの公式ドキュメントで除外設定と保存期間の項目を確認してください。
まとめ
- 最初に
duとwp db size、テーブル別の容量確認で、どこが大きいのかを数字で把握する - キャッシュ、過去のバックアップ、一時フォルダ、ログはバックアップから除外し、保存先はサイトの外に置く
- データベースはエクスポートを取ってから、トランジェント・スパム・リビジョンの順に整理し、
WP_POST_REVISIONSで増加を抑える - メディアは圧縮が効かないので、データベースと分けて差分方式でバックアップする
- ダンプは書き出しと同時に圧縮し、保持期間を決めて古い世代を消す。変更後は復元テストで確認する