WordPressマルチサイトのバックアップ方法｜データベースとファイル・自動化・1サイトだけの書き出し

WordPress のマルチサイトは、1つの WordPress で複数のサイトを運用する仕組みです。バックアップの基本は通常のサイトと同じで、「データベース」と「ファイル」の両方を取りますが、全サイトのデータが1つのデータベースと1つの wp-content に入っている点が異なります。この記事では、2026年10月時点の WordPress 7.1 と WP-CLI で確認した手順で、マルチサイトをまとめてバックアップする方法と、1サイトだけを書き出す方法を説明します。

マルチサイトのデータはどこにあるか

データベース

マルチサイトでは、全サイトのテーブルが1つのデータベースに入っています。接頭辞が wp_ の場合、次のようになります。

データベース全体を書き出せば、全サイトのデータがまとめてバックアップされます。

ファイル

• WordPress 本体、プラグイン、テーマは全サイトで共通です
• メディア（アップロードしたファイル）は、メインサイトが wp-content/uploads/、それ以外のサイトが wp-content/uploads/sites/<サイトID>/ に保存されます（WordPress 3.5 より前に作られたネットワークでは wp-content/blogs.dir/ の場合があります）
• wp-config.php にはマルチサイトの設定が書かれています。Apache の場合は .htaccess、Nginx の場合はサーバーの設定ファイルにも、マルチサイト用の書き換え設定があります。これらもバックアップに含めます

マルチサイトかどうかを確認する

WordPress のディレクトリで次を実行します。終了コードが 0 ならマルチサイトです。

wp core is-installed --network && echo "マルチサイトです"

wp-config.php を直接確認する場合は、次のようにします。

grep -nE "define\(\s*'(MULTISITE|WP_ALLOW_MULTISITE)'" wp-config.php

2つの定数は意味が違います。

• WP_ALLOW_MULTISITE：管理画面の「ツール」に「サイトネットワークの設置」を表示するための設定です。これだけではマルチサイトになっていません
• MULTISITE：true になっていれば、ネットワークが作成済みで、マルチサイトとして動いています

サイトの一覧と ID は次で確認できます。

wp site list --fields=blog_id,url

手動でバックアップする

WP-CLIを使う場合

WP-CLI は wp-config.php の接続情報を使うので、パスワードを入力せずにデータベースを書き出せます。

cd /var/www/example.com/public

# データベース全体（全サイト分）を書き出す
wp db export ~/backup/db-$(date +%Y%m%d).sql --single-transaction

# WordPress のディレクトリ全体を固める
tar -czf ~/backup/files-$(date +%Y%m%d).tar.gz -C /var/www/example.com public

• --single-transaction は mysqldump に渡されるオプションで、InnoDB のテーブルを、サイトを止めずに同じ時点の状態で書き出します
• wp-config.php を WordPress のディレクトリの1つ上に置いている場合は、そのファイルも別にコピーします
• 保存先（ここでは ~/backup）は、Web から見えない場所にします

mysqldumpを直接使う場合

WP-CLI がない場合は mysqldump を使います。パスワードをコマンドに書くと、ほかのユーザーからプロセス一覧で見えることがあるため、権限を絞ったファイルに書きます。

# 接続情報のファイルを作る（値は wp-config.php の DB_USER・DB_PASSWORD・DB_HOST）
cat > ~/.wp-backup.cnf <<'EOF'
[client]
user=wpuser
password=ここにパスワード
host=localhost
EOF
chmod 600 ~/.wp-backup.cnf

# データベース全体を書き出す（--defaults-extra-file は最初に書く）
mysqldump --defaults-extra-file=$HOME/.wp-backup.cnf --single-transaction --default-character-set=utf8mb4 --no-tablespaces wpdb | gzip > ~/backup/db-$(date +%Y%m%d).sql.gz

wpdb は wp-config.php の DB_NAME に置き換えます。--no-tablespaces は、MySQL 8.0 の新しい版などで、権限不足（PROCESS 権限）のエラーを避けるために付けます。MariaDB では mysqldump の代わりに mariadb-dump という名前のコマンドが推奨されています。

cronで自動化する

毎日決まった時刻にバックアップを取るスクリプトの例です。/usr/local/bin/wp-multisite-backup.sh として保存し、先頭の3つの値を自分の環境に合わせます。

#!/bin/bash
# WordPress マルチサイトのバックアップ（データベース＋ファイル）
set -euo pipefail

WP_PATH=/var/www/example.com/public      # WordPress のディレクトリ（wp-config.php がある場所）
DEST=/var/backups/wp-multisite           # 保存先（公開ディレクトリの外）
KEEP_DAYS=14                             # 残す日数
PATH=/usr/local/bin:/usr/bin:/bin        # cron から実行したときに wp コマンドを見つけるため

STAMP=$(date +%Y%m%d-%H%M)
umask 077
mkdir -p "$DEST"

# 1. データベース：ネットワーク全体（全サイトのテーブルと共通テーブル）を1ファイルに
wp --path="$WP_PATH" db export - --single-transaction | gzip > "$DEST/db-$STAMP.sql.gz"

