2026年7月3日

WordPressのバックアップと復元を自動化する方法｜プラグインとWP-CLI＋cron

カスタマイズ

WordPress のバックアップを自動化するには、データベースと wp-content フォルダの2つを、決まった時刻に、サーバーの外へ保存する仕組みを作ります。方法は、UpdraftPlus などのプラグインで設定する方法と、WP-CLI と cron でスクリプトを動かす方法の2通りです。この記事では両方の手順に加えて、見落とされがちな「復元できるかの定期的な確認」と、復元の手順までを解説します。

何をバックアップすれば復元できるのか

WordPress のサイトは、大きく次の2つでできています。

データベース：投稿、固定ページ、コメント、ユーザー、設定、プラグインの設定値など
wp-content フォルダ：アップロードした画像（uploads）、テーマ、プラグイン

この2つに加えて、wp-config.php と .htaccess（Nginx なら設定ファイル）を控えておくと、復元が速くなります。WordPress 本体のファイル（wp-admin や wp-includes）は公式から入れ直せるので、容量を節約したい場合は対象から外してかまいません。

自動化を考える前に、次の3点を決めておきます。

頻度：記事を毎日更新する、EC サイトで注文が入るなど、データベースの変化が多いサイトは毎日以上。更新が月数回なら週1回でも足ります。ファイルとデータベースで頻度を変えるのも有効です
保存世代：直近の数日分だけでなく、週単位・月単位の古いものも残します。改ざんやデータの破損に気づくのが遅れた場合、直前のバックアップもすでに壊れていることがあるためです
保存先：同じサーバーの中だけに置くと、サーバーの障害や乗っ取りで一緒に失われます。クラウドストレージなど、サーバーの外にも保存します

方法1：プラグインで自動化する

コマンドを使えない共用サーバーや、管理画面だけで完結させたい場合はプラグインを使います。代表的なものは次のとおりです。無料版と有料版で使える保存先や機能の範囲は変わることがあるため、導入前に公式ページで確認してください（2026年10月現在）。

UpdraftPlus：スケジュール実行、Google ドライブや Dropbox、Amazon S3 などへの保存、管理画面からの復元まで扱えます。利用者が多く、情報を見つけやすいプラグインです
BackWPup：スケジュールを細かく設定でき、データベースとファイルを別々のジョブにできます
Duplicator や All-in-One WP Migration：サイト全体を1つのファイルにまとめる用途が中心で、引っ越しや複製に向いています。定期的な自動バックアップとして使えるかどうかは、エディションや設定によって異なります

UpdraftPlus を例にした設定の流れは次のとおりです。画面の項目名はバージョンによって変わるため、目的に合う項目を探してください。

プラグインを有効にし、設定画面でファイルとデータベースのバックアップ間隔をそれぞれ選ぶ
保持する世代数を指定する
保存先（リモートストレージ）を選び、画面の案内に従って連携する
設定を保存したら、手動で1回バックアップを実行し、保存先にファイルが届いたことを確かめる

プラグインのスケジュールは WP-Cron で動きます。WP-Cron は訪問者のアクセスをきっかけに実行されるため、アクセスが少ないサイトでは予定どおりに動かないことがあります。サーバーの cron から wp-cron.php を定期的に呼ぶか、wp-config.php に define( 'DISABLE_WP_CRON', true ); を書いたうえでサーバーの cron から実行する方法で、時刻どおりに動かせます。

また、サイトが大きいとプラグインでのバックアップは PHP の実行時間やメモリの制限で途中で止まりやすくなります。毎回失敗する場合は、アップロードフォルダを分ける、圧縮をやめる、次の WP-CLI の方法に切り替える、を検討します。

方法2：WP-CLI と cron で自動化する

SSH で入れるサーバーなら、WP-CLI とシェルスクリプトで動かすのが確実性と速さの面で有利です。WP-CLI は wp-config.php からデータベースの接続情報を読むので、スクリプトにパスワードを書く必要がありません。

次は、データベースと wp-content を日付つきで保存し、14日より古いものを消すスクリプトの例です。パスは自分の環境に合わせて書き換えてください。

#!/bin/bash
# /home/user/bin/wp-backup.sh
set -euo pipefail

SITE_DIR="/var/www/example.com"     # WordPress を置いたディレクトリ
BACKUP_DIR="/home/user/backups"     # 公開ディレクトリの外に置く
KEEP_DAYS=14
DATE=$(date +%Y%m%d-%H%M)

