タグアーカイブ UpdraftPlus

UpdraftPlusのバックアップが途中で失敗する原因と対処法

UpdraftPlusのバックアップが途中で止まって失敗する場合、まず確認すべきはセマフォロックの詰まりとサーバー側の実行時間制限だ。ログにエラーが表示されず、ファイル追加の途中で途切れているなら、バックアップ処理がサーバーから強制終了されている可能性が高い。

バックアップが途中で失敗する原因をログから特定する

UpdraftPlusのログに「このサイトで重大なエラーが発生しました」のような明確なメッセージがなく、zipファイルへのファイル追加が途中で止まっている場合、原因のほとんどはバックアップ処理が外部から強制終了されたことにある。ログの末尾に「失敗」や「エラー」の表記がなく、単に記録が終わっている点が重要な手がかりだ。

具体的には、以下の3つのポイントをログから読み取る。1つ目は冒頭の「Semaphore（セマフォ）」に関する記述だ。「Semaphore was stuck」と表示されているなら、前回のバックアップがクラッシュしてロックが残ったままになっていたことを示している。2つ目は処理中に「cgi-fcgi」と記録されている点で、FastCGI経由でPHPが動いている証拠だ。3つ目はファイル追加の記録が数千件単位で正常に進んだ後、突然途切れている点だ。

上のデモは、強制終了されたバックアップと正常に完了したバックアップのログ末尾の違いを示したものだ。UpdraftPlusのログはバックアップが正常に終わった場合、末尾に完了を示すメッセージが必ず記録される。エラー文言も完了メッセージもないまま記録が途切れているなら、PHPのプロセスごと外部から停止されたと判断できる。

セマフォロックの詰まりが起きる仕組み

セマフォロックとは、同時に複数のバックアップが走らないようにするための「占有フラグ」だ。バックアップ開始時にWordPressのオプションテーブル（wp_options）にロック用の値を書き込み、終了時に削除する。しかし、サーバーが処理を強制終了した場合、ロックを削除する処理まで到達できないため、古いロックが残ってしまう。

残ったロックは次回のバックアップ開始時に「stuck（詰まっている）」と判定され、UpdraftPlusが自動的にリセットする。ログに「Semaphore was stuck, reset to 1」と出ていれば、これは前回のバックアップが異常終了した履歴を示している。ロックの詰まり自体は自動回復するが、その前の回でなぜ強制終了されたのかを解決しなければ、同じ失敗を繰り返す。

セマフォロックの詰まりを解消してから再実行する手順

ロックの詰まりが記録されている場合、まずは古いロックを手動で削除してからバックアップを再実行する。UpdraftPlusはロックを自動リセットするが、データベースに古いレコードが残っていると、別の不整合を引き起こすことがある。手動で掃除してから再実行すれば、より確実に状態をリセットできる。

上記の手順でロックを掃除したら、必ずバックアップを即時実行して挙動を確認する。ロックを消しただけでは根本原因は解消されていないため、再び同じ場所で処理が止まるかどうかをログで追う必要がある。もし再び途中で止まるなら、次のセクションで説明するサーバー側の実行制限が原因だ。

wp_optionsテーブルを安全に操作するには

wp_optionsテーブルの操作はレンタルサーバーの管理画面からphpMyAdminを開いて行う。テーブル名はインストール時にプレフィックスを変更している場合があるため、「wp_options」が存在しない場合は「wp_」の部分を導入時に設定した文字列に読み替える。該当するレコードを検索するには、phpMyAdminのSQLタブで「option_name LIKE ‘updraftplus_locked_%’」のような条件を指定すると確実だ。

データベースを直接触るのが不安な場合は、必ず事前にデータベース全体のエクスポートを実行しておく。wp_optionsテーブルはサイト全体の設定を保持する重要なテーブルなので、削除対象を間違えるとサイトが表示されなくなる恐れがある。削除するのは「updraftplus_」で始まるロック関連のレコードだけに限定する。

サーバーの実行時間制限が原因なら設定を見直す

ログに「cgi-fcgi」と記録されている環境では、サーバー側のFastCGI設定がバックアップ処理を途中で切断している可能性が高い。この場合、UpdraftPlusやWordPressの設定をいくら変更しても解決しない。サーバーの実行時間制限とプロセス管理の仕組みを理解し、制限内に収まるようにバックアップ規模を調整するか、サーバー側の設定を変更する必要がある。

バックアップ対象を絞って1回あたりの負荷を下げる

処理が途中で強制終了される最も簡単な回避策は、1回のバックアップで処理するデータ量を減らすことだ。UpdraftPlusの設定画面で「ファイルのバックアップ」の対象から、変更頻度の低い大容量ディレクトリを除外する。たとえば、開発用のnode_modulesやキャッシュディレクトリ、過去のバックアップファイルなどは除外候補になる。

データベースのバックアップも同様に、ログや一時テーブル、リビジョンなどを除外すると処理時間を短縮できる。とくに投稿リビジョンやスパムコメント、ゴミ箱内のデータは意外と容量が大きい。不要なデータを定期的に削除するだけでも、バックアップの所要時間が大きく変わる。

zip分割サイズとバッチ処理の調整

UpdraftPlusの詳細設定では、zipファイルを分割するサイズを変更できる。デフォルトでは400MBごとに分割されるが、ファイル数が多いサイトでは分割サイズを小さく設定すると、1回のバッチ処理にかかる時間を短縮できる。ログで「split every 400 MB」と表示されている箇所が、この設定の反映だ。

