WordPressをバックアップして、復元できるところまで試す

2026年10月5日

BUILD

WordPressで社内向けサイトを作ったあと、データベースとファイルを手動でバックアップし、別の検証環境へ復元するところまで試しました。

バックアップ用のファイルが作られただけでは、障害時にサイトを戻せるかは分かりません。今回は、何を保存したか、復元後に何を確認したか、自動化で何が未確認のまま残ったかを整理します。

WordPressはファイルだけ保存しても戻らない

WordPressの状態は、大きくデータベースとファイルに分かれます。

画像だけを保存しても投稿や設定は戻りません。データベースだけでは、記事が参照している画像やPDFが欠けます。そこで今回は、MariaDBのSQLダンプに加えて、uploads、plugins、languagesを一組として保存しました。

復元先でURLを確認できるよう、元サイトのURLも記録しました。さらに、SQLとアーカイブにはSHA-256のチェックサムを作り、保存後のファイルが作成時と同じか確認できるようにしました。

バックアップ処理は、途中で止まる可能性があります。SQLは作れたものの、ファイルの圧縮に失敗した状態を完成品として残すと、復元時に必要なデータがそろいません。

そのため、処理中は一時フォルダーへ出力し、すべて成功した後だけ日時名の完成フォルダーへ移す構成にしました。完成フォルダーの存在を、バックアップ一式がそろった目印にします。

同時に二つの処理が走らないようロックを置き、実行結果は専用ログへ残します。古いデータを削除する保持処理も、完成済みの日時フォルダーだけを対象にしました。

いきなり定期実行だけを設定すると、失敗したときにスクリプトとスケジュールのどちらが原因か分かりにくくなります。そこで、先に手動でバックアップを実行しました。

手動実行では、日時フォルダーと必要なファイルが作られ、処理が正常に完了しました。この時点で確認できたのは、保存処理そのものが動くことです。定期実行が動くことまでは、まだ確認できていません。

次に、手動で作ったバックアップを使い、本番とは別の検証環境へコピーサイトを復元しました。元のサイトとバックアップは残したまま、復元練習用の環境を用意しています。

復元では、SQLをデータベースへ戻し、保存した wp-content のデータを配置しました。サイトが起動しただけで終わりにせず、次の項目を確認しました。

これらが動作したことで、今回保存したSQLとファイルから、サイトを利用できる状態へ戻せることを確認できました。

ファイルを展開したとき、パーミッションの再設定に関する警告が出ました。警告が出た事実だけで成功・失敗を決めず、復元後のサイトの状態も確認しました。

今回は画像、PDF、管理画面、投稿、コメント、アップロードが動作していました。そのため、警告は記録へ残しつつ、今回の復元練習を止める致命的な問題ではないと判断しました。

ただし、別の環境で同じ警告が出た場合も無条件で無視できるわけではありません。表示と操作を確認し、必要なら所有者やパーミッションを調べる、という順番が必要です。

手動実行を確認した後、毎日午前2時に動く定期バックアップも設定しました。しかし翌日に確認すると、新しい日時フォルダーが作られていませんでした。

時刻、タイムゾーン、スケジュール設定、ログ、保存先、cronのプロセスを順に確認しました。ログには手動実行の成功だけが残り、午前2時に処理を開始した記録がありませんでした。

この結果から、バックアップ処理の途中で失敗したのではなく、cronから処理自体が起動していなかったと判断しました。設定を実行中のcrontabへ再登録し、cronを再起動して、ジョブが読み込まれているところまで確認しました。

ただし、2026年10月2日時点の作業ログには、再設定後の次回午前2時に自動実行が成功した記録は残っていません。

そのため、「自動バックアップまで正常に稼働した」とは扱いません。確認できたのは、手動バックアップの成功、別環境での復元成功、cronの再登録までです。

cronへ設定行があること、プロセスが動いていること、手動実行が成功することは、それぞれ必要な確認です。しかし、それだけで予定時刻の自動実行が成功した証明にはなりません。

定期バックアップの成功条件は、予定時刻を過ぎたあとに新しい完成フォルダーがあり、ログが成功を示し、必要なファイルとチェックサムがそろっていることです。さらに定期的な復元練習まで行えば、保存と復旧を一つの運用として確認できます。

今回の実験で分かったのは、バックアップの完成条件を「ファイルがある」だけにしないことでした。

保存できたこと、復元できたこと、自動で続けられることは、別々に確認する。

この切り分けにより、成功した範囲と未確認の範囲を混ぜずに残せました。社内向けWordPressを運用できる状態へ仕上げた全体の記録は、社内ポータルを仕上げる｜WordPress実制作記録でまとめています。