コメントサービスプロバイダーはハイブリッドクラウドを信頼すべきだと言います。彼らは専門家のようです。しかし、障害が発生し、データや仮想インスタンスが失われたり、利用できなくなったりすると、その影響は甚大です。
データやインフラストラクチャにアクセスできない状態で長期間取引できる企業はほとんどありません。
ハイブリッドクラウドを信頼しますか？信頼しつつも保護しましょう。
ハイブリッドクラウドシステム、特にオンプレミスとオフプレミスのバックアップとリカバリの設定を独自に導入する際に陥りやすい大きな間違いの一つは、これらが簡単だと思い込んでしまうことです。確かにクラウド環境を稼働させるのはそれほど難しくありませんが、だからといって適切な設計を怠る必要はありません。以前にも述べたように、AWSストレージの設定を誤って、プライベートファイルをインターネットに公開してしまうことはよくあることです。したがって、ストレージが利用可能で、バックアップとリカバリ機能がクラウドに備わっているからといって、チェックボックスをいくつかオンにするだけで必要なレベルの保護が確保できると考えるのは間違いです。
企業のITインフラにおいて、バックアップとリカバリは今、かつてないほど重要になっています。かつてはファイアウォールという比較的安全な環境で自社サーバーを運用し、社内ITチームのソフトウェアパッチ適用とセキュリティ体制を整備していましたが、クラウドという未知の世界へと移行しました。つまり、他人のサーバー、パッチ適用、そして運用手順が利用され、データとアプリケーションがネットワークを縦横無尽に駆け巡り、一部のサービスはもはや物理環境ではなく仮想環境へと移行しているのです。
それを全部または一部失うと、困ったことになります。
データや仮想マシンが失われたり破損したり、ユーザーのミスやサーバーやディスクのクラッシュが発生したり、ハッキングやランサムウェアの被害に遭ったりした場合に備えて、適切なデータ保護、バックアップ、およびリカバリを実施しておく必要があります。
基本に戻る
しかし、これらをインストールする前に、まずは基本を理解することが重要です。目標は何で、リカバリシステムは何ができるのでしょうか？多くの人がこれらの点について考えていません。要件とは？バックアップして復元できるようにする必要があります。簡単ですよね？
それは違います。基本的な出発点は、復元ポイントと復元時間の目標を定義し、様々な「もしも」のシナリオから必要な機能とパフォーマンスを導き出すことです。具体的な例を挙げましょう。自社サーバー、あるいはクラウドサービスプロバイダーのサーバーが差し押さえられ、身代金を要求された場合、50万件の顧客ファイルを復元するにはどれくらいの時間がかかるでしょうか？アジャイル開発、反復型開発、そしてフェイルファストの時代において、要件について深く考えることは時代遅れに思えるかもしれませんが、そもそも問いが明確でなければ、答えを導き出すことはできません。
バックアップ戦略を選択する
目標を詳細に検討した後 (これは皆さんにお任せします)、ハイブリッド クラウドのバックアップとリカバリに必要なシステムの種類について考え始める必要があります。
クラウドの成長により、今日のバックアップとリカバリの議論において、レプリケーションが人気の選択肢として浮上しました。その考え方は、次のようになります。データのリアルタイム（あるいは現実的にはほぼリアルタイム）なレプリカを維持するという面倒な作業はすべてインフラストラクチャに任せます。問題が発生した場合には、セカンダリサイトで同期され保管されているデータに頼ります。
GitHub が 43 秒間ネットワーク接続を失い、1 日間機能停止に陥った
続きを読む
ほとんどのクラウド サービスがデフォルトでレプリケーションを提供しているか、レプリケーションの構成が比較的簡単になっていることを考えると、レプリケーションがこのように登場したことは驚くことではありません。
レプリケーションは実に素晴らしい機能です。オンプレミスとクラウドベースのストレージはどちらも、システム間でほぼリアルタイムにレプリケーションできます。リージョン間でクラウドデータをレプリケーションする場合でも、クラウドとローカルストレージ間のハイブリッド構成でレプリケーションする場合でも、レプリケーションは可能です。つまり、個々のキットやサイトの障害に備えてデータの複製を保持することは、非常に確実なアプローチと言えるでしょう。
したがって、レプリケーションのメリットは大きいです。しかし、マルウェアに感染すると、感染したファイルや暗号化されたファイルの複製コピーが作成されてしまいます。同様に、アプリケーションや仮想マシンが誤動作を起こしたり、IT担当者がコマンドラインやプロンプトに「DROP DATABASE」と入力するなど、うっかりミスをしてしまったりした場合も、同様に問題が山積みになります。なぜなら、これらの問題はすべて、まさに複製されてしまうからです。
これらすべてを回避する一つの方法は、もちろん、ハイパーバイザーレベル、クラウド、オンプレミスの仮想化システムなど、データストアのポイントインタイムスナップショットを検討することです。あるいは、SANインフラストラクチャにアクセスできる場合は、そのレベルで作業することも可能です。つまり、おそらくキットを自らホストしていることになります。目的は、既知の正常なデータのスナップショットを取得することです。
ここでは、ジリバイト単位のストレージを消費しないよう、複製が最優先事項です。しかも、複製は簡単でシンプルです。しかし、もし欠点に近づいているとお気づきでしたら、それは次の点です。多くの場合、ファイルストア全体を以前のバージョンに戻すことしかできず、特定の日時のファイルだけを取り出すことはできません。
スコッティ、応援して
バックアップは、レプリケーションと同様に、その名前が示すとおりのことだけを実行します。この場合、データは、データセンターのハードウェア障害、ユーザー エラー、ランサムウェアの発生、その他のインシデントなどのイベントによってトリガーされるサービス レベル アグリーメントに従って呼び出されるまで保存されます。
バックアップは非常に基本的で従来的な方法で、年1回、月1回、週1回の完全バックアップに加え、1日に1回以上増分バックアップを取ることができます。これらの増分バックアップは、前回の完全バックアップ以降のデータ変更のログとなります。つまり、復元に必要なのは2種類のバックアップメディアだけです。1つは最新の完全バックアップを含むメディア、もう1つはそれ以降のすべての増分変更を含むメディアです。前回の完全バックアップと変更ログを組み合わせることで、ファイルシステムとデータベースを最新の増分バックアップに再構築できます。
GitLab.com が間違ったディレクトリを削除した後にダウンし、バックアップが失敗する
続きを読む
このアプローチは、パブリッククラウドとオンプレミス機器をまたぐハイブリッド環境で特に便利です。最初のバックアップのみが完全なコピーとなり、残りは小規模なアップデートとなるため、スケジュールに基づいてサイト間で大規模なバックアップを何度もアップロードするコストと労力を費やす必要がなくなります。つまり、一度に大きなバックアップを作成すれば完了です。いや、そうあるべきです。
しかし、これは重要な「しかし」です。いざという時に、何千もの差分を含むフルバックアップを延々と時間をかけて復元するのは、望ましくありません。バックアップシステムには、「合成」フルバックアップを定義できる機能が必要です。合成フルバックアップとは、フルコピーと増分コピーを1つにまとめ、復元がはるかに高速な単一の仮想エンティティを提供する機能です。
つまり、一度だけ完全アーカイブを作成し、増分バックアップからの再構築に頼るのではなく、増分バックアップに一度でも失敗すると、データが失われ始める可能性があります。代わりに、定期的に仮想または物理の完全バックアップを作成し、増分バックアップで最新の日、時間、分まで復元するなど、ビジネスの運営状況に応じて最適なバランスを見つけてください。
これを重複排除する
ここで重複排除について触れておきます。インフラのどこかにストレージ（低レベルのSANであれ、バックアップシステムが書き込むストレージであれ）があれば、重複排除テクノロジーも利用できます。重複排除はバックアップファイルのサイズを縮小することで、リカバリ手順中のネットワークトラフィックの削減などに役立ちます。重複排除によってデータのコピーのデータ量が90%以上削減されることも珍しくありません。これは、例えば同じデータチャンクを10個保持するのではなく、1つのコピーとそれへの9つの小さな「ショートカット」形式のポインターを保持することで機能します。
合成バックアップは、重複排除機能を備えたハイブリッド環境でのみ実現可能です。クラウドでは、ネットワーク転送とストレージのバイト単位で料金が発生するため、ネットワーク上で移動するデータとストレージバケットに保存するデータに細心の注意を払う必要があります。重複排除は、特にハイブリッド環境の広域環境では、バックアップとリカバリにかかる時間を短縮できます。複数のデータコピーを作成し、保護することは、複数のインストール間でデータをやり取りする際に不可欠です。
ある程度は信頼できる…
今日のテクノロジーは実に信頼性が高く、企業データのリスク評価はますます低いスコアを示しています。IT機器の信頼性はかつてないほど高まっています。例えば、SSDには可動部品がないため、ビットエラーの影響を受けないわけではありませんが、少なくともHDDのように物理的に故障することはありません。また、耐障害性はもはやロケット科学の域を脱しています。
テクノロジーベンダーは、ユーザーが自社のインフラではなく自社のインフラを利用することを望んでいるため、クラウドの恩恵も大きいと言えるでしょう。しかし、クラウドはバックアップとリカバリに新たな重要性をもたらしました。
「彼ら」、つまりサービス プロバイダーが、ユーザーが制御できないデータ センターで混乱を引き起こすだけでなく、ハイブリッド環境のハッカーがオンプレミスとオフプレミスのサーバー、ネットワーク、ストレージに侵入し、大混乱を引き起こし、痕跡を隠蔽して、信頼できると思っていたレプリカやスナップショットを吹き飛ばしてしまう可能性もあります。
ハイブリッドで「簡単」な設計をしたり、デフォルト設定を採用したりすると、情報の保護に失敗する可能性が高くなります。また、バックアップとリカバリのファブリックを確保する責任者としての義務を果たせなくなる可能性も高くなります。
幸いなことに、ハイブリッドのバックアップとリカバリは、克服できない課題ではありません。必要なのは、基本をしっかりと把握し、目標と結果を理解することだけです。つまり、どのデータまたは仮想インスタンスを、どのくらいの速さで、どの期間から取り戻すかなど、さまざまな要素を理解することです。
したがって、ハイブリッド クラウドを信頼するのは当然ですが、慎重に進め、適切なバックアップとリカバリのアーキテクチャを導入してください。®
