WordPress更新前のバックアップと復元|宿のサイトを戻せる状態にする

宿主と担当者がWordPressのファイルとデータベースを一組で別保存しテスト環境へ復元して確認するイラスト WordPress入門

WordPressの更新前に「バックアップを取りました」と言われても、それだけでは安全とは限りません。ファイルしかない、データベースが古い、保存先が本番サーバーと同じ、復元方法を誰も知らないという状態では、障害時に戻せないことがあります。

宿のサイトで必要なのは、次の状態です。

同じ時点のファイルとデータベースを一組で保管し、どこへどう復元するか分かり、復元後の確認項目が決まっている。

この記事では、バックアップの取得方法を一つに限定せず、レンタルサーバー、バックアッププラグイン、制作会社の運用に共通する確認方法を説明します。

バックアップには二つの主要部分がある

1. WordPressのファイル

  • テーマ
  • プラグイン
  • アップロード画像・PDF
  • wp-config.php
  • .htaccess などの設定ファイル
  • WordPress本体のファイル

2. データベース

  • 投稿、固定ページ、コメント
  • WordPressの設定
  • ユーザー情報
  • メニューやウィジェット設定
  • 多くのプラグインが保存する設定・データ

WordPress公式のデータベースバックアップ資料も、データベースの書き出しにはテーマ、プラグイン、アップロード、wp-config.php などのファイルが含まれないと説明しています。

ファイルだけ、データベースだけを保存する場合もありますが、WordPress全体を戻す更新前バックアップでは、原則として両方を保存します。

外部サービスはWordPressへ含まれない

次のデータは、WordPressの外にある場合があります。

  • OTAの予約
  • 外部予約システムの在庫・宿泊者情報
  • Stripe・Squareなどの決済
  • Google Analytics・Search Console
  • 外部メールサービスのメールボックス
  • DNS・ドメイン契約
  • SNSや地図の情報

WordPressを復元しても、これらが過去へ戻るとは限りません。反対に、WordPressだけ過去へ戻すと、外部予約・決済との状態がずれる可能性があります。

「復元点」を一組で管理する

バックアップには、次の情報を添えます。

項目 記録例
取得日時 2026年8月16日 10:00 JST
対象サイト 公式サイトのドメイン
対象フォルダ WordPress設置先
データベース 対象名を安全な管理表へ記録
ファイル 完了・容量
データベース 完了・容量
取得理由 プラグイン更新前
保存先 サーバー外の保管場所
検証 読み取り・チェックサム・復元テスト
担当者 取得者・確認者

ファイルとデータベースの時刻が大きく違うと、画像はあるのに記事に表示されない、設定とプラグインの版が合わない、といった不整合が起こり得ます。

よくある三つの取得方法

レンタルサーバーのバックアップ

管理画面からファイルとデータベースを保存・復元します。操作が分かりやすい一方、プランによって保持期間、復元料金、対象、別保存の可否が違います。

ロリポップの公式マニュアルでも、Webサイトとデータベースを分けて復元します。対象と復元日時を間違えないようにします。

WordPressバックアッププラグイン

管理画面から定期取得や外部保存を設定できます。ただし、サイトが開けない障害ではWordPress管理画面へ入れず、同じプラグインだけでは復元できない場合があります。

確認することは次のとおりです。

  • WordPressに入れない状態でも復元できるか
  • 保存先の認証情報を誰が管理するか
  • 大容量サイトで処理が途中終了しないか
  • バックアップ自体が公開URLから読めないか
  • プラグインの契約終了後も取り出せるか

制作・保守会社によるバックアップ

「保守に含まれる」だけでなく、取得頻度、保持期間、復元目標時間、追加料金、契約終了時の引き渡しを確認します。宿側でも、緊急連絡先と直近の成功日時を把握します。

サーバー内だけに置かない

同じサーバー内の別フォルダへコピーしただけでは、サーバー障害、契約停止、侵害、容量不足の影響を同時に受けます。

バックアップは、少なくとも一つを本番サーバーとは別の信頼できる場所へ置きます。

  • サーバー会社とは別のクラウドストレージ
  • アクセス制限された事業用ストレージ
  • 暗号化した外部媒体
  • 保守会社の分離されたバックアップ基盤

WordPress公式のセキュリティ資料も、WordPress全体とデータベースの定期スナップショットを信頼できる場所へ置く考え方を示しています。

バックアップの公開事故を防ぐ

SQL、ZIP、tarなどのバックアップをWeb公開フォルダへ置くと、URLを知られた場合に取得される危険があります。バックアップには個人情報、メールアドレス、パスワードハッシュ、設定、秘密情報が含まれる可能性があります。

  • Webから直接取得できる場所へ置かない
  • 保存先の共有範囲を限定する
  • 必要に応じて暗号化する
  • 復号鍵をバックアップと同じ場所へ置かない
  • ダウンロード履歴・操作履歴を確認できるようにする
  • 不要になった古いバックアップを安全に削除する

バックアップのURL、パスワード、復号鍵をAIチャットへ貼らないでください。

取得成功をどう確認するか

「完了」というメールだけでなく、次を確認します。

  • エラーで終了していない
  • ファイル容量が0や極端に小さくない
  • データベースファイルが存在する
  • 取得日時が更新作業の直前
  • 対象ドメインとフォルダが正しい
  • 保存先から実際に読み取れる
  • ハッシュ値・チェックサムがある場合は一致する

定期バックアップは、最後に成功した日時を毎月確認します。容量不足や認証切れで、数か月前から失敗していることがあります。

