WordPressのデータベースをバックアップする方法（mysqldump・WP-CLI・UpdraftPlus）

WordPress の記事・固定ページ・コメント・設定・ユーザー情報は、すべてデータベース（MySQL または MariaDB）に入っています。画像やテーマ、プラグインは wp-content 以下のファイルなので、データベースのバックアップとは別に取る必要があります。

この記事では、データベースのバックアップを次の3つの方法で取る手順と、自動化・保管・復元テストの方法を説明します。

バックアップを取る前に確認すること

接続情報を確認する

データベース名・ユーザー名・ホストは wp-config.php に書かれています。

grep -E "DB_NAME|DB_USER|DB_HOST|table_prefix" /var/www/html/wp-config.php

/var/www/html は WordPress を置いたディレクトリに読み替えてください。パスワード（DB_PASSWORD）は画面やログに残さないよう、必要なときだけファイルを開いて確認します。

保存先のディレクトリを用意する

バックアップは公開ディレクトリ（ドキュメントルート）の外に置きます。公開ディレクトリに置くと、URL を推測されてダウンロードされるおそれがあります。

この記事の VPS 向けのコマンドは、root のシェル（sudo -i で切り替えたもの）で実行する前提です。保存先を root だけが読めるディレクトリにするためで、WP-CLI だけはファイルの所有者のユーザーで動かします。

mkdir -p /var/backups/wordpress
chmod 700 /var/backups/wordpress

方法1：mysqldump でバックアップする

パスワードをオプションファイルに書く

--password=... のようにコマンドラインへパスワードを書くと、シェルの履歴やプロセス一覧に残ります。MySQL のクライアントは、オプションファイルの [mysqldump] グループから接続情報を読めます。

# /root/.wp-backup.cnf
[mysqldump]
user=wp_user
password=ここにDB_PASSWORDの値
host=localhost

chmod 600 /root/.wp-backup.cnf

ダンプを取る

mysqldump --defaults-extra-file=/root/.wp-backup.cnf \
  --single-transaction \
  --no-tablespaces \
  wp_database | gzip > /var/backups/wordpress/db_$(date +%Y%m%d_%H%M%S).sql.gz

• --defaults-extra-file は最初のオプションとして書く必要があります。
• --single-transaction は、InnoDB のテーブルをロックせずに、開始時点で整合したデータを書き出します。現在の WordPress のテーブルは通常 InnoDB です。
• --no-tablespaces は、MySQL 8.0.21 以降で PROCESS 権限のないユーザーが実行したときに出る「you need (at least one of) the PROCESS privilege(s)」というエラーを避けます。WordPress の復元には表領域の情報は不要です。
• MariaDB では mariadb-dump という名前のコマンドが正式名で、環境によっては mysqldump が無い場合があります。その場合は mysqldump を mariadb-dump に置き換えてください（オプションは同じです）。

中身を確認する

ls -lh /var/backups/wordpress/
zcat /var/backups/wordpress/db_20261110_020000.sql.gz | head -20

ファイル名は実際に作られたものに置き換えます。先頭に -- MySQL dump や -- MariaDB dump の行があり、CREATE TABLE 文が続いていれば書き出せています。

方法2：WP-CLI の wp db export でバックアップする

WP-CLI の wp db export は、wp-config.php の接続情報を使って mysqldump を実行します。パスワードを別に用意しなくて済むのが利点です。

ファイル名に - を指定すると標準出力に書き出すので、圧縮しながら保存できます。WP-CLI は WordPress のファイルの所有者（Ubuntu の Apache なら www-data）として実行し、出力の保存は root のシェルが行います。

sudo -u www-data wp --path=/var/www/html db export - | gzip > /var/backups/wordpress/db_$(date +%Y%m%d_%H%M%S).sql.gz

ファイル名を指定した場合（例：wp db export backup.sql）は、実行したユーザーが書き込める場所に書き出されます。ファイル名を省略すると、カレントディレクトリに「データベース名-日付-ランダムな文字列.sql」の名前で作られます。

• wp db export は既定で --no-tablespaces を付けて mysqldump を呼びます（付けたくない場合は --include-tablespaces）。
• --single-transaction など mysqldump のオプションは、そのまま付け足せます（例：wp db export - --single-transaction）。
• 特定のテーブルだけなら --tables=wp_posts,wp_postmeta、除外するなら --exclude_tables=... を使います。
• root で実行する場合は --allow-root が必要ですが、ファイルの所有者を変えてしまうことがあるため、上のように所有者のユーザーで実行するのが安全です。

WP-CLI の基本は WP-CLIでデータベースをエクスポートする方法 にもまとめています。

方法3：UpdraftPlus でバックアップする（SSH が使えない場合）

SSH が使えないレンタルサーバーでは、バックアッププラグインを使います。UpdraftPlus は無料版でデータベースとファイルのバックアップ、スケジュール実行、復元、外部ストレージへの保存ができます（2026年11月時点、バージョン 1.26.14）。

1. 管理画面の「プラグイン」→「新規追加」で UpdraftPlus を検索してインストールし、有効化します。
2. 「設定」→「UpdraftPlus バックアップ」を開き、「設定」タブを表示します。
3. 「ファイルのバックアップスケジュール」と「データベースバックアップのスケジュール」で間隔（例：毎日）と、「予約からのバックアップを保存しておく数」を指定します。無料版では 2・4・8・12 時間ごと、毎日、毎週、2週間ごと、毎月から選べます。
4. 保存先（リモートストレージ）を選びます。無料版では Dropbox、Google Drive、Amazon S3（互換ストレージを含む）、FTP、メールなどが使えます。選んだサービスの画面の指示に従って連携します。
5. 「変更を保存」を押し、「バックアップ / 復元」タブの「今すぐバックアップ」で一度手動実行して、「既存のバックアップ」に表示されることを確認します。

差分バックアップやデータベースの暗号化は有料版の機能です。

バックアップを自動化する（cron）

mysqldump や WP-CLI を使う場合は、シェルスクリプトを cron から毎日実行します。

#!/bin/bash
# /usr/local/bin/wp-db-backup.sh
set -euo pipefail

WP_PATH="/var/www/html"
BACKUP_DIR="/var/backups/wordpress"
KEEP_DAYS=7
FILE="${BACKUP_DIR}/db_$(date +%Y%m%d_%H%M%S).sql.gz"

mkdir -p "$BACKUP_DIR"

# DB をエクスポートして圧縮（失敗したら set -e と pipefail で止まる）
sudo -u www-data wp --path="$WP_PATH" db export - --single-transaction | gzip > "$FILE"

# 圧縮ファイルが壊れていないか確認
gzip -t "$FILE"

# 保存日数を過ぎたファイルを削除
find "$BACKUP_DIR" -name 'db_*.sql.gz' -mtime +"$KEEP_DAYS" -delete

echo "$(date '+%F %T') backup ok: $FILE"

chmod 700 /usr/local/bin/wp-db-backup.sh
crontab -e

root の crontab に次の1行を追加します（毎日 2:00 に実行し、結果をログに追記）。

0 2 * * * /usr/local/bin/wp-db-backup.sh >> /var/log/wp-db-backup.log 2>&1

set -o pipefail を付けないと、wp db export が失敗しても gzip が成功すれば成功扱いになり、空のバックアップが残ります。

バックアップをサーバーの外に保存する

同じサーバーに置いたバックアップは、ディスク障害やサーバーの乗っ取りで一緒に失われます。少なくとも1つはサーバーの外に置きます。Amazon S3 を使う例です（AWS CLI をインストールし、書き込み権限だけを持つ IAM ユーザーの認証情報を設定済みとします）。

# 上のスクリプトの最後に追加する
aws s3 cp "$FILE" "s3://your-backup-bucket/wordpress/db/" --storage-class STANDARD_IA

S3 に置いた古いファイルは、スクリプトで消すよりも、バケットのライフサイクルルールで「作成から○日後に削除」と指定するほうが、スクリプトの誤りで消し過ぎる心配がありません。

あわせて wp-content（アップロード画像・テーマ・プラグイン）もアーカイブして保存しておくと、サーバーごと失ったときにも復元できます。

tar -czf /var/backups/wordpress/files_$(date +%Y%m%d).tar.gz \
  -C /var/www/html wp-content --exclude=wp-content/cache

復元できるか確認する

バックアップは、実際に戻せることを確かめて初めて役に立ちます。本番とは別のテスト環境（別のデータベース）で復元してみます。

# 圧縮ファイルが壊れていないか
gzip -t /var/backups/wordpress/db_20261110_020000.sql.gz && echo OK

# テーブル数を数える（WordPress 本体だけなら 12 個前後、プラグインで増える）
zcat /var/backups/wordpress/db_20261110_020000.sql.gz | grep -c '^CREATE TABLE'

# テスト環境の WordPress に取り込む（wp db import は「-」で標準入力から読む）
zcat /var/backups/wordpress/db_20261110_020000.sql.gz | sudo -u www-data wp --path=/var/www/test db import -

# 記事が読めるか確認
sudo -u www-data wp --path=/var/www/test post list --posts_per_page=5

テスト環境のドメインが本番と違う場合は、復元後に wp search-replace で URL を置き換えないと、管理画面へのアクセスが本番に飛ばされます。

注意点

• wp db import や mysql での復元は、取り込み先のデータベースの内容を上書きします。本番に戻すときは、戻す前にその時点のバックアップを別に取ってください。
• オプションファイルやスクリプトには DB のパスワードが入ります。権限を 600／700 にし、Git などに含めないようにします。
• レンタルサーバーでは、サーバー会社の自動バックアップ機能がある場合があります。保存期間と復元方法（無料か有料か）を事前に確認しておくと、プラグインと組み合わせて使えます。