Webサイトのバックアップの取り方と復元手順

Webサイトのデータは、ある日突然失われることがあります。サーバーの障害、不正アクセスによる改ざん、更新作業中の操作ミス。原因はさまざまですが、共通しているのは「その瞬間まで、誰もバックアップを気にしていなかった」ことです。

当社がサイトの保守を引き継ぐ際、必ず最初に確認するのがバックアップの状態です。そして残念ながら、「バックアップは取っているはず」という認識と実態が食い違っているケースが少なくありません。取っているつもりが止まっていた、取っていたが復元方法を誰も知らなかった。こうなってからでは遅いのです。バックアップが必要な理由から、取り方、保管場所、そして意外と知られていない正しい復元手順まで、順に整理していきましょう。

なぜバックアップが必要なのか

データ損失の原因は、大きく4つに分けられます。どれも「うちには起きない」と言い切れないものばかりです。

サーバー障害

ハードウェア故障、ソフトウェアの不具合、停電などでサーバーが停止し、データが失われる

サイバー攻撃

ランサムウェアやマルウェアにより、データが暗号化・削除・改ざんされる

人的ミス

誤操作によるファイル削除、アップデート失敗、設定変更のミス

自然災害

地震・火災・洪水などでデータセンターが物理的に損傷する

実際に最も多いのは、派手な攻撃ではなく人的ミスです。WordPressのアップデートで画面が真っ白になった、テーマのファイルを編集していて壊してしまった、プラグインを更新したらフォームが動かなくなった。サイトを運用していれば、この種のトラブルはいつか必ず起きます。バックアップがあれば数十分で戻せる事故が、なければ数週間の作り直しになるのです。この差は、事故が起きたその日に痛感することになります。

「サーバー会社が何とかしてくれるはず」という期待も、残念ながら当てになりません。多くのレンタルサーバーの利用規約には、データの保全は利用者の責任であり、障害等によるデータ消失について運営会社は責任を負わない旨が明記されています。サーバー会社が提供する自動バックアップはあくまで付加サービスであり、契約プランによっては提供されていないこともあります。自社サイトのデータを守る最終責任は、自社にあるのです。

失われるのはデータだけではありません。サイトが止まっている間、ECサイトなら売上がゼロになり、問い合わせフォームが動かなければ商談の機会を逃します。復旧が長引けば、検索エンジンからの評価も下がり、取り戻すのに数ヶ月かかることもあります。バックアップは、こうした連鎖的な損失を断ち切るための保険だといえます。サイトを守る対策の全体像はWebサイトのセキュリティ対策の基本で整理していますが、その中でもバックアップは「他の対策がすべて破られたときの最後の砦」という特別な位置づけにあります。

バックアップの取り方と頻度

バックアップの対象は2つあります。記事や商品情報が入っているデータベースと、画像・テーマ・プラグインなどのファイル一式です。片方だけでは復元できないため、必ずセットで取得します。

取り方には3つの方法があり、それぞれ性格が異なります。

完全バックアップ

サイトの全データを丸ごと保存する。復元が簡単だが、容量と時間を多く使う。週1回程度が目安

増分バックアップ

前回のバックアップ以降に変更されたデータだけを保存する。軽いが、復元には複数のバックアップが必要。日次向き

差分バックアップ

最後の完全バックアップ以降の変更分を保存する。復元は完全バックアップと最新の差分だけで済む。日次向き

頻度は、サイトの更新ペースから逆算します。毎日商品や記事が増えるECサイトやメディアなら日1回以上、週に数回更新する企業サイトやブログなら週2〜3回、ほとんど更新しないサイトでも週1回は確保したいところです。判断の基準は「最後のバックアップ以降の作業を、もう一度やり直せるか」です。やり直せない量になる前に、次のバックアップを取る。これが頻度設定の考え方です。

保持する世代数も決めておきましょう。直近1回分しか残さない設定だと、改ざんに数日気づかなかった場合、汚染されたデータで上書きされたバックアップしか残っていないことになります。日次で7世代、週次で4世代のように、時間を遡れる幅を確保しておくと、発見が遅れたトラブルにも対応できます。

WordPressサイトであれば、UpdraftPlusやBackWPupといった定番プラグインで、スケジュール実行と外部ストレージへの自動転送まで設定できます。エックスサーバーをはじめ多くのレンタルサーバーも自動バックアップを標準提供しています。ただし、サーバー標準のバックアップには保持期間が7〜14日程度と短いものがあり、以前は復元データの取り出しが有料のサーバーもありました。「サーバーが取ってくれているから大丈夫」と思い込まず、保持期間・復元方法・費用を一度確認しておきましょう。WordPress特有の注意点はWordPressのセキュリティ対策でも扱っています。

このほか、アップデートやリニューアルといった大きな変更の直前には、スケジュールとは別に手動でバックアップを取るのが鉄則です。変更作業はトラブルの発生率がいちばん高い瞬間だからです。