分割サイズを200MBや100MBに下げると、1回のzip処理が短くなり、サーバーの制限時間内に完了しやすくなる。ただし、分割数を増やすと全体の処理時間は逆に延びるため、サーバーの制限時間に対してどこで止まるかを見極めながら調整する。ログの経過時間と処理件数を確認し、どこまで進んだ時点で強制終了されるかを把握することが先決だ。

バックアップを安定させるための追加対策

ロックの掃除とバックアップ対象の絞り込みに加えて、以下の設定を組み合わせると、UpdraftPlusのバックアップ成功率が大きく向上する。いずれも管理画面から変更できる項目なので、サーバーに詳しくなくても実行できる。

バックアップの実行方法を「手動」から「cron」に切り替える

管理画面から手動でバックアップを実行すると、ブラウザとサーバーの接続が切れたタイミングで処理が中断されることがある。一方、WordPressのcron（疑似cron）を使ったスケジュール実行は、サーバー側で処理が完結するため、ブラウザの接続状態に影響されない。UpdraftPlusの設定で「バックアップのスケジュール」を有効にし、実行タイミングを毎日や毎週などに設定する。

ただし、WordPressの疑似cronはサイトへのアクセスをきっかけに動くため、アクセスの少ないサイトでは実行が遅れることがある。その場合はサーバー側のcron（本物のcron）を設定し、wp-cron.phpを定期的に呼び出す方式に切り替えると確実だ。レンタルサーバーの管理画面からcronジョブを追加できる場合が多い。

バックアップの保存先を外部ストレージに変更する

バックアップをサーバー内のディレクトリに保存していると、バックアップ完了後にファイルを外部へ転送する処理が追加され、時間がかかるだけでなく、転送中のエラーで失敗と記録されることがある。UpdraftPlusはGoogle DriveやDropbox、Amazon S3などへの直接アップロードに対応しているため、外部ストレージを保存先に指定すると、サーバー内への書き込みと転送を1つの流れで行える。

外部ストレージへの保存は、サーバーのディスク容量不足による失敗を防ぐ効果もある。バックアップは数GB単位で容量を消費するため、共用サーバーでは容量制限に達して書き込みに失敗するケースが少なくない。ログの冒頭に「Free space on disk」の値が記録されているので、この数値が数十GB以上確保されているかも確認しておく。

PHPの実行時間とメモリ制限を確認する

ログの冒頭には「max_execution_time」と「memory_limit」が記録されている。max_execution_timeはPHPスクリプトが実行できる最大時間、memory_limitはPHPが使用できるメモリの上限だ。どちらもバックアップ処理に直結する設定で、これらの値が小さいと処理が途中で打ち切られる。

レンタルサーバーによっては、管理画面からPHPのバージョンや設定を変更できる。max_execution_timeを300秒以上、memory_limitを512MB以上に設定できるなら変更を検討する。ただし、共有サーバーでは変更できない場合も多い。その場合は先に説明したバックアップ対象の絞り込みで対応するほうが現実的だ。

よくある質問

ログにエラーが何も表示されません。どこを確認すればいいですか？

ログの末尾に「失敗」や「エラー」の文言がなく記録が途中で止まっている場合、PHPのプロセスがサーバーから強制終了された可能性が高い。ログの経過時間と処理済みファイル数を確認し、どこまで進んだ時点で止まったかを特定する。あわせて冒頭のセマフォロック関連の記述も確認する。

セマフォロックは自動的に解消されますか？

UpdraftPlusは次回のバックアップ開始時に古いロックを自動でリセットする。ただし、原因が解決されていなければ再び同じ場所で強制終了され、ロックの詰まりが繰り返される。手動でロックを掃除したうえで、根本原因であるサーバーの実行制限やバックアップ規模の見直しを行うことが重要だ。

バックアップ対象から除外すべきフォルダはありますか？

キャッシュディレクトリ、過去のバックアップファイル、開発用の依存関係が入ったディレクトリ、ログファイルなどは除外候補になる。とくに「node_modules」や「vendor」のようなディレクトリは数千から数万のファイルを含むことがあり、ファイル数の多さがバックアップを遅くする大きな要因になる。

UpdraftPlusのログはどこで確認できますか？

管理画面の「設定」から「UpdraftPlus バックアップ」を開き、「既存のバックアップ」タブを表示する。各バックアップの横にある「ログを表示」ボタンから詳細なログを確認できる。ログは最新のものから順に表示され、画面上でスクロールしながら全文を確認できる。

バックアップが途中で止まる場合、サーバー会社に問い合わせるべきですか？

レンタルサーバーの管理画面から設定を変更できない項目が原因の場合、サーバー会社への問い合わせが必要になる。問い合わせる際は、UpdraftPlusのログの該当部分を添付し、「バックアップが毎回特定のタイミングで強制終了される」と具体的に伝えると、調査がスムーズに進む。

この記事のポイント

• ログに完了メッセージがなく途中で止まる場合は強制終了が原因
• セマフォロックの詰まりは前回の異常終了の痕跡
• wp_optionsのロック関連レコードを手動で削除して状態をリセット
• バックアップ対象の絞り込みとzip分割サイズの調整で負荷を下げる
• cron実行と外部ストレージ保存の組み合わせで成功率を上げる

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている