バックアップが動かない原因と確認方法

バックアッププラグインを入れてある。しかしいつ取れたのか分からない。 管理画面を見ると「次回のバックアップ」の日時が過ぎたままになっている。

UpdraftPlus（1.26.8）と BackWPup（5.7.6）を入れて、 どこまでが自動で、どこからが手動なのかを測りました。 あわせて、取れたバックアップが外から取れるかどうかも確認しています。

実測環境#

WordPress 7.1 / PHP 8.2。この環境はループバックが通りません。

loopback 失敗: cURL error 7: Failed to connect to localhost:8080

ループバックとは、サイトが自分自身に HTTP リクエストを投げる仕組みのことです。 WP-Cron はこれで動くため、通らない環境では定期処理が一切動きません。 → 予約投稿されない

レンタルサーバーでも、Basic 認証・WAF・CDN 経由の構成で同じ状態になります。

実測 1: 入れただけでは何も予約されない#

有効化した直後に、登録された定期処理を数えました。

どちらも掃除用の処理が増えるだけです。 「入れた＝バックアップが始まる」ではありません。

BackWPup は「ジョブが 1 件あるのに無い」#

BackWPup は有効化時に First backup という雛形ジョブを作ります。 しかし画面にもコマンドにも出てきません。

有効化した直後の画面。内部に雛形はあるが、設定は何も終わっていない

理由はフラグでした。雛形には tempjob が立っていて、 一覧を作る処理がこれを除外します。

tempjob を外すと、コマンドの一覧には出るようになりました （cron = 0 0 1 * * = 毎月 1 日 0 時、last_run = never）。 それでも予約は入りません。

予約は「掃除の処理」が入れている#

BackWPup の予約は、ジョブを作った時ではなく 12 時間ごとの掃除の処理（backwpup_check_cleanup）が走ったときに登録されます。

実測しました。

その掃除の処理自体も WP-Cron で動きます。 つまりループバックが通らない環境では、 予約が入る前の段階で止まります。

実測 2: 予約しても、時間が来ても走らない#

UpdraftPlus で日次のスケジュールを設定しました。予約は入ります。

updraft_backup           1 日ごと
updraft_backup_database  1 日ごと

ここで予約時刻を過去にずらし、サイトに 3 回アクセスしました。 WP-Cron は「誰かがアクセスしたとき」に起動する仕組みだからです。

1 つも実行されませんでした。ループバックが通らないためです。

管理画面にはこう出ていました。

Next scheduled backups:
  Files:    日, 9月 27, 2026 00:39
  Database: 金, 9月 25, 2026 00:39
  Time now: 土, 9月 26, 2026 01:43

データベースの予定は 9 月 25 日なのに、今は 9 月 26 日です。 画面に「次回」と書かれていても、過ぎた日時のまま止まっていることがあります。 ここが「取れているつもり」の正体です。

実測 3: 手動なら完走する#

同じ状態で、コマンドから直接実行しました。

処理そのものは正常です。壊れているのは「実行のきっかけ」だけ、と確定できます。

対策は予約投稿と同じで、サーバーの cron から叩くことです。

*/15 * * * * cd /path/to/wordpress && wp cron event run --due-now > /dev/null

wp-config.php に define( 'DISABLE_WP_CRON', true ); を入れる場合は、 サーバー側の cron 登録を必ずセットで行います。片方だけだと全部止まります。

実測 4: 取れたバックアップは外から取れる#

置き場所と、未ログインでの到達性を測りました。 別記事で測った All-in-One WP Migration も並べます。

3 つとも nginx では素通りです。.htaccess は Apache しか読まないためです。

実際に未ログインで取得できた中身です。

BackWPup のアーカイブには wp-config.php が入っていました。 データベースの認証情報と認証キーが書かれているファイルです。 → 設定ファイルは漏れるのか

nginx を使っているなら、サーバー設定で塞ぎます。

location ~* /wp-content/(updraft|ai1wm-backups)/ { deny all; }
location ~* /wp-content/uploads/backwpup/         { deny all; }

保存先を公開領域の外に置ける設定があるなら、そちらが確実です。 → .wpress は未ログインで取得できる

実測 5: 消しても設定は残る#

両方のプラグインを削除したあと、残ったオプションを数えました。

uploads/backwpup-restore というディレクトリも残りました。

削除しても設定は消えません。入れ替えを繰り返したサイトでは、 使っていないプラグインの設定が wp_options に積もります。 起動のたびに読み込まれる設定が増えると表示が遅くなります。 → WordPress が重い

確認の順番#

# 1. バックアップの予約が入っているか
wp cron event list | grep -iE 'updraft|backwpup'

# 2. 予定時刻が過去になっていないか（過去のまま = 動いていない）
wp cron event list --fields=hook,next_run_relative | grep -iE 'updraft|backwpup'

# 3. ループバックが通るか
wp eval '$r = wp_remote_get( site_url( "/wp-cron.php" ), array( "timeout" => 5 ) );
echo is_wp_error( $r ) ? "失敗: " . $r->get_error_message() : "成功";'

# 4. 取れたファイルが外から取れないか
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/updraft/

「次回のバックアップ」の日時が過ぎていないかを見るのが、 いちばん早い確認方法です。

wp plugin install updraftplus --activate
wp plugin install backwpup --activate

# 入れただけの状態で予約を数える
wp cron event list --fields=hook,recurrence | grep -iE 'updraft|backwpup'

# UpdraftPlus に日次スケジュールを入れる
wp eval '$GLOBALS["updraftplus"]->schedule_backup("daily");
$GLOBALS["updraftplus"]->schedule_backup_database("daily");'

# 予約時刻を過去にずらしてサイトにアクセスする（実行されない）
for i in 1 2 3; do curl -s -o /dev/null http://localhost:8080/; sleep 3; done
ls wp-content/updraft/backup_* | wc -l

# 手動実行（完走する）
wp cron event run updraft_backup

# BackWPup の雛形ジョブ
wp eval 'echo count(BackWPup_Option::get_job_ids()), "\n";'   # 1 件
wp backwpup job                                                # 0 件
wp eval 'BackWPup_Option::update(1, "tempjob", false);'
wp cron event run backwpup_check_cleanup                       # ここで予約が入る
wp backwpup run 1 --now

# 外から取れるか
curl -s -o /dev/null -w '%{http_code}\n' "http://localhost:8080/wp-content/updraft/<ファイル名>"
curl -s -o /dev/null -w '%{http_code}\n' "http://localhost:8082/wp-content/updraft/<ファイル名>"