書籍『完全ガイド』の元になったWebコンテンツ

g.災害に強いオンプレミス環境を整えるには new!

「オンプレミスは災害に弱い」とよく言われます。
地震や火災、落雷や停電でシステムが止まる――最悪、データまで失う。そんな事態は、普段はなかなか想像しにくいですよね。

でも、オンプレが現実の建物や電源・配線といった“物理”の上に成り立つ以上、自然の力を完全に避けることはできません。
さらに「災害」という言葉の中には、広い意味で人為的な事故（人災）やサイバー攻撃まで含めて語られることもあります。要するに、予測や制御が難しい出来事は、オンプレにもクラウドにも起こりうる、という前提を持っておく必要があります。

一方でクラウドは、「オンプレに比べて災害に強い」と語られがちです。
本当にそうでしょうか？　少し前の有名な二つの出来事から考えてみます。

�@ 2011年：Gmailの障害と“磁気テープ”の逆転劇

2011年、Googleのメールサービス「Gmail」で障害が発生し、ごく一部のユーザーでメールが消えたように見える事象が起きました（影響は全体のごく一部）。
原因はストレージソフト更新時のバグと説明され、最終的にはオフライン保管の“磁気テープ”バックアップから復旧しています。

ポイントはここです。
クラウドであっても、オフライン／別系統のバックアップをしっかり持っていれば、深刻な障害からでも戻せる可能性が高まります。実際、Googleは複数のバックアップを用意していて、そのうちテープが決め手になりました。
（音楽配信サービスでも、後年テープが活躍したという報道がありました。細部の数字には諸説ありますが、「オフライン媒体の有効性」は大きな示唆です。）

�A 2012年：ファーストサーバの大規模データ消失

2012年、Yahoo!子会社のレンタルサーバー「ファーストサーバ」で大規模障害が発生しました。
不備のある更新プログラムを本番に適用してしまい、さらにバックアップ側にも適用してしまうという人為ミスが重なり、多数の顧客データが消失。Webだけでなく、メールやメールボックスのデータにも被害が及びました。
調査では、個人のミスにとどまらず、手順・管理体制の問題も指摘されています。2018年には同社の「Zenlogic」でも大規模障害があり、メールの送受信ができない期間が生じるなど、利用者の不信を招きました。

整理してみると

• オンプレミス
  自社の都合で更新・メンテができ、独自のセキュリティ強化も可能。
  ただし物理災害の影響は直接受けやすいので、建屋・電源・ネットワークまで含めた対策が欠かせません。
• クラウド
  データセンター多拠点や冗長化など、物理災害への耐性は一般に高め。
  とはいえ人為ミスやソフト不具合、契約外の事象までは避けきれません。SLA（サービスレベル契約）は可用性中心で、データの完全回復や損害の補償は限定的なことが多いです。
• テープ（オフラインバックアップ）
  ネットワークから切り離されているため、ランサムウェアや誤操作の連鎖から守りやすい。
  復旧に時間はかかりがちですが、“最後の砦”としての強さがあります。

小さな結論

「オンプレ＝災害に弱い／クラウド＝災害に強い」と単純化するより、
“どこにデータの最後の拠りどころを置くか”が本質です。
クラウドでもオンプレでも、異なる場所・異なる仕組み・オフラインに複数の世代を確保しておくこと――これがデータ消失の現実的な防御になります。オンプレのみ、クラウドのみ、のどちらかに偏った運用はリスクが高いということになります。ハイブリッドクラウド＋αの運用でバックアップを必ず取っておくということが、まず基本的な「災害に強い環境」の答えです。

基本的にオンプレミスのみで本格的に環境を構築したい、という方や、もっと詳しく設計や運用について知りたい方はこの先もご覧ください。

オンプレミスは自社でサーバーやシステムを構築・運用する形態です。一般にクラウドの方が標準で強力な冗長性を備えますが、適切な設計と運用を行えば、オンプレミスでも災害に強い環境を実現できます。

基本方針（まず決めるべき指標）

• RTO（復旧時間目標）：
  停止から復旧までに許容できる時間。
• RPO（復旧時点目標）：
  復旧時に許容できるデータ欠損量（例：5分前まで）。
• 優先順位：
  先に復旧すべき業務（メール、DNS、認証、バックアップストレージ等）。

災害に強いオンプレミスを構築するポイント

1) データセンターの活用（コロケーション）

• 設備要件：
  耐震・耐火、N+1以上の電源冗長（UPS＋発電機）、多系統空調、ガス系消火。
• 回線冗長：
  異キャリア・異ルートでの冗長回線、ラストワンマイルの物理多重化。
• サイト選定：
  本社／庁舎と物理的に離れた地域（洪水・停電の同時影響を避ける）。



→ N+1以上とは？

• 意味：
  必要台数（N）に対して、最低1台の予備を加えて運用する冗長構成のこと。
• 例：
  発電機が1台（N=1）必要なら、実際は2台（1+1）用意。空調機が3台必要なら4台（3+1）。
• ねらい：
  どれか1台が故障してもサービスを止めないため。

2) バックアップ戦略

• 3-2-1-1-0 ルール：
  データを3世代・2種類媒体・1つは遠隔地・1つはイミュータブル/オフライン、検証エラー0を目指す。
• 整合性確認：
  定期的なリストア演習（実際に戻す）と整合性チェック。
• 暗号化・鍵：
  バックアップは暗号化し、鍵は別保管。鍵のローテーションと廃棄手順を文書化。



→ 3-2-1-1-0 バックアップ・ルールとは？

