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

バックアップは、保存できている表示ではなく復元できた結果で評価します。毎日自動取得されていても、必要なファイルが対象外になる場合があります。戻し方が分からなければ、障害時にサイトを再開できません。

設定を始める前に、どこまでのデータ消失を許容し、何時間で戻したいかを決めます。この二つが取得間隔、保存先、復元方法を選ぶ基準になります。

失ってよい時間から取得間隔を決める

会社案内の更新が月に一度なら、短時間ごとのデータベース保存は過剰かもしれません。注文や予約が連続して入るサイトでは、一日前の状態へ戻すと多くの受付を失います。更新頻度と業務影響から、許容できるデータ損失の時間を決めます。

自動取得の実行時刻も確認します。アクセスや定期処理と重なると負荷が増える場合があります。成功通知だけでなく失敗通知を受け取り、保存件数が突然減っていないかを見ます。時刻は担当者が調査しやすい形で記録します。

変更の多い時間帯が分かるなら、取得間隔を一日均一にする必要はありません。更新作業の直前にも手動で世代を作り、作業名と結び付けておくと戻す時点を選びやすくなります。

WordPressでは、テーマ・プラグイン・画像などのファイルと、記事・設定・利用者情報を持つデータベースが分かれています。完全な復元には両方が必要です。近い時点の組として識別できる名前を付けます。

更新中に別々の時刻で取得すると、ファイルとデータベースの状態が合わない場合があります。バックアップ中に書き込みを止める必要があるかを確認します。注文サイトでは、取得後に成立した取引を復元時にどう照合するかも決めます。

バックアップセットには取得時刻とサイト識別子を付けます。複数サイトを同じ契約で管理する場合は、別サイトのデータを誤って戻さないように対象ドメインも記録します。

サーバー会社の自動バックアップは便利ですが、契約停止やアカウント侵害のときに同時に使えなくなる可能性があります。自社が管理する別の保存先へ、必要な復元セットを定期的に複製します。閲覧権限は復元担当者へ限定します。

複製先にも保存期間と削除手順が必要です。問い合わせや会員情報を含むバックアップは、古いデータを長く残すほど安全になるとは限りません。暗号化・保管地域・委託先・契約終了時の削除を社内ルールと合わせます。

外部保存先のアカウントも会社名義で管理します。サーバーと同じパスワードを使わず、削除権限を持つ人を限定します。保管先自体の障害時に取り出せる方法も確認します。

障害が起きたら、すぐ古い状態へ上書きせず、現在のファイル・データベース・ログを保全します。不正アクセスが疑われる場合は、原因を残したまま戻す危険があります。まず書き込みを止め、影響を受けた範囲と復元時点を決めます。

復元すると消えるデータを利用部門と確認します。注文・問い合わせ・記事更新など復元時点より後の記録を別に退避し、復旧後に照合します。サーバー全体を戻すか、一つのサイトだけを戻すかも事前に選べるようにします。

攻撃が原因なら、侵入前と判断できる世代を選ぶ必要があります。最新だから安全とは限りません。原因のプラグインや認証情報を修正してから公開を再開します。

復元セットを検証環境へ展開し、トップページだけでなく管理画面と書き込み処理を確認します。データベース接続情報やドメインが本番と違う場合は、設定を調整します。マルウェアや不要な管理者が戻っていないことも見ます。

本番復元後は、DNS・HTTPS・フォーム通知・定期処理・監視を順に確認します。再開時刻と利用者への告知も記録します。復元にかかった実時間が目標を超えたなら、次回までに手順や保存方法を変えます。

本番への反映中は、複数の担当者が別々の変更をしないようにします。作業責任者が開始と終了を宣言し、業務担当者が受付件数を照合した時点で書き込みを再開します。

バックアップ設定は、担当者やサーバー構成が変わると古くなります。定期的に一つの復元セットを選び、別環境で最後まで戻します。管理画面へログインできただけで終えず、業務機能を担当部門と確認します。

試験記録には、使用した世代・所要時間・迷った手順・失われる差分を残します。復元できなかった原因は取得設定へ戻して直します。この循環があって初めて、バックアップは障害時に使える仕組みになります。

試験は同じ詳しい担当者だけで行いません。手順書を見た代理者が連絡と復元を進められるかを確認します。認証情報や問い合わせ先の古さも同時に見つけられます。