レンタルサーバーのバックアップ設定と復元手順

レンタルサーバーの自動バックアップは、有効になっているだけでは復旧の準備が終わりません。必要なデータがそろい、別の場所へ取り出せて、戻した後の動作を確認できる状態にしておきます。特にWordPressは、ファイルだけでなくデータベースも必要です。

設定は、保存する対象を選び、取得を有効にし、成功した履歴を見る流れです。復元は、戻す日時と範囲を選び、現在のデータを退避してから行います。操作画面はサービスによって異なりますが、この二つを分けると手順を追いやすくなります。

初めてバックアップを設定するとき

契約した時点から自動取得されるサービスと、自分で有効にするサービスがあります。管理画面のバックアップ欄で対象サイトを選び、取得日時の一覧があるかを見ると、設定だけでなく保存の実績も分かります。

自分で設定する方式では、Webファイルとデータベースを対象にし、取得頻度と保存先を指定します。その後に手動実行または次の予定取得を待ち、成功履歴と保存データを確認します。メールが対象外なら、メールの保存は別に必要です。

プラグインを使う場合も、保存先が同じサーバー内だけだと、サーバーへ入れないときに取り出せないことがあります。暗号化や認証情報を含む保存データは、公開フォルダへ置かないでください。復元機能の有無と、データをダウンロードする方法も保存方法と一緒に扱います。

管理画面で取得対象と保存条件を照合する

まず契約中のプランのマニュアルと、実際のバックアップ一覧を並べます。設定が有効でも、容量超過や除外設定によって必要なデータが保存されていない場合があります。

確認結果を残すときは、次の五つを別々に照合すると漏れを見つけやすくなります。表の「不足時の対応」は、標準機能で対応できると決めつけずに確認するためのものです。

WordPressのファイルには、テーマやプラグインのほか、アップロードした画像や設定ファイルが含まれます。一方、記事本文や設定の多くはDBにあるため、WebのフォルダをダウンロードしてもDBが一緒に取得できたとは限りません。WordPress公式のバックアップ説明でも、完全な復元に両方が必要とされています。

二つの取得時刻が近くても、その間に書き込みがあれば状態がずれる可能性があります。更新を止められるサイトでは、担当者の作業と自動処理を止めた時間に取得します。注文が入り続けるサイトでは、単に短い間隔で保存するだけでなく、整合性を保つ取得方法を保守担当者へ確認してください。

取得した組には、対象ドメインとDB名、取得日時を対応付けて記録します。メールや外部サービスに保存された注文は別の管理対象なので、同じ組に入っているかを推測しません。初回設定後は実際の成功履歴を確認し、失敗通知がある機能では会社が受け取れる宛先に設定します。

取得間隔と保存期間の考え方

取得間隔は、失ってよいデータの量から決めます。「どこまで過去へ戻ってよいか」と「何時間以内に業務を再開したいか」は、別の目標です。

例えば、毎日2時に取得し、16時に障害が起きたとします。2時の状態へ戻すと、その間の14時間分の変更が失われる可能性があります。これは説明のための仮例であり、実際には最後に成功した取得時刻と保存対象を確認して判断します。

会社案内の修正なら原稿からやり直せる場合がありますが、注文や予約は顧客との照合が必要です。失ってよい時間を1時間以内と決めた業務に、一日一回のバックアップだけでは足りません。取得間隔を短くするか、注文の保存先や復旧方法そのものを見直します。この許容損失の目標をRPOと呼びます。

復旧に使える時間の目標はRTOです。バックアップを戻す操作が短くても、窓口の応答待ちやデータのダウンロードに時間がかかれば再開は遅れます。復元後の業務確認まで含めて測り、目標に入るかを試験で確かめます。

保存期間は、異常に気づくまでの時間も考えて決めます。古い改ざんを発見したとき、すべての世代が改ざん後であれば正常な状態を選べません。「何世代」と「何日前まで」は同じではないため、管理画面に残る取得日時で確認します。

別保存は削除権限まで分ける

同じサーバー内の別フォルダへコピーしても、契約停止や管理アカウントの侵害に一緒に巻き込まれる可能性があります。別保存では、場所とアクセス権限の両方を分けて考えます。

自社で管理する保存先へ必要な世代を取り出し、サーバーのログイン情報だけでは削除できない構成にします。本番の削除を即座に複製先へ反映する同期だけでは、誤削除も広がります。過去の世代を残せるか、通常の作業アカウントがその履歴を消せないかを確かめます。

オフライン保管や、一定期間の上書き・削除を制限する仕組みも候補です。CISAのランサムウェア対策ガイドは、オフラインで暗号化したバックアップと定期的な復元確認を勧めています。レンタルサーバーでは契約者が変更できない部分もあるので、標準機能の外へ何を複製するか決めます。

