WordPressのコールドバックアップとホットバックアップの違いと使い分け

コールドとホットの違い

バックアップは、取得中にサービスを止めるかどうかで2つに分けられます。

どちらが優れているというより、「止められるか」「どの時点のデータが揃っていればよいか」で選びます。多くのサイトでは、日々はホットバックアップを自動で取り、大きな作業の前だけコールドバックアップを取る組み合わせが現実的です。

WordPressでバックアップする対象

WordPressのデータは、データベースとファイルに分かれています。どちらか一方だけでは元に戻せません。

• データベース: 投稿、固定ページ、コメント、ユーザー、設定（wp_options）など
• wp-content/: アップロードした画像（uploads）、テーマ、プラグイン
• wp-config.php: データベース接続情報と認証用のキー
• サーバー側の設定: .htaccess、Nginx／Caddyの設定、PHPの設定など（作り直せるなら控えでも可）

WordPress本体（wp-admin・wp-includes）は公式配布物から入れ直せるため、容量を抑えたい場合は省いても構いません。

ホットバックアップの取り方

データベース: mysqldump の --single-transaction

テーブルがInnoDBであれば、--single-transaction を付けた mysqldump で、サイトを止めずにある時点の一貫したダンプが取れます。ダンプ開始時点のスナップショットを読むため、取得中の書き込みは混ざりません。

パスワードをコマンドラインに書かないよう、オプションファイルを用意します。

# ~/.my.cnf（chmod 600 にする）
[client]
user=wp_backup
password=ここにパスワード

chmod 600 ~/.my.cnf
mysqldump --single-transaction --no-tablespaces --default-character-set=utf8mb4 \
  wordpress_db | gzip > /var/backups/wp/db_$(date +%Y%m%d_%H%M).sql.gz

• --no-tablespaces は、MySQL 8.0以降で PROCESS 権限の無いユーザーがダンプするときに必要です。
• MariaDBでは同じ働きの mariadb-dump も使えます。
• --single-transaction が一貫性を保てるのはInnoDBなどトランザクション対応のテーブルだけです。古いサイトでMyISAMが残っていないか確認しておきます。

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'wordpress_db' AND ENGINE <> 'InnoDB';

• ダンプ中に ALTER TABLE などの構造変更が走ると、ダンプが失敗したり不整合になったりします。プラグインの更新と時間をずらします。

WP-CLIがある環境では、wp-config.php の接続情報を使ってダンプできます。wp db export は追加の引数を mysqldump にそのまま渡すので、--single-transaction を付けます。

cd /var/www/wordpress
sudo -u www-data wp db export /var/backups/wp/db_$(date +%Y%m%d).sql --single-transaction

データベース: 物理ホットバックアップ

データベースが数GB以上あり、ダンプや復元に時間がかかる場合は、データファイルを動かしたままコピーする物理バックアップが向きます。MariaDBなら mariadb-backup、MySQLならPercona XtraBackup（MySQLのバージョンに合う系列を選ぶ）を使います。MariaDBの例です。

sudo apt install mariadb-backup
sudo mariadb-backup --backup --target-dir=/var/backups/wp/mariadb_full
# 復元に使える状態に整える（取得中の変更を適用する）
sudo mariadb-backup --prepare --target-dir=/var/backups/wp/mariadb_full

復元するときはMariaDBを止め、データディレクトリを空にしてから --copy-back で戻し、所有者を mysql に直します。

sudo systemctl stop mariadb
sudo mv /var/lib/mysql /var/lib/mysql.old    # 元のデータは消さずに退避
sudo mkdir /var/lib/mysql
sudo mariadb-backup --copy-back --target-dir=/var/backups/wp/mariadb_full
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mariadb

ファイル: tar または rsync

ファイルは公開中でも tar や rsync で複製できます。ただし、コピー中にアップロードされた画像は入ったり入らなかったりします。

tar -czf /var/backups/wp/files_$(date +%Y%m%d).tar.gz -C /var/www wordpress

データベースを先に、ファイルを後に取るのがおすすめです。逆の順番だと、データベースには記録があるのに画像ファイルが無い、という状態のバックアップができることがあります。先にデータベースを取れば、ファイル側に余分な画像が増えるだけで済みます。

rsync は実行した時点の差分を同期するだけで、常時の複製（リアルタイム同期）ではありません。また --delete を付けた同期先は、元のファイルを消すと同期先からも消えるため、それ単体では誤削除への備えになりません。日付ごとに残す方法はrsyncでWordPressをバックアップする方法を参考にしてください。

コールドバックアップの取り方

書き込みを止めるので、データベースとファイルの時点がそろったバックアップになります。サーバー移行やメジャーアップデートの直前に向いています。

方法1: メンテナンスモードにしてダンプする

データベースは動かしたまま、WordPressへの書き込みだけを止める方法です。

cd /var/www/wordpress
sudo -u www-data wp maintenance-mode activate
sudo -u www-data wp db export /var/backups/wp/db_cold_$(date +%Y%m%d).sql
tar -czf /var/backups/wp/files_cold_$(date +%Y%m%d).tar.gz -C /var/www wordpress
sudo -u www-data wp maintenance-mode deactivate

メンテナンスモード中は、訪問者に「メンテナンス中」の画面が表示されます。WP-Cronや外部からのAPI経由の書き込みも止めたい場合は、次の方法2を使います。

方法2: Webサーバーとデータベースを止めてコピーする

sudo systemctl stop nginx        # Apacheなら apache2、Caddyなら caddy
sudo systemctl stop mariadb      # MySQLなら mysql
sudo tar -czf /var/backups/wp/mysql_datadir_$(date +%Y%m%d).tar.gz -C /var/lib mysql
sudo tar -czf /var/backups/wp/files_cold_$(date +%Y%m%d).tar.gz -C /var/www wordpress
sudo systemctl start mariadb
sudo systemctl start nginx

データディレクトリをそのまま複製したバックアップは、同じ系列・同じバージョンのMySQL/MariaDBでしか戻せない点に注意してください。別のバージョンのサーバーへ移す予定があるなら、方法1のダンプ（SQL）も取っておきます。

取ったバックアップを確かめる

バックアップは戻せることを確認して初めて役に立ちます。本番とは別のデータベースに読み込んで、エラーが出ないか、投稿数がそろっているかを見ます。

mysql -e "CREATE DATABASE wp_restore_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"
gunzip -c /var/backups/wp/db_20261001_0300.sql.gz | mysql wp_restore_test
mysql -e "SELECT COUNT(*) FROM wp_restore_test.wp_posts WHERE post_status='publish'"
mysql -e "DROP DATABASE wp_restore_test"

テーブル接頭辞を wp_ 以外にしている場合は、テーブル名を読み替えてください。

使い分けの目安

• 毎日の定期バックアップ: ホット（--single-transaction 付きのダンプ＋ファイルのアーカイブ）を自動化する。手順はWordPressのバックアップを自動化するBashスクリプトで紹介しています。
• 大きなデータベース: 物理ホットバックアップ（mariadb-backup／XtraBackup）を検討する。
• サーバー移行・メジャーアップデート・PHP更新の直前: 停止時間を告知したうえでコールドバックアップを取る。
• 保存先: 同じサーバーだけに置かず、別の場所にも複製する。考え方はWordPressの3-2-1バックアップルールを参照してください。