復元テストを行う

バックアップが使えるかを最も確実に確認する方法は、本番と分離したテスト環境へ復元することです。

  1. テスト用のドメイン・フォルダ・データベースを用意
  2. 検索エンジンと一般利用者から遮断
  3. ファイルを復元
  4. データベースを復元
  5. テスト用URLへ安全に変更
  6. 管理画面へログイン
  7. トップ、記事、画像、メニューを確認
  8. 予約・問い合わせは本番へ送らない設定で確認
  9. 個人情報の保護を確認
  10. 結果と所要時間を記録

テスト環境から宿泊者へメールを送ったり、外部予約在庫や本番決済を操作したりしないようにします。

技術担当者がいない場合は、サーバー会社や制作会社へ「本番を上書きせず、別の場所へ復元確認できますか」と依頼します。

本番復元の前に止まる

本番復元は、既存データを過去の状態で上書きする可能性がある重要操作です。焦って実行せず、まず次を判断します。

  • 公開画面だけの不具合か
  • 管理画面へ入れるか
  • 直前のプラグインだけ戻せるか
  • ファイルだけ戻せば直るか
  • データベースまで戻す必要があるか
  • バックアップ後に新しい予約・問い合わせ・記事があるか
  • 外部決済・OTAとの状態がずれないか

データベース復元は、バックアップ後に入った情報を消す可能性があります。復元前に現在のデータも緊急退避し、差分を記録します。

復元の基本順序

実際の操作はサーバー会社の手順を優先します。一般的な判断順序は次のとおりです。

  1. 新しい更新・投稿・予約受付を一時停止する
  2. 障害時刻と症状を記録する
  3. 現在状態を緊急バックアップする
  4. 復元対象と復元点を二人で確認する
  5. バックアップ後の予約・問い合わせを別記録する
  6. ファイル・データベースの必要な範囲を復元する
  7. キャッシュを削除する
  8. 管理画面と公開画面を確認する
  9. 予約、フォーム、メールを確認する
  10. 差分を安全に再入力・照合する
  11. 販売・更新を再開する

「すべてを戻す」より、原因となった一部分だけを安全に戻せる場合があります。判断できない場合は、全復元を実行せず保守担当へ連絡します。

復元後の確認表

WordPress

  • [ ] トップ・客室・料金・アクセスが表示される
  • [ ] 画像とPDFが表示される
  • [ ] メニューと内部リンクが動く
  • [ ] 管理画面へログインできる
  • [ ] 記事を下書き保存できる
  • [ ] SSL警告、404、PHPエラーがない

予約・問い合わせ

  • [ ] 予約ボタンが正しい外部ページへ進む
  • [ ] WordPress内予約の在庫が外部と一致する
  • [ ] 問い合わせフォームが動く
  • [ ] 宿側通知と自動返信が届く
  • [ ] 復元中に届いた予約・取消・変更を反映した

安全性

  • [ ] テスト環境が検索公開されていない
  • [ ] バックアップファイルがWeb公開されていない
  • [ ] 復元用の一時アカウントを停止した
  • [ ] キャッシュや一時ファイルを確認した
  • [ ] 復元日時、担当者、結果を記録した

保持期間は更新頻度で決める

一つの最新版だけを上書きし続けると、侵害や不具合に気づいた時点で正常な版が残っていないことがあります。

小さな宿でも、用途を分けて保持します。

  • 更新直前の手動バックアップ
  • 毎日の自動バックアップ
  • 週・月単位の長期バックアップ
  • 大幅なデザイン変更前の保管版

必要期間は記事更新、予約データの保存場所、保守契約、個人情報方針で決めます。不要な個人情報を無期限に持ち続けないことも重要です。

AIへ確認を頼むプロンプト

宿のWordPress更新前バックアップを確認してください。
まだ取得、復元、削除、本番変更は実行しないでください。

読み取りだけで次を整理してください。
- WordPressの設置場所
- 対象データベース
- ファイルとデータベースの取得方法
- 外部予約、決済、メールなど含まれないデータ
- 現在の保存先、保持期間、最終成功日時
- 本番と別の保存先があるか
- 復元方法と必要時間
- 復元で失われる可能性がある新しいデータ
- 本番を上書きしない復元テスト案

秘密情報、顧客情報、バックアップの中身は表示しないでください。
不明な点は推測せず、サーバー会社への質問にしてください。

AIには最初から本番復元を許可せず、対象、復元点、差分、確認方法を人が承認してから進めます。

バックアップ管理表

日時 理由 ファイル DB 別保存 検証 復元テスト 担当
更新前

パスワードや暗号鍵をこの表へ直接書かず、安全なパスワード管理手段を使います。

まとめ

  • ファイルとデータベースを同じ復元点として一組にする
  • 外部予約・決済・メールは別物として確認する
  • 少なくとも一つを本番サーバー外へ保存する
  • 完了メールだけでなく容量・日時・対象・読み取りを確認する
  • 本番と分離した場所へ復元テストする
  • 本番復元前に、バックアップ後の予約と問い合わせを退避する
  • 復元後は表示だけでなく予約・フォーム・メールを確認する

レンタルサーバーでWordPressを安全に更新する方法と組み合わせ、バックアップ、更新、確認、復元を一つの手順書にしてください。

参考資料

※バックアップ対象、保存期間、復元料金、操作画面はサービスと契約プランで異なります。必ず契約先の最新マニュアルを確認してください。

タイトルとURLをコピーしました