クラウドバックアップは標準的なデータセンターバックアップとは異なります

何らかのクラウドベースのシステム復旧テクノロジーを実装する必要がある場合、それぞれに独自のコストとリスクがある 2 つの方法から選択できます。

バックアップは常に良い戦略です。自然災害や人為的災害が発生した場合でもビジネスを継続し、重要なシステムの停止を回避するために、データとアプリケーションをどこかにバックアップできる必要があります。

当社には、バックアップ サイトとバックアップ テクノロジーを提供する完全なソリューションがあります。これらはリアクティブであるため、短期間でサイトを復元し、再び稼働させることができます。あるいは、予防的（かつより高価）な方法もあり、無効になったシステムが再リリースされ、ユーザーの知らないうちに現在のデータとコードで引き継がれる可能性があります。

[[234411]]

クラウド コンピューティングのコンテキストでは、災害復旧には、オンプレミス システムのオプションとはまったく異なる新しいオプション セットが含まれます。最終的に採用するアプローチは、アプリケーションとデータ セットがビジネスにもたらす価値に見合ったものでなければなりません。費用が災害復旧構成の価値を超えないように、これらすべての運用オプションの実用性を慎重に検討することをお勧めします。

オプション 1: リージョン間の災害復旧

同じパブリック クラウド プロバイダー内に 2 つ以上のリージョンを設定して、災害復旧機能を提供できます。したがって、バージニア州の地域が削除されれば、国の残りの地域が引き継ぐことができます。

データとアプリケーションの正確なコピーをバックアップ領域に複製して、シームレスに引き継ぐことができるように料金を支払うことができます (アクティブ リカバリなど)。または、パッシブ大容量ストレージへのスケジュールされたバックアップなど、よりコスト効率の高い方法を使用して、別のリージョンで操作を迅速に再開することもできます (パッシブリカバリ)。

オプション 2: クラウド間の災害復旧

私が最もよく受ける質問は、「パブリック クラウド プロバイダー全体が停止したり、長時間の停止が発生した場合、どのように自分たちを保護すればよいのか?」というものです。

たとえば、あるパブリック クラウドを使用して別のパブリック クラウドにバックアップを提供すると、Amazon Web Services を使用して Azure をバックアップしたり、その逆を行ったり、その他の組み合わせも可能になります。

これは DR の究極の目標、そしてリスク回避の究極の目標のように思えるかもしれませんが、マルチクラウド コンピューティングでは、DR をサポートするために 2 つの異なるスキル セットを維持し、2 つの異なるプラットフォーム構成を持つ必要があり、その他のコストとリスクも伴います。

ただし、クラウド間でシステムを複製すると (クラウド間レプリケーションとも呼ばれます)、エラーが発生する可能性が大幅に高まります。特に、プライマリ バックアップ プラットフォームを複製しようとする場合、これは絶対に望ましいことではありません。不可能ではありませんが、クラウド間のレプリケーションは、同じベンダー内のクラウド内レプリケーションよりも 5 倍困難になる可能性があります。このため、いくつかの例外を除いて、クラウド間のレプリケーションのサポートはほとんど存在しません。