• 3：バックアップは最低3コピー（本番＋別コピー2つ）。
• 2：2種類以上の媒体に保存（例：ディスクとテープ）。
• 1：1つは遠隔地に保管（災害で同時被災を避ける）。
• 1：1つは改ざんできない形（イミュータブル or オフライン）で保管。
• 0：復元テストでエラー0＝定期的にリストア検証して復旧できることを確認。

3) ディザスタリカバリ（DR）

• DRサイト：
  遠隔地に待機系を用意（コールド/ウォーム/ホットのいずれか）。RTO/RPOに応じて選択。
• データ複製：
  同期（低RPOだが距離に制約）または非同期（距離自由だが数分〜遅延）。
• 切替手順：
  フェイルオーバー／フェイルバックの手順書、権限、判定基準を明確化。



→ DRサイトとは？

• 意味：
  Disaster Recovery（災害復旧）用の予備拠点。本拠点が止まったときに切り替えるためのサイト。
• 種類：
  
  • コールド：
    機器やデータを用意しておき、災害時にセットアップ開始（コスト低、復旧は遅い）。
  • ウォーム：
    一部を常時同期・起動準備（中コスト、中速復旧）。
  • ホット：
    本番とほぼ同等を常時稼働・同期（高コスト、最速復旧）。
• ポイント：
  どれを選ぶかはRTO（復旧時間）とRPO（許容データ欠損）で決める。

4) システム構成の冗長化

• サーバー：
  クラスタリング、仮想基盤のHA、電源二重化（デュアルPSU）。
• ネットワーク：
  コアルータ冗長、STP/VRRP/HSRP 等、セグメント冗長。
• 電源：
  UPSの無停電時間と自家発の燃料確保を計画。

5) メール特有の設計ポイント

• DNS・MX：
  権威DNSの冗長（異拠点／異事業者）。MXレコードは複数拠点へ配分し、優先度とTTLを適切化。
• スプールとアーカイブ：
  メールスプール領域はRAID＋バックアップ。ジャーナリング/アーカイブは別系で保持。
• 一時蓄留：
  回線断対策として外部中継（store-and-forward）や、一時リレーの用意。
• 送信経路：
  アウトバウンドのスマートホスト二重化、逆引き/DKIM/DMARC/SPFのDR側準備。



→ スマートホストとは？

• 意味：
  社内メールサーバが外部へ送信する際に、中継を任せる送信用リレーサーバのこと。
• 利点：
  自前で到達性やIP評価を管理する負担を減らし、ブロックされにくい経路で配信できる。回線障害時の経路冗長にも使える。
• 使い方のイメージ：
  社内メールサーバ → スマートホスト → 各相手先メールサーバ。

6) サイバー災害対策

• ゼロトラスト前提：
  最小権限、MFA、特権IDの監査、メールゲートウェイでのマルウェア/フィッシング対策。
• ネット分離と復旧：
  感染時の論理隔離と、クリーンルーム復旧手順を用意。
• ログ保全：
  改ざん耐性のある中央集約（WORM/イミュータブル）と可視化。



→ ゼロトラストとは？

• 意味：
  「何も信用しない」を前提に、社内外を問わず毎回検証してアクセスを許可する設計思想。
• 基本原則：
  
  • 常時検証：
    ユーザー・端末・場所・状態を都度確認（MFA 等）。
  • 最小権限：
    必要最小限の権限だけ与える。
  • セグメント化：
    ネットワークを細かく分割し、横移動を防ぐ。
  • 監査と可視化：
    ログを集約し、異常を早期検知。
• ねらい：
  侵入を前提に、被害を最小化し、迅速に検知・遮断・復旧する。

7) BCP（事業継続計画）と訓練

• 役割分担：
  指揮系統、連絡網、委託先連絡手順を明確化。
• 演習：
  机上演習＋実地訓練（停電想定、回線断想定、DR切替演習）を定期実施。
• 監査：
  定期レビューでRTO/RPO・手順・連絡先・資材（燃料/予備機）を更新。

オンプレミスとクラウドの比較（災害対策の観点）

• クラウド：
  標準で多リージョン/ゾーンの冗長性、SLA、バックアップ選択肢が豊富。短期で高可用を実現しやすい。
• オンプレミス：
  自社で同等の対策を設計・運用する必要があるが、データ主権・カスタマイズ・ネット断時の自営継続性に優れる。
• 実務的解：
  重要ワークロードはオンプレ＋DRを遠隔地DCで、外向き周辺はクラウド併用などハイブリッドが現実的。

まとめ

「災害に強いオンプレミス」とは、単に社内にサーバーを置くことではなく、適切なDC活用、冗長化、バックアップとDR、サイバー対策、BCP訓練を組み合わせ、定期的に検証・改善する体制を指します。RTO/RPOの合意を起点に、メール/DNS/認証など最初に立ち上げるべき機能から順に手順と自動化を整備しましょう。

出典

• 日本経済新聞 (2022年6月29日) 記事タイトル: 「Googleも重宝　しぶとく生きる日本製磁気テープ」
  内容: 2011年のGmail障害はテープから復旧。クラウド時代でもオフライン媒体が再評価、国内製テープも存在感。信頼性と長期保管性が理由に。
• ITmedia NEWS (2012年6月25日) 記事タイトル: 「ファーストサーバ、データが消えた理由を説明　削除コマンドの停止・範囲記述漏れ」
  内容: 更新プログラムの記述ミスと運用手順不備が重なり、削除コマンドが本番とバックアップに適用。結果、顧客データが広範に消失。


    
     ツイート