WordPressサイトがクラッシュしてアクセス不能になったとき、慌てずにバックアップから復元することが求められます。突然のトラブルでデータが失われると、ビジネス機会の損失やサイト信頼性の低下につながりかねません。本記事では、復元前の準備からファイル・データベース復元、動作確認、テスト環境での復元方法、今後のバックアップ対策まで、初心者でも迷わない具体的かつ丁寧な手順を詳しく解説します。この記事を最後まで読めば、「緊急時でもこの記事さえあれば復旧できる」という安心感を持って作業に臨めるはずです。
1. 事前準備：新環境構築とサイト停止方法
結論：安全に復元作業を行うには、まず別環境でWordPressを立ち上げ、現行サイトを一時停止することが必須です。
復元作業中にサイト訪問者への影響を最小限に抑え、データの不整合を防ぐため、ステージング環境を用意し、メンテナンスモードで既存サイトを停止しましょう。
理由：不完全な復元や上書きでさらなるトラブルを防ぐ
本番環境のままファイルやデータベースを直接上書きすると、途中でエラーが発生した際にサイトが完全に機能しなくなるリスクがあります。ステージング環境での検証を先に行うことで、手順の間違いや不足を事前に洗い出し、安全な移行が可能になります。
具体例：ステージング環境の用意からメンテナンスモード設定まで
1. 新サーバー／ローカル環境の準備
– レンタルサーバーの別サブドメイン、またはローカル開発環境（XAMPP/MAMP）を用意し、PHP・MySQLが動作する状態にします。
2. 空のWordPressをインストール
– 最新版のWordPressをダウンロードし、ステージング環境に配置。データベースは空の状態でOKです。
3. メンテナンスモードの有効化
– 本番サイトのwp-content/pluginsにメンテナンス用プラグイン（例：WP Maintenance Mode）をインストールし、一時的にサイト全体を停止。訪問者には「ただいまメンテナンス中」の画面を表示し、検索エンジンにもクロール停止を指示します。
4. FTP／データベース情報の整理
– 復元に必要なFTPホスト、ユーザー名、パスワード、phpMyAdminのログイン情報を手元にまとめ、不足があれば事前に取得しておきます。
5. バックアップファイルの配置確認
– 手元にあるバックアップ（ファイル群＋SQLダンプ）の最新版を確認。ファイルのタイムスタンプとSQLの先頭コメントを照合し、本当に最新であることを必ずチェックしてください。
2. ファイル復元：FTPでのアップロード手順と注意点
結論：バックアップ済みのWordPressファイルをFTPクライアントで正確に上書きして、サイトのファイル構成を元に戻しましょう。
FTPクライアント（FileZilla、WinSCPなど）を使い、正しいディレクトリ構造でバックアップファイルをアップロードすることが重要です。途中で転送エラーがないか確認しながら実行すると、ファイル欠損による不具合を防げます。
理由：ディレクトリ構造のずれやファイル欠落は動作不良の原因に
WordPressはテーマ、プラグイン、メディア、コアファイルなどが階層化されており、1つでもファイルが欠落すると致命的エラー（500エラーやWhite Screen of Death）を引き起こします。FTP転送時の失敗やフォルダ構造のミスマッチを避けるため、常に上書きモードで一括転送しつつ、ログを確認しながら実施しましょう。
具体例：FTPでファイルを復元する手順
- FTPクライアントに接続
– ホスト、ユーザー名、パスワード、ポート（通常21）を入力して接続します。
– 接続に成功したら、右側ペインでステージング環境（または本番環境）のルートディレクトリ（例：public_html）を開きます。 - バックアップファイルの解凍と配置
– ローカルPC上でバックアップZIPを解凍し、`wp-content`や`wp-includes`、`wp-admin`など**ルート直下**にあるフォルダとファイルが並ぶ状態にします。
– メディアフォルダ（`wp-content/uploads`）は特に容量が大きいため、分割アップロード機能を使うか、帯域制限を設定して転送中の切断を防ぎましょう。 - 上書きアップロードの設定
– FTPクライアントの転送オプションで「常に上書き」を選択。既存ファイルを上書きすることで、不要な古いファイルを残さず復元できます。
– 転送前に「バックアップしたファイルサイズ」と「リモートのファイルサイズ」を比較し、大きさが一致するか確認しておくとミスを防げます。 - 転送後の整合性チェック
– 転送完了後、FTPクライアントのログパネルでエラーや警告がないか確認。
– ランダムに複数のファイル（例：`wp-config.php`、`index.php`、テーマ内のテンプレートファイル）をダウンロードし、差分エディタでバックアップファイルと照合します。 - パーミッション設定の見直し
– テーマやプラグインフォルダのパーミッションが適切か確認。一般的にはディレクトリが755、ファイルが644ですが、プラグインによっては特定のフォルダに書き込み権限（775）を必要とする場合があります。
– `wp-config.php`はセキュリティ向上のために400または440に設定することを推奨します。
3. データベース復元：phpMyAdminでのインポート方法
結論：バックアップしたSQLダンプをphpMyAdminで正しくインポートし、テーブル構造とデータを元通りに復元しましょう。
WordPressの投稿、設定、ユーザー情報などは全てデータベースに保存されています。テーブル構造が壊れたりデータが抜け落ちたりすると、サイト表示の不具合や投稿消失につながるため、インポート前にテーブルを空にし、インポート後に正常に反映されたかを必ず確認してください。
理由：インポート時のミスはサイト全体の動作停止やデータ不整合を招く
誤った文字コード設定や途中エラーによるインポート失敗は、文字化けやリンク切れ、さらにはSQLエラーによる500エラーを引き起こします。特にシリアライズされた配列を含むユーザーメタやオプションは、文字列長の変化によって正しく復元できない恐れがあるため、文字コード（utf8mb4など）と照合順序（utf8mb4_general_ciなど）をバックアップ時と同じに揃えることが重要です。
具体例：phpMyAdminを使ったデータベース復元手順
- phpMyAdminにログイン
– ブラウザでステージング環境のphpMyAdminにアクセスし、データベースユーザーとパスワードでログインします。 - 既存テーブルの削除
– 復元先データベース内の全テーブルをチェックボックスで選択し、「削除」をクリックして空の状態にします。
– テーブル数が多い場合は、一括削除SQL（DROP TABLE `wp_*`;）を実行しても構いません。 - 文字コードと照合順序の確認
– 左ペインでデータベース名をクリックし、上部の「操作」タブを開いて「照合順序」がバックアップ時と同じか確認。
– 不一致の場合はプルダウンから同じもの（例：utf8mb4_general_ci）を選択して「実行」をクリック。 - SQLダンプファイルのインポート
– 上部「インポート」タブを選択し、「ファイルを選択」からバックアップSQL（.sqlまたは.zip）をアップロード。
– 「文字セット」をutf8mb4に設定し、「実行」をクリック。
– 大容量の場合はZIP圧縮しておくか、php.iniでupload_max_filesizeを増やす必要があります。 - インポートエラーの確認と対処
– インポート後、下部にエラーが表示されていないか確認。
– 「#1071 Specified key was too long」などのIndexエラーが出た場合、SQLファイル内で該当箇所をVARCHAR(191)に書き換えるか、MySQLバージョンに合わせた調整が必要です。
– 「WordPress 関数が存在しない」などのテーブル欠落エラーが出た場合は、再インポート前に必ず全テーブルを削除し、ファイルが完全であるか再チェックしましょう。 - シリアライズデータの整合性チェック
– ユーザーメタやオプションテーブル内のシリアライズ配列は文字列長を含むため、シリアライズ解除ツールで一部データを確認し、文字化けや配列崩れがないかチェックします。
– 問題がある場合は、元のバックアップSQLをテキストエディタで開き、文字コードをUTF-8 BOMなしに統一して再度インポートを試みましょう。 - インポート後のテーブル確認
– 左ペインで各テーブルを開き、件数がバックアップ時と同一か比較。特にwp_posts、wp_options、wp_usersのレコード件数を確認します。
– サイトURLやパスワードリセット用メールテンプレートなど、wp_options内の重要設定が意図した値か再度チェック。
4. WP‑Config設定：再設定とセキュリティ強化
結論：wp‑config.phpのデータベース接続情報とセキュリティキーを正確に設定し、不要な情報は削除してセキュリティ強化を図ります。
wp‑config.phpはWordPressサイトの心臓部です。データベース接続情報の誤設定や平文のままセキュリティキーを放置すると、不正アクセスや情報漏えいのリスクが高まります。復元後は必ず見直し、最新の設定に更新しましょう。
理由：不適切な設定は脆弱性につながり、サイト全体の安全性を損なう
復元前の古いwp‑config.phpには、テスト環境専用の設定や開発用デバッグモードが含まれている場合があります。これを本番環境にそのまま適用すると、不必要なデバッグ情報が公開されたり、無効なキャッシュ設定でサイトが遅くなる可能性があります。
具体例：wp‑config.phpで見直す７つのポイント
- データベース接続情報の確認
–DB_NAME、DB_USER、DB_PASSWORD、DB_HOSTを復元先データベース情報に合わせて更新。
– 特にDB_HOSTが“localhost”以外の場合（例：AWS RDSやDocker環境）は必ず修正します。 - 認証用セキュリティキーの再生成
– WordPress公式のキー生成サービス（https://api.wordpress.org/secret-key/1.1/salt/）から最新の8行をコピーして上書き。
– 古いキーを使い回すと、ユーザーログインセッションが不正利用されるリスクがあります。 - デバッグモードの無効化
–define('WP_DEBUG', true);があればfalseに切り替え、エラー表示を非公開にします。
– **デバッグログ**（WP_DEBUG_LOG）も本番では無効化しましょう。 - メモリ制限と自動アップデート設定
– 必要に応じてdefine('WP_MEMORY_LIMIT', '256M');を設定し、大規模サイトでも安定動作を確保。
– 自動更新を制御する場合はdefine('WP_AUTO_UPDATE_CORE', false);でコア更新のみ停止できます。 - キャッシュ設定の確認
– オブジェクトキャッシュやOPcache用の定義がある場合は、環境に合致しているか確認。
– 不要なキャッシュプラグインとの競合を防ぐため、WP_CACHE定義の有無をチェック。 - データベーステーブルプレフィックスの見直し
– セキュリティ強化用に$table_prefixを推奨のwp_以外に変更している場合、SQLインポート時に同じプレフィックスに揃える必要があります。 - 不要な設定項目の削除
– 開発用の定義（例：define('SAVEQUERIES', true);、define('JETPACK_DEV_DEBUG', true);）は削除。
– コメントアウトされた古い設定も整理し、ファイルを見やすく保つことでヒューマンエラーを防ぎます。
5. 動作確認：必須チェックリストとトラブルシューティング
結論：復元後はパーマリンク設定やプラグインの再有効化などを含むチェックリストを一つずつ実行し、サイト全体の正常動作を確認します。
バックアップからの復元が完了しても細かな設定漏れやキャッシュ残存で思わぬ不具合が起こるため、チェック項目を順番に検証しましょう。
理由：復元後の微調整不足でユーザー体験低下やSEO順位変動のリスク
復元直後は見た目や機能が正しく動作していても、URL構造のズレやキャッシュされた古いリソースによって、リンク切れやデザイン崩れ、ページ速度低下が発生します。これに気づかず運用を再開すると、訪問者離脱や検索エンジンからの評価低下を招く恐れがあります。
具体例：動作確認チェックリスト
- パーマリンク再設定
– 管理画面の「設定＞パーマリンク」を開き、変更不要でも「変更を保存」をクリックして内部リライトルールを再生成。 - キャッシュクリア
– キャッシュプラグイン（W3 Total Cache、WP Super Cache等）がある場合、全キャッシュをクリア。ブラウザ側キャッシュも合わせてリフレッシュ。 - プラグイン再有効化と動作確認
– 全プラグインを一旦無効化し、1つずつ有効化しながら機能テスト。フォーム送信、SNS連携、Eコマースカートなど主要機能を順にチェック。 - テーマファイルの動作チェック
– カスタムテンプレートやウィジェットが正しく表示されているか確認。子テーマを使用している場合は、親テーマも更新忘れがないかチェック。 - 404エラーページの確認
– 存在しないURLにアクセスし、カスタム404ページが正しく表示されるかテスト。 - サイト速度計測
– Google PageSpeed InsightsやGTmetrixで復元前後のスコアを比較し、目立った速度低下がないか確認。 - SSL証明書とHTTPSリダイレクト
– 管理画面のサイトアドレスがHTTPSになっているか、.htaccessでHTTPSへの強制リダイレクトが機能しているかテスト。
6. テスト復元：ステージング環境での試験復元方法
結論：本番環境へ適用前に、ステージング環境で復元手順を再現し、問題点を洗い出して修正します。
ステージング環境は本番サイトへの影響を避けつつ、実際の復元作業手順を検証できる場です。ここでのテストが、万全な本番復元の鍵となります。
理由：リスクの低い環境で手順を確認することで、想定外のエラーを事前に潰せる
初回の復元作業で予期しない問題（ファイル転送中のタイムアウト、SQLインポートエラー、テーマの互換性問題など）が起こっても、ステージング環境ならサイトダウンを恐れず何度でも再試行できます。
具体例：ステージング環境でのテスト復元手順
- ステージングURLのアクセス確認
– パスワード保護またはBasic認証を設定し、無関係な訪問者がアクセスできないようにします。 - ステップ1～4の作業フローをそのまま実行
– 事前準備→ファイル復元→DB復元→WP‑Config設定→動作確認を全て再現。各ステップで掛かった時間や発生したエラーを記録。 - 復元後の最終チェック
– 前章の動作確認チェックリストを適用。特にメディア表示やフォーム、決済機能など、クリティカルな機能を重点的にテスト。 - テスト結果のまとめと手順書の更新
– 発生したトラブルと対処法をドキュメント化し、手順書に反映。手順書は本番環境での復元時に参照できるようサーバー上に配置しておくと安心です。
7. 今後の対策：バックアップ計画と専門家活用のすすめ
結論：定期的な自動バックアップと専門家への相談窓口を設けることで、次回以降のトラブルを未然に防ぎます。
復元作業の大変さを経験したら、バックアップ計画の見直しと専門業者への定期相談を取り入れ、安心してサイト運営を継続できる体制を整えましょう。
理由：未然にリスク管理を行わないと、致命的トラブルが再発する恐れがある
手動バックアップに頼るとヒューマンエラーが起こりやすく、最新データが取得できない場合があります。自動化と専門家の知見を組み合わせることで、確実かつ迅速なバックアップ・復元体制を構築できます。
具体例：おすすめバックアッププランと専門家活用法
- 自動バックアッププラグインの導入
– UpdraftPlus、BackWPup、WP Time Capsuleなどを導入し、毎日深夜に自動バックアップ。クラウドストレージ（Dropbox、Google Drive、AWS S3など）への二重保存を推奨。 - バックアップ保管ポリシーの設定
– 過去30日分を保持し、週単位のバックアップは90日分、月単位は1年間保管する**多層バックアップ**を実施。 - 定期的な復元テスト
– 半年に一度はステージング環境でリストアテストを実施し、プラグインやサーバー環境のアップデートによる不整合を早期に発見。 - 専門業者への相談窓口設置
– 重要サイトならば、契約ベースでのサポートプランや障害時優先対応を行う業者と連携。緊急時の対応フローを明示化しておくと安心です。
まとめ
WordPressサイトの復元は
1. 事前準備（ステージング環境構築、メンテナンスモード）
2. ファイル復元（FTPアップロード）
3. データベース復元（phpMyAdminインポート）
4. wp‑config再設定（接続情報・セキュリティキー）
5. 動作確認（パーマリンク・キャッシュ・プラグイン）
6. テスト復元（ステージングで再検証）
7. 今後対策（自動バックアップ、自動テスト、専門家活用）
の手順を踏むことで、緊急時でも安心して完全復旧が可能です。
今すぐバックアップ体制を見直し、本稿の手順書を保存しておくことを強くおすすめします。
万が一のトラブルに備え、この記事を参考にバックアップ自動化と復元テストを今日から始めましょう。
