「バックアップは取っています」——サイトの保守についてお話しすると、ほとんどの方がこう答えます。しかし実際に障害が起きたとき、取っていたはずのバックアップから戻せなかったという事態は珍しくありません。今回は、なぜそうなるのか、そして何を確認しておけばよいのかを整理します。
「取れている」と「戻せる」は別の話
バックアップには、実は3つの段階があります。
- 取得できている
- 保存されている
- そこから復元できる
多くの現場で確認されているのは1番だけです。管理画面に「バックアップ完了」と表示されていれば安心してしまう。しかし障害時に必要なのは3番であり、復元を一度も試したことがないバックアップは、存在しないのとほとんど同じです。
バックアップの価値は、取った回数ではなく、戻せた回数で決まる。
実際に起きた失敗のパターン
現場で聞く典型的なつまずきを挙げます。
データベースが含まれていなかった
WordPressのようなCMSは、ファイルとデータベースの両方がそろって初めて元に戻ります。ファイルだけコピーしていて、記事の中身が入っているデータベースが取れていなかった、というケースです。
同じサーバーの中にしか置いていなかった
サーバー内のフォルダにバックアップを保存していたものの、サーバー自体の障害やアカウント停止で、本体と一緒にバックアップも失われたという例です。
世代が1つしかなかった
上書き保存型で、直近の1世代しか残していないパターン。改ざんや不具合に気づくのが数日後だと、壊れた状態のデータで上書きされていることがあります。
復元に必要な情報が分からなかった
データは残っていたものの、サーバーの管理画面へのログイン情報、データベースの接続情報、ドメインの管理会社が分からず、作業に入れなかったケース。担当者の退職後に多く発生します。
3-2-1ルールという目安
バックアップの世界には、古くから使われている目安があります。
| 数字 | 意味 |
|---|---|
| 3 | データを3つ持つ（本番＋バックアップ2つ） |
| 2 | 2種類の異なる媒体や場所に保存する |
| 1 | そのうち1つは別の場所に離して置く |
中小企業のサイトであれば、サーバーの自動バックアップ＋外部ストレージへの保存という組み合わせで、実質的にこの条件を満たせます。完璧を目指すより、「本体と同じ場所にしか無い」状態を解消することが先決です。
頻度と保存期間の決め方
頻度は更新の多さで決めます。
- ほとんど更新しない会社案内サイト：週1回
- 月に数回コラムを更新する：週1回＋更新作業の直前に手動で1回
- 毎日更新がある、受注データが入る：毎日
保存期間は最低でも30日を推奨します。理由は、改ざんや不具合に気づくまでに時間がかかるためです。1週間しか残していないと、気づいたときには正常な状態のデータが消えています。
保存先は「解約したら消える」ことに注意
外部ストレージに保存している場合、その契約が切れれば当然データも消えます。クラウドストレージの無料枠を使っているケースでは、容量超過で古い世代から自動削除されることもあります。
保存先の契約状況と残容量も、年に一度の確認項目に入れておいてください。
復元テストのやり方
最も重要で、最も実施されていないのがこれです。年に1回でよいので、次の手順を試してください。
- 本番とは別の場所（テスト用の領域やローカル環境）を用意する
- バックアップから、ファイルとデータベースの両方を戻す
- トップページ、問い合わせフォーム、管理画面のログインが動くか確認する
- かかった時間を記録する
- 手順書として書き残す
4番の時間が重要です。「半日で戻せる」と分かっていれば、障害時に落ち着いて判断できます。逆に復旧に何日かかるか分からない状態では、取引先への説明もできません。
手順書に書いておくべきこと
復旧作業は、平常時とは違う精神状態で行います。記憶に頼らず、次の情報を1枚にまとめておきます。
- ドメインの管理会社と、管理画面のURL
- サーバー会社と契約プラン、管理画面のURL
- バックアップの保存場所と、取得の仕組み
- サイトの構成（CMSの種類、使用しているプラグイン）
- 復元の手順と、想定所要時間
- 制作会社・保守業者の連絡先
この情報は、サイトが落ちている状態でも見られる場所に保管してください。サイト内やサーバー上にだけ置いていると、いざというときに参照できません。
バックアップでは守れないもの
見落とされやすいのですが、サイトのバックアップを取っていても、それだけでは元に戻らないものがあります。
- ドメイン：失効すると、データが無事でもサイトは表示されません
- メール：サーバーに残したままの受信メールは、サーバー障害で消えます
- 外部サービスの設定：解析タグ、広告アカウント、地図の埋め込み設定など
- SSL証明書：再取得が必要になる場合があります
特にドメインとメールは、サイト本体より復旧が難しい領域です。詳しくはSSL・ドメインの更新忘れで実際に起きることで扱っています。
改ざんされた場合は、戻す前に保全する
バックアップから戻す作業は有効ですが、改ざんが疑われる場合は順番が変わります。
慌てて上書き復元してしまうと、侵入の痕跡ごと消えてしまい、原因が分からないまま同じ経路で再び侵入されます。手順としては次のとおりです。
- サイトを一時的に非公開にする
- 現状のファイルとデータベースを、そのまま別途保存する
- その後でバックアップから復元する
- 侵入経路を特定し、塞いだうえで再公開する
2番を飛ばさないことが重要です。復旧より、再発を止めるほうが結果的に安く済みます。
誰が確認するかを決めておく
バックアップが止まっていても、通常は誰も気づきません。エラー通知メールが迷惑メールに振り分けられていたり、退職者のアドレス宛に送られ続けていたりします。
そのため、次の3点を運用として決めておきます。
- 月に一度、バックアップが取得できているかを目視で確認する担当者
- 通知メールの宛先を、個人ではなく共有のアドレスにする
- 年に一度、復元テストを行う時期を決めておく
仕組みを作ることより、確認する人を決めることのほうが実際には難しく、そして効果があります。
サーバー標準の自動バックアップだけで足りるか
多くのレンタルサーバーには自動バックアップ機能がついています。無いよりは確実に良いのですが、次の点は確認しておく必要があります。
- 保存される世代数と保存期間
- 復元操作が有料オプションになっていないか
- 復元の申請から完了までにかかる日数
- 誤操作による削除も対象になるか
「バックアップは無料だが、復元は有料かつ数日かかる」という条件のサーバーは実際にあります。契約内容を一度確認しておいてください。
まとめ
バックアップで確認すべきは、取得の有無ではなく復元できる状態かどうかです。データベースを含んでいるか、別の場所にも保存されているか、30日分残っているか、そして一度でも戻せたことがあるか。
更新作業のたびに手動バックアップを取り、復元手順を維持しておくのは手間のかかる作業です。当スタジオの保守プランでは、この確認作業を毎月代行しています。あわせてワードプレスのセキュリティの弱点もご覧ください。ご相談はお問い合わせより承ります。