ROBO Backup：リモートオフィスおよび支店の保護

ROBOバックアップの真の問題点 

1つの支店を保護するのは簡単なことです。500カ所を保護することこそが、真の問題なのです。ROBOバックアップに関するアドバイスの多くは、前者の問題には対処するものの、後者の問題を無視しています。 1つの支店で機能するアーキテクチャは50店舗になると機能しなくなり、50店舗で機能するアーキテクチャは500店舗になると一から再構築する必要があります。 

私は、数百店舗を展開するチェーン店において、各小売店舗にバックアップアプライアンスを導入する顧客の様子を見てきました。 導入から2年が経過した時点で、現場には400台のバックアップアプライアンスが設置されていますが、ファームウェアのバージョンは統一されておらず、各拠点にはIT担当者がおらず、その修理方法を知っているたった1人の担当者のための四半期ごとの出張予算しか確保されていません。バックアップは技術的には実行されています。しかし、ほとんどの拠点ではバックアップのテストが一度も行われていません。 実際の復旧が機能するかどうか、誰も確信を持っていません。 

この記事は、支店側にほとんど何も配置しないことでスケーラビリティを実現するアプローチについて述べたものです。 支店は、支店としての業務を継続します。バックアップは一元的に実行されます。 

ROBO拠点が本社よりも難しい理由 

本社にはデータセンター、大容量の回線、そしてITチームがあります。ROBO拠点にはそれらのいずれもありませんが、ビジネス継続性に関する要件は同じです。 4つの具体的な課題が常に浮上します。 

第一に、WANの帯域幅の問題です。 一般的な支店回線でのフルバックアップは、バックアップウィンドウをオーバーし、業務時間中に回線を飽和させてしまう可能性があります。日常業務に十分な帯域幅であっても、夜間のフルバックアップにはほとんど不十分です。 

2つ目は、現地のITスタッフが存在しないことです。 小売店舗にはバックアップ管理者がいません。支店で稼働するシステムはすべて、自律的に動作し、自律的に復旧でき、担当者が現地へ出向く必要が一切ないものでなければなりません。 

3つ目は、規模の問題です。 支店が1か所なら簡単です。しかし、同一のポリシーと同一のレポート要件を持つ500か所の支店を管理することが、真の課題となります。 

そして、4つ目はSLA（サービスレベル契約）です。顧客や規制当局は、小売店舗の回線速度が10Mbpsであるかどうかなど気にしません。 POSデータが失われたり、システムがダウンしたりすれば、事業は停止してしまいます。ROBOバックアップは、本社レベルのインフラを必要とせずに、本社レベルの復旧を実現しなければなりません。

支店におけるダウンタイムの実際のコスト 

Statistaの調査によると、組織の24％が、重要サーバーのダウンタイムによる1時間あたりのコストを30万1,000ドルから40万ドルと報告しており、14％は1時間あたり500万ドルを超えると報告しています。 POSシステムや取引システムが分散している小売業や金融サービス業界では、支店が1時間オフラインになるごとに、その影響は倍増します。

支店での障害は通常、互いに独立しているため、コストはさらに膨れ上がります。 1つの支店がダウンしただけでは、企業の緊急対策本部が動員されることはありません。誰かが気づくまで、収益は静かに失われ続けます。中央のIT部門が対応に乗り出す頃には、復旧までの時間がすでに数時間経過していることがよくあります。 

コンプライアンス規制により、最低基準はさらに引き上げられています。GDPRでは、顧客データの適切な管理（適時の削除を含む）が求められています。 HIPAAでは、医療データの適切な管理を求めます。支店で生成されたデータは、適切にバックアップされているかどうかにかかわらず、両方の規制の対象となります。 

現代のROBOデータ保護に実際に必要なもの 

5つの要件があり、そのいずれかを満たさないアーキテクチャでは、1年以内に問題が生じることになります。 

WAN効率の高い運用。業務時間中に、バックアップによって支店の接続帯域が飽和状態になってはなりません。 WAN経由でのフルバックアップは許容されません。 

ローカルインフラの完全排除。支店に専用のバックアップサーバー、アプライアンス、または独自仕様のストレージを設置しません。サイト内の構成要素が少ないほど、システムの信頼性は高まります。 

一元管理。 すべての支店を単一の管理画面で一元的に把握できます。ポリシーは一度適用すれば、どこでも強制されます。レポートは本社に集約されます。

両端での復旧。支店のスタッフは、本社のIT部門に連絡することなく、削除されたファイルを復旧できます。 必要に応じて、中央IT部門が本社から支店全体のデータを復旧できます。 

きめ細やかでテナントを意識した設計。VM、アプリケーション、またはファイルレベルでの復旧が可能です。管理者およびテナントレベルのアクセス権限により、各支店は他の支店のデータを見ることなく、自身のデータを管理できます。 

「レプリカからのバックアップ」の実際の仕組み 

最新のROBOバックアップを可能にするアーキテクチャの転換は、一見すると驚くほどシンプルです。 各支店でバックアップを実行する代わりに、通常のDR（災害復旧）運用の一環として支店のデータをデータセンターにレプリケートし、その後、データセンターでレプリカから実際のバックアップを実行します。 

変化する点：バックアッププロセスにより、支店側の演算リソース、ストレージ、帯域幅が一切消費されなくなります。 支店では、レプリケーションのために変更されたデータを一度送信するだけです。バックアップは、本社にすでに存在するデータに対して行われます。

フローは単純明快です。支店は、ネイティブレプリケーションを使用して、継続的に、またはポリシーに基づいてデータセンターへレプリケーションを行います。データセンターの HYCU は、支店からではなく、レプリケートされたコピーからバックアップを行います。 オプションのセカンダリバックアップコピーは、3-2-1準拠のため、データセンター内のNutanix以外のストレージに書き込まれます。 復旧処理は、どちらの拠点でも実行可能です。 