暗号化したデータには、復号するための鍵や回復手段も必要です。それらが使えなくなったサーバーにしかなければ取り出せません。保存先の容量や契約更新と合わせ、代理の担当者でも復元に必要な権限へ到達できるか確認します。個人情報を含む世代は無期限に増やさず、会社の保管・削除方針に合わせます。

復元前に現在のデータと戻す範囲を確定する

障害時は、古い世代をすぐ本番へ上書きしないでください。復元時点より後の業務データを残せるか、影響を受けた範囲と一緒に確認する必要があります。

まず社内の作業責任者を決め、別の担当者が同時に更新や復元をしないようにします。書き込みを止める必要がある場合は、通常の画面操作だけでなく外部からの受付や定期処理も対象です。代替の受付方法を利用部門と決めてから停止します。

保守担当者と現在のファイル・DB・ログを安全に保全し、最後に正常だった時点を特定します。例えばテーマの変更だけが原因なら、注文DBまで過去へ戻す必要があるとは限りません。ただしプラグイン更新でDB構造も変わった場合は、ファイルだけ戻すと不整合になることがあります。変更内容から復元単位を選びます。

不正アクセスが疑われる場合は、単なる更新失敗と分けて対応します。障害に気づく前から侵入されている可能性があるため、直前の世代が安全とは限りません。原因調査や証拠保全の判断ができないときは、上書きを進めずサーバー会社や対応できる専門家へ相談してください。

復元すると失われる差分は、業務側の記録と照合できる形で退避します。決済サービスの取引記録とサイトの注文記録は別なので、DBを戻せば決済まで取り消されるわけではありません。差分を機械的に再登録する前に、二重注文や重複処理を起こさない確認方法を決めます。

外部へ送信しない環境で復元を試す

最初の復元試験は、本番を上書きしない別環境で行います。本番データをコピーした検証先から通知や決済が実行されないよう、動作確認より先に外部連携を止めます。

Basic認証などの閲覧制限だけでは、プログラムからの外向き通信を止められません。メールは試験用の受け取り先へ向け、決済は本番キーを使わない構成にします。定期処理やWebhookも、本番の相手先へ通知しないことを確認します。利用者情報を持つ複製にはアクセス制限を付け、検索に出さない設定も合わせます。

試験は次の順に進めます。契約環境ごとの操作はマニュアルに従い、同じ画面名や復元方式をすべてのサーバーへ当てはめないようにします。

1. 本番と別の復元先を用意し、アクセス制限と外部送信の抑止を確認する。
2. 対象ドメインと取得日時を照合してファイルを戻し、起動前にDB接続とURLを検証用へ切り替える。
3. 復元先が検証用DBであることを確認して対応するDBを戻し、表示・ログイン・試験データの保存を調べる。
4. 結果と所要時間を記録し、失敗があれば本番へ進む前に取得設定や手順を直す。

本番の接続情報が入った設定ファイルを戻した直後は、まだアプリを動かしません。検証用DBにしか接続できない権限を用意し、インポート先とアプリの接続先の両方を照合します。DB内に本番URLが保存される場合もあるので、復元後に検証用へ調整してから表示を確認します。

確認するのはトップページだけではありません。代表的な下層ページで画像を開き、業務で使うフォームが試験用の通知先へ届くところまで確認します。DB単体の手順はMySQLのバックアップと復元、別URLへの展開はWordPress移転時の確認も参照できます。

ファイルのダウンロード成功やチェックサムの一致は、転送の確認には役立ちますが、サイト全体が正常に動く証明にはなりません。試験で使った世代と動作結果を結び付けて残します。不正アクセス後の復元なら、脆弱性や認証情報への対処も済ませてから本番再開を判断します。

本番再開は業務データの照合後に判断する

復元処理が完了しても、すぐ受付を再開せず利用部門の確認を挟みます。作業責任者が技術面と業務データの両方を確認し、再開時刻を決めます。

本番ではHTTPSと主要画面の表示を確認し、退避した注文や問い合わせを復元後の記録と照合します。検証用に止めていた通知や定期処理は、重複実行の影響を確かめてから必要なものを戻します。同じサーバーへ戻しただけならDNSを変更するとは限りません。接続先を変える復旧の場合だけ、DNSの切り替えも作業に含めます。

再開後は、新しい受付が正常に保存されるかとエラーログを確認します。不足や重複が残る場合は、受付範囲を限定するか再開を待つ判断も必要です。判断者と未解決事項を記録し、必要に応じて利用者へ案内します。

バックアップが役立つのは、戻したい時点のデータがあり、そのデータで必要な動作を再開できるときです。ファイルの誤削除と注文DBの障害では戻す範囲が違います。すべてを古い状態へ戻すのではなく、原因と失われる差分に合わせて復元することが、二次的な損失を減らします。