# 2. ファイル：WordPress のディレクトリ全体（wp-content/uploads/sites/ も含む）
#    tar は読み取り中にファイルが変わると終了コード 1 を返すため、1 は許容する
tar -czf "$DEST/files-$STAMP.tar.gz" -C "$(dirname "$WP_PATH")" "$(basename "$WP_PATH")" || {
  rc=$?
  [ "$rc" -eq 1 ] || exit "$rc"
}

# 3. 壊れていないかを確認
gzip -t "$DEST/db-$STAMP.sql.gz"
tar -tzf "$DEST/files-$STAMP.tar.gz" > /dev/null

# 4. 古いバックアップを削除
find "$DEST" -name 'db-*.sql.gz' -mtime +"$KEEP_DAYS" -delete
find "$DEST" -name 'files-*.tar.gz' -mtime +"$KEEP_DAYS" -delete

echo "backup done: $STAMP"

実行権限を付けて、一度手で動かして確認します。

sudo chmod 755 /usr/local/bin/wp-multisite-backup.sh
/usr/local/bin/wp-multisite-backup.sh
ls -l /var/backups/wp-multisite

• WordPress のファイルを所有しているユーザーで実行します。保存先のディレクトリには、そのユーザーが書き込めるようにしておきます
• root で実行する場合、WP-CLI は --allow-root を付けないと動きません。ファイルの所有者のユーザーで実行するほうが安全です
• umask 077 により、バックアップのファイルは実行したユーザーだけが読めるようになります。中身には全ユーザーの情報が入っているためです

動作を確認したら、そのユーザーの crontab（crontab -e）に登録します。毎日3時30分に実行する例です。

30 3 * * * /usr/local/bin/wp-multisite-backup.sh >> $HOME/wp-backup.log 2>&1

crontab の行の中では、% が改行の意味になります。date +%Y%m%d のように % を含むコマンドを crontab に直接書く場合は、date +\%Y\%m\%d のように \% と書く必要があります。上の例のように処理をスクリプトにまとめておけば、この問題は起きません。

cron が失敗していないかを知る方法は cronジョブの実行監視と失敗通知設定 を参照してください。

1つのサイトだけを書き出す

特定のサイトのテーブルだけを書き出すには、wp db tables でそのサイトのテーブルを選びます。--url にはサイトの URL（wp site list で表示されるもの）を指定します。

# サイト（例：https://example.com/shop/）のテーブルだけを書き出す
wp db export shop.sql --single-transaction --tables="$(wp db tables --scope=blog --url=https://example.com/shop/ --format=csv)"

--scope=blog を付けると、そのサイトの wp_<ID>_ で始まるテーブルだけが選ばれ、ユーザーなどの共通テーブルは含まれません。メディアは wp-content/uploads/sites/<サイトID>/ を別に固めます。

復元するときの注意

• ネットワーク全体を戻す：データベースのバックアップを丸ごと読み込み、ファイルを展開すれば元に戻ります。WP-CLI では wp db import ファイル名.sql で読み込めます
• 1つのサイトだけを戻す：そのサイトの wp_<ID>_ テーブルとメディアだけを戻します。ユーザー（wp_users・wp_usermeta）やネットワークの設定（wp_blogs・wp_site・wp_sitemeta）は全サイト共通なので、1サイトを戻す目的で上書きすると、ほかのサイトにも影響します
• ドメインや URL を変えて戻す：サイトの URL はサイトごとの wp_<ID>_options だけでなく wp_blogs や wp_site にも入っています。置換は wp search-replace に --network を付けて全サイトを対象にします。手順は WP-CLIのnetworkコマンドでマルチサイトのネットワーク設定を操作する方法 もあわせて確認してください

バックアップは、取れているだけでなく戻せることが大切です。本番とは別の環境に読み込んで、サイトが表示されるかを定期的に確かめます（WordPressのバックアップテストと復元確認の方法）。

保管場所

同じサーバーにだけバックアップを置いていると、サーバーの故障や不正アクセスで一緒に失われます。外部のストレージにも送っておきます（rcloneでクラウドストレージにバックアップする方法｜S3設定・暗号化・cron自動化まで）。データベースのバックアップには全サイトのユーザー情報が入っているため、送り先でも閲覧できる人を限定します。

まとめ

• マルチサイトは全サイトのテーブルが1つのデータベースにあり、データベース全体を書き出せば全サイト分のバックアップになる
• ファイルは WordPress のディレクトリ全体（wp-content/uploads/sites/ を含む）と wp-config.php、Web サーバーの設定を取る
• マルチサイトかどうかは wp core is-installed --network か、wp-config.php の MULTISITE で判断する。WP_ALLOW_MULTISITE だけではマルチサイトではない
• 自動化はスクリプトにまとめて cron から呼ぶ。crontab に直接書く場合は % を \% にする
• 1サイトだけ戻すときは、共通テーブルを上書きしない

関連記事:

• WordPressマルチサイトの設定方法と導入後の管理のポイント
• WP-CLIのsiteコマンドでWordPressマルチサイトを管理する方法
• WordPressのバックアップテストと復元確認の方法