会社のWebサイトで表示の不具合が起きたり、更新作業のあとに問い合わせフォームが動かなくなったりしたとき、元の状態に戻すための備えになるのがバックアップです。
ただし、「サーバーが自動で保存している」「バックアップ用のプラグインを入れている」というだけでは、必要なときに復元できるかまでは分かりません。保存されている範囲や日時、復元方法を把握していなければ、トラブルが起きてから調べることになります。
大切なのは、データを保存することに加えて、必要なデータを選び、担当者が手順に沿って復元し、動作を確認できる状態にしておくことです。
この記事では、WordPressで運用する中小企業サイトを想定し、バックアップ頻度、復元手順、トラブル対応、テスト復元の基本を整理します。
バックアップは「何が保存されているか」から確認する
WordPressサイトのバックアップでは、ファイルとデータベースの両方を確認する必要があります。
ファイルには、画像、テーマ、プラグインなどが含まれます。データベースには、記事や固定ページの内容、各種設定などが保存されています。WordPress公式資料でも、サイトのバックアップはこの二つで構成されると説明されています。
画像を保存していても記事のデータがなければ、サイト全体を元どおりに戻せるとは限りません。反対に、データベースだけが残っていても、画像や使用していたテーマなどが不足する場合があります。
まずは、利用しているサーバーやバックアップ機能について、保存対象、保存先、保存期間を確認しましょう。制作会社に管理を依頼している場合も、どこまでが契約に含まれているかを共有しておくことが大切です。
バックアップ頻度は、失って困る情報から決める
記事の更新頻度だけで判断しない
バックアップの間隔を考えるときは、「何日前まで戻っても業務上対応できるか」を基準にします。
たとえば、毎日ブログを更新しているサイトを1週間前の状態へ戻すと、その間に公開した記事や修正内容が失われる可能性があります。注文や予約をサイト内に保存する場合は、記事を更新していなくてもデータが増え続けます。
そのため、ページの更新回数だけでなく、注文、予約、会員登録、フォームの送信記録など、サイト内に何が保存されているかを確認してください。
次の表は、頻度を検討する際の考え方です。一律の推奨間隔ではなく、自社の運用に合わせて判断するための例として使えます。
| サイトの運用 | 頻度を考えるときのポイント |
|---|---|
| 更新が少ない会社案内サイト | 定期保存に加え、ページ修正や設定変更の前にも取得する |
| 記事を頻繁に公開するサイト | 公開・修正した内容をどこまで失ってよいかに合わせて間隔を決める |
| 注文や予約を保存するサイト | 営業時間中に増えるデータを考慮し、より短い間隔での保存を検討する |
| 大きな更新・改修を行うサイト | 作業直前の状態を保存し、通常の定期バックアップと区別して残す |
保存期間と世代数も決める
バックアップは、最新の一つだけでなく、異なる日時のデータを残しておくことも重要です。
問題に気づくまで時間がかかると、直近のバックアップにも不具合や改ざんが含まれている可能性があります。過去の状態を選べるよう、どれくらい前までさかのぼれるかを確認しましょう。
また、サイトと同じサーバー内だけに保存する運用では、同時に利用できなくなる場合も考えられます。別の保存先も含め、障害時にバックアップを取り出せるかを確認してください。
保存先へのアクセス権限も整理し、バックアップに含まれる情報を必要な担当者だけが扱える状態にします。
復元手順は、トラブルが起きる前に整理する
誰が、どの方法で戻すかを決める
復元方法は、レンタルサーバーの機能、バックアップ用プラグイン、制作会社の管理方法などによって異なります。
日頃の保存方法に対応した手順を確認し、担当者が見つけられる場所へまとめておきましょう。WordPressの管理画面に入れなくなった場合でも、必要な手順や連絡先を参照できるようにしておきます。
記録したいのは、バックアップの保存先、取得日時の確認方法、復元する対象の選び方、作業担当者、問題が起きた際の問い合わせ先です。パスワードなどの認証情報は、管理表へ直接書かず、社内で決めた方法で別に管理します。
復元すると失われる変更を確認する
過去のバックアップを戻すと、その時点以降に追加・変更した情報が上書きされる可能性があります。
特に、注文や予約を扱うサイトでは注意が必要です。表示を直すために古いデータベースを戻した結果、直近の注文情報まで巻き戻してしまうことがあります。
復元前には、どの日時へ戻すのか、その間に増えたデータをどう扱うのかを確認します。必要に応じて現状のデータを別途保全し、制作会社や保守担当者と復元範囲を決めましょう。
ファイルとデータベースについても、対応するバックアップを一組として管理しておくと、復元対象を確認しやすくなります。WordPress公式資料でも、両者を同じバックアップセットとして保管する方法が案内されています。
トラブル時は、状況を記録してから対応する
サイトに異常が起きたときは、慌てて更新や復元を繰り返す前に、分かっていることを記録します。
いつ気づいたのか、どのページや機能に問題があるのか、直前に何を変更したのかを整理してください。エラー画面や通知メールも、原因を確認する材料になります。
そのうえで、担当者や制作会社、サーバー会社へ連絡します。サイト全体が表示されないのか、フォームだけが動かないのかによって、調べる箇所や対応は変わります。
バックアップからの復元が必要かどうかも、この段階で判断します。サーバー側の障害など、サイトデータを戻しても解消しない問題もあるためです。
また、不正アクセスや改ざんが疑われる場合は、古いデータへ戻すだけで対応を終えないようにします。復元元の安全性と、侵入原因への対応を担当者と確認し、同じ問題が再発しないように進めましょう。
テスト復元で、手順とデータを確かめる
本番サイトとは別の環境で試す
テスト復元とは、保存したバックアップを使い、実際にサイトを戻せるかを確認する作業です。
本番サイトへ影響を与えないよう、別のテスト環境で行う方法を検討しましょう。バックアップの導入時や保存方法の変更後などに実施し、その後もサイトの重要度に応じて確認の機会を設けます。
テスト環境でも、復元したサイトがメールを送ったり、外部サービスへ接続したりする可能性があります。作業前に、外部への送信や決済が発生しない設定、関係者以外がアクセスできない設定を担当者と確認してください。
表示だけでなく、業務で使う機能まで確認する
トップページが開けただけでは、復元確認は完了しません。
記事や画像が表示されるか、管理画面へログインできるか、主要ページのリンクが正しいかを確認します。問い合わせフォームや予約機能がある場合は、テスト用の送信先や設定で動作を確かめます。
確認対象は、実際に業務で使っている機能から決めましょう。会社案内サイトとECサイトでは、復元後に確認すべき内容も異なります。
復元にかかった時間と、つまずいた点を残す
テスト復元では、完了したかどうかに加えて、所要時間と問題点を記録します。
バックアップを探すのに時間がかかった、必要な権限がなかった、画像が一部不足していた、といった点も大切な確認結果です。
見つかった問題を手順書へ反映し、担当者が変わっても作業を進められるようにします。復元訓練は、データの確認と同時に、運用の不足を見つける機会になります。
バックアップ管理表で、保存から復元まで共有する
運用状況を把握するために、バックアップ管理表へ次の情報をまとめておきましょう。
| 管理項目 | 記録する内容 |
|---|---|
| 対象サイト・保存範囲 | URL、ファイル、データベース、対象外の情報 |
| 取得方法・頻度 | 使用する機能、取得間隔、更新前の取得ルール |
| 保存先・保存期間 | 保存場所、世代数、いつまで戻せるか |
| 取得結果 | 直近の成功日時、失敗時の通知先と対応担当 |
| 復元手順・連絡先 | 手順書の場所、作業担当、外部の問い合わせ先 |
| テスト復元の記録 | 実施日、使用データ、所要時間、動作確認結果 |
| 改善事項 | 修正が必要な点、担当者、対応期限、次回確認日 |
設定している内容だけでなく、実際に取得が成功したか、復元を試したかまで残すのがポイントです。
まとめ｜保存できていることと、戻せることを確認する
バックアップは、サイトの更新内容や業務への影響に合わせて頻度を決め、必要な範囲を保存することから始まります。
そのうえで、復元方法と担当者を明確にし、過去へ戻すことで失われる情報を確認します。別の環境でテスト復元を行い、表示と主要機能を確かめておけば、手順や保存内容の不足も見つけられます。
まずは、最後にバックアップが成功した日時と、そのデータを使った復元方法を確認してみましょう。
「バックアップ管理表」を活用し、取得頻度・保存先・復元担当・テスト復元の結果を整理しましょう。