Nutanix ベースの ROBO については、具体的には、本社で 1 時間以内にプロビジョニングされ、すぐに稼働可能な状態で支店へ出荷される 1 ノードまたは 2 ノードのクラスターと組み合わせて使用されます。 Prismによる同一の管理プラットフォーム。HYCUポリシーも同様です。 ROBO専用の製品は存在しません。また、ESXiベースのROBOサイトもサポートしており、リカバリ時にはAHVとESXiの間でワークロードを移動させたり、AWSやGCP上のNutanix Clustersへ移行したりすることが可能です。 

レプリケーションだけでは災害復旧とは言えない理由 

チームはこれらを常に混同しています。 「すべての支店からデータセンターへレプリケーションを行っているため、万全です。」これは重大な誤解です。 

レプリケーションは現在の状態のコピーに過ぎません。ソースがランサムウェア、アプリケーションのバグ、あるいは管理者の誤ったコマンドによって破損した場合、その破損部分もレプリケーションされてしまいます。 その結果、データセンターには破損したデータの完全なコピーが残り、元のデータは失われてしまいます。 復旧の拠り所がなくなってしまいます。 

真の ROBO データ保護は、3-2-1のルールに従います。つまり、2種類の異なるメディアに、少なくとも3つのデータコピーを保存し、そのうち少なくとも1つはオフサイトに保管するというものです。 レプリケーションは、そのコピーの一つであり、戦略全体ではありません。バックアップは、レプリケーションでは提供されない、特定の時点の復元可能なコピーを追加します。レプリケーションは、迅速なフェイルオーバーを可能にします。 バックアップは、クリーンな復旧を可能にします。 

ROBO環境では、本社よりもこの点が重要です。なぜなら、支店には多くの場合、単一のレプリケーション先しかなく、その他の保護層がないからです。ある支店がランサムウェア攻撃を受けると、本社の誰かが気付く前にレプリカが破損してしまう可能性があります。保存期間を設定したレプリカからのバックアップにより、この問題を解決できます。 稼働中のレプリカが侵害された後でも、支店をクリーンな時点の状態に復元することが可能です。 

ROBOの復旧が実際にどのようなものか 

3つのシナリオで、ROBO運用に必要なことのほとんどを網羅できます。 単一のファイルまたはフォルダ：従業員が誤って文書を削除してしまった場合です。支店のスタッフが、最新のバックアップからファイル単位の復旧をセルフサービスで行います。単一のVMまたはアプリケーション：POS（販売時点情報管理）用VMが故障したり、アプリケーションが破損したりした場合です。ワンクリック復旧により、支店のVMを復元するか、支店のハードウェアが交換される間、一時的に本社でVMを復元します。 火災、洪水、ランサムウェア、またはハードウェア障害による支店全体の障害。 支店全体が、代替サイト、あるいは一時的な運用を目的としたAWSまたはGCP上のNutanix Clustersのいずれかに復旧します。 

これら3つのケースすべてにおいて、復旧は管理者またはテナントによって制御されます。支店のスタッフは、自身の管轄範囲内のデータを復旧します。他の支店の状況については把握できません。 これは、複数の事業者がインフラを共有する小売業やフランチャイズ環境において重要です。 

ROBOのデータ保護に関するよくある質問 

すべての支店にバックアップインフラは必要ですか？ 

いいえ、それこそがポイントです。 「レプリカからのバックアップ」では、支店がデータセンターへレプリケーションを行い、実際のバックアップ処理は一元的に実行されます。支店にバックアップサーバーも、アプライアンスも、専用ストレージも必要ありません。 支店は変更されたデータをレプリケーションのために一度送信するだけで、残りの処理は本社が行います。 

ROBOの災害復旧にはレプリケーションだけで十分ですか？ 

いいえ。レプリケーションは現在の状態をコピーするものであり、フェイルオーバーには有用ですが、ソースが破損している場合は無意味です。なぜなら、破損部分もレプリケートされてしまうからです。 ROBO環境では、迅速なフェイルオーバーのためのレプリケーションと、特定の時点へのクリーンな復旧を可能にする保持期間を備えたバックアップの両方が必要です。「3-2-1のルール」は、本社と同様に支店にも適用されます。 

サイト全体の損失にはどのように対処するのでしょうか？ 

火災、洪水、または長期にわたるハードウェア障害などにより、支社が現地で復旧不能となった場合、ワークロードはAWSまたはGCP上のNutanix Clustersに復元されます。ポリシーも復旧モデルも同様です。 支社がオンラインに戻るまで、クラウドホスト型インフラストラクチャから運用を継続します。設定を変更することなく、後でワークロードを元の環境に戻すことができます。 

接続状態が悪い支社についてはどうでしょうか？ 

WAN帯域を消費する処理はレプリケーションのみです。 5Mbpsの回線で運用されているお客様もいらっしゃいます。レプリケーションは利用可能な帯域幅に合わせて構成されており、それ以外の処理はすべてデータセンターが担当します。支店の回線が本当に使用不能な場合、このアーキテクチャでは対応できませんが、テープを郵送する以外の選択肢でも同様です。 

10以上の支店を運営されている場合は、ぜひご相談ください 

当社が置き換えているROBOアーキテクチャの多くは、20～500の支店を運用しており、各サイトにバックアップアプライアンスが設置されています。 これらを「レプリカからのバックアップ」に置き換える場合、通常、ハードウェアの更新を回避できるだけで、初年度中に投資を回収できます。運用面の改善効果は通常、コスト削減効果よりも大きいですが、事前に定量化するのは困難です。ご自身の環境に当てはまると思われる場合は、担当のアカウントチームにご相談ください。