保管場所は「3-2-1ルール」で考える

バックアップをどこに保存するかは、取ることと同じくらい大事です。よくある失敗が、バックアップを本番サーバーと同じ場所に保存しているケース。これではサーバーごと障害が起きたときに、本体もバックアップも一緒に失われます。

保管の指針として世界的に使われているのが「3-2-1ルール」です。データのコピーを3つ持ち、2種類の異なる媒体に保存し、そのうち1つはサイトとは別の場所に置く、という原則です。たとえば、本番サーバーのデータに加えて、サーバー会社の自動バックアップと、クラウドストレージへの自動転送を組み合わせれば、この条件を満たせます。先ほど挙げたWordPressのバックアッププラグインの多くは、Google DriveやDropboxへの自動転送に対応しているため、一度設定してしまえば手間なくオフサイト保管まで実現できます。

オンプレミス（自社サーバー・NAS）

手元で管理でき、取り出しも速い。ただし災害や盗難で本体と同時に失うリスクがある

クラウドストレージ

Amazon S3やGoogle Cloud Storageなど。地理的に分散され災害に強い。自動転送との相性も良い

外部メディア（外付けHDDなど）

安価で手軽だが、劣化や紛失のリスクがある。補助的な位置づけで使う

バックアップデータには、サイトの全情報が入っています。顧客情報を扱うサイトなら、バックアップの流出はサイト本体の流出と同じ被害になるため、保存時の暗号化と、アクセスできる人の限定も忘れずに行いましょう。

万が一の際の復元手順

バックアップの本当の価値は、復元できて初めて生まれます。ところが復元は、トラブルで気が動転している状況で行う作業です。だからこそ、平時の準備がものを言います。

まず、復元手順を文書にしておきます。どこにバックアップがあり、どのツールで、どの順番で戻すのか。サーバーやデータベースのログイン情報はどこにあるのか。担当者が不在でも他の人が実行できる粒度で書いておくと、いざというときの対応速度がまるで違います。

次に、定期的な復元テストです。当社の保守の現場では、これがいちばん重要だと考えています。バックアップファイルが実は壊れていた、必要なデータが含まれていなかったという問題は、復元してみるまで分かりません。実際、他社から保守を引き継いだサイトで復元テストを行ったところ、ファイルは毎日保存されていたのにデータベースが対象から外れており、記事データが一切戻せない設定だったことがありました。設定画面上は「バックアップ稼働中」に見えるだけに、テストなしでは気づけない落とし穴です。年に1〜2回でも、テスト環境への復元を実際にやっておくと、こうした穴が事前に見つかります。

あわせて、復旧までの目標時間も決めておくと、体制の設計が具体的になります。「半日以内に復旧させたい」なら、手順書と担当者の習熟が必要ですし、外部の保守会社に任せる選択肢も見えてきます。目標がないと、いざというときに「誰が、いつまでに、何をするか」がすべてその場の判断になってしまうのです。

実際の復元作業は、次の順で落ち着いて進めます。

• 被害範囲の確認
• バックアップデータの検証
• 復元環境の準備
• 段階的な復元と動作確認

最初に、どのデータがいつから失われたのかを確認します。原因が不正アクセスの場合、直近のバックアップにも改ざんが含まれている可能性があるため、汚染前の時点まで遡る判断が必要です。次に、使うバックアップが正常に開けるか、必要なデータが揃っているかを検証します。そのうえで、可能ならテスト環境で先に復元し、表示とフォームなど主要機能を確認してから本番へ反映します。データベース、ファイル、設定の順に段階的に戻し、各段階で動作を確かめながら進めると、二次被害を防げます。

復旧を急ぐあまり検証を飛ばすと、壊れたデータで上書きしてしまい、状況がさらに悪化することがあります。急がば回れが、復元作業の鉄則なのです。

まとめ

バックアップ体制は、「何を、どのくらいの頻度で、どこに保存し、どう戻すか」の4点が揃って初めて機能します。データベースとファイルをセットで、更新ペースに合わせた頻度で取得し、3-2-1ルールで保管し、復元手順の文書化とテストまで行う。ここまでやって、ようやく「うちはバックアップを取っている」と言えます。

まずは今日、自社サイトのバックアップがいつ取られたものか、そしてそれを誰が復元できるのかを確認してみてください。この2つの質問に即答できる会社は、実のところ多くありません。答えに詰まったら、そこが対策の始めどころです。日々の運用の中でバックアップを回し続ける体制づくりは、サイト保守の重要性とあわせて考えると全体像がつかめます。

バックアップ体制の点検と復元テストのご相談

自社サイトのバックアップが正しく機能しているか自信がない、復元手順を整備したいという方は、合同会社ギャラクタスにご相談ください。現在のバックアップ設定の点検、3-2-1ルールに沿った保管体制の設計、復元テストの実施まで、保守の実務としてお手伝いしています。無料相談で、いまのサーバー環境と運用状況をお聞かせください。