mkdir -p "$BACKUP_DIR"
umask 077   # 作ったファイルを本人だけが読めるようにする

# データベース（InnoDB ならテーブルをロックせずに一貫した状態で出力）
wp --path="$SITE_DIR" db export - --single-transaction | gzip > "$BACKUP_DIR/db-$DATE.sql.gz"

# wp-content（キャッシュは復元に不要なので除外）
tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" \
  -C "$SITE_DIR" --exclude='wp-content/cache' wp-content wp-config.php

# 古い世代を削除
find "$BACKUP_DIR" -name '*.gz' -mtime +"$KEEP_DAYS" -delete

バックアップの保存先は、Web から見えない場所にします。公開ディレクトリの中に置くと、URL を推測されてデータベースの中身をダウンロードされるおそれがあります。wp-config.php にはデータベースのパスワードが含まれるので、保存したファイルの権限を本人だけが読める状態にしておきます。

スクリプトに実行権限を付け、cron に登録します。

chmod 700 /home/user/bin/wp-backup.sh
crontab -e
# 毎日 3:30 に実行し、結果をログに残す
30 3 * * * /home/user/bin/wp-backup.sh >> /home/user/backups/backup.log 2>&1

cron から実行すると、ログイン時とは環境変数の PATH が違い、wp コマンドが見つからずに失敗することがあります。which wp で WP-CLI の場所を調べ、スクリプトの中ではフルパスで書くか、スクリプトの先頭で PATH を設定しておきます。登録したら、最初の実行時刻のあとにログとバックアップファイルを確認してください。

これだけでは、バックアップがサーバーの中にしかありません。rclone や各クラウドの CLI でスクリプトの最後にクラウドストレージへ転送し、サーバーの外にも置きます。転送先では、バックアップを上書き・削除できないようにするバージョン管理やオブジェクトロックの機能があれば有効にしておくと、サーバーが乗っ取られた場合にバックアップまで消される被害を防ぎやすくなります。転送前に暗号化しておくと、保存先の設定ミスで公開されたときの被害も抑えられます。

失敗に気づける仕組みを作る

自動化で最も多い失敗は、「動いているつもりで、何か月も前から止まっていた」というものです。次のどれかを用意しておきます。

cron の結果をメールで受け取る、または失敗したときだけ通知する
バックアップファイルのサイズを記録し、急に小さくなっていないかを見る（データベースの出力が途中で止まると、ファイルが極端に小さくなります）
月に1回などの頻度で、実際に復元してみる

復元の手順

復元は、本番に戻す前に、ステージング環境やローカル環境で試すのが安全です。復元先にすでにデータがある場合は、上書きする前にその状態もバックアップしておきます。

WP-CLI での復元の流れは次のとおりです。

cd /var/www/example.com
wp maintenance-mode activate

# ファイルを戻す（展開先を確認してから実行）
tar -xzf /home/user/backups/files-20261018-0330.tar.gz -C /var/www/example.com

# データベースを戻す
gunzip -c /home/user/backups/db-20261018-0330.sql.gz | wp db import -

# 別のドメインやステージングに戻した場合は URL を置き換える（まず --dry-run で確認）
wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables --dry-run

wp cache flush
wp maintenance-mode deactivate

wp search-replace は、シリアライズされたデータの文字数も正しく直してくれるため、SQL ファイルをテキストエディタで置き換えるより安全です。--dry-run で置き換え件数を確認してから、オプションを外して実行します。

復元後は、トップページと記事ページの表示、画像、ログイン、フォームの送信を確認し、パーマリンクがおかしい場合は管理画面の「パーマリンク設定」で変更せずに保存し直します。UpdraftPlus などのプラグインで取ったバックアップは、同じプラグインの復元機能を使うのが基本ですが、プラグインが入れられない状況でも、データベースのファイルと wp-content のアーカイブを手で戻せるかどうかを一度確かめておくと安心です。

まとめ

バックアップの対象はデータベースと wp-content。wp-config.php も控えておく
頻度・保存世代・保存先を先に決め、サーバーの外にも保存する
共用サーバーなら UpdraftPlus などのプラグイン、SSH が使えるなら WP-CLI と cron が向いている
WP-Cron は時刻どおりに動かないことがあるため、サーバーの cron を使うと安定する
バックアップは公開ディレクトリの外に置き、権限を絞る
失敗の通知と定期的な復元テストで、「戻せるバックアップ」になっているかを確認する