次の方法で共有

Azure アンマネージド ディスクのバックアップとディザスター リカバリー

適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット

この記事では、Azure の IaaS 仮想マシン (VM) とディスクのバックアップおよびディザスター リカバリー (DR) を計画する方法について説明します。 このドキュメントでは、アンマネージド ディスクまたはページ BLOB について説明します。

最初に Azure プラットフォームに組み込まれているフォールト トレランス機能について説明します。この機能は、局所的な障害に対する保護となります。 次に、組み込みの機能では完全にはカバーされない障害のシナリオについて説明します。 また、別のバックアップと DR の考慮事項を適用できるワークロード シナリオの例を複数紹介します。 そして、IaaS のディスクの DR に対して考えられる解決策を検討します。

はじめに

Azure プラットフォームでは、局所的なハードウェア障害からお客様を保護するために、冗長性とフォールト トレランスに関するさまざまなメソッドが使用されています。 局所的な障害には、仮想ディスクのデータの一部を格納する Azure Storage サーバー マシンに関する問題や、これらのサーバー上の SSD または HDD の障害などが含まれます。 このような孤立したハードウェア コンポーネントの障害は通常の操作中に発生する可能性があります。

Azure プラットフォームはこのような障害から復旧するように設計されています。 大規模災害によって、多数のストレージ サーバーまたはデータセンター全体にも障害が発生する可能性や、それらにアクセスできなくなる可能性があります。 VM とディスクは通常、局所的な障害からは保護されていますが、VM とディスクに影響を与える可能性のある、リージョン全体にわたる致命的な障害 (大規模災害など) からワークロードを保護するためには、追加の手順が必要になります。

プラットフォームに障害が発生する可能性だけでなく、お客様のアプリケーションやデータに問題が発生する場合もあります。 たとえば、アプリケーションのバージョンを新しくしたことで、中断の原因となるデータ変更が意図せずに加えられる場合があります。 その場合は、以前のバージョンのうち、正常な状態であることがわかっている最新のバージョンに、アプリケーションやデータを戻したいと思うでしょう。 これには、定期的なバックアップを継続する必要があります。

リージョンのディザスター リカバリーについては、IaaS VM ディスクを別のリージョンにバックアップする必要があります。

バックアップと DR のオプションについて考える前に、局所的な障害の処理に使用できるいくつかの方法を要約します。

Azure IaaS 回復性

回復性とは、ハードウェア コンポーネントで発生する通常の障害の許容範囲のことです。 回復性は、障害から回復して、機能を継続する能力です。 障害を回避することではなく、ダウンタイムまたはデータの損失を回避するように障害に対応することです。 回復性の目的は、障害後にアプリケーションを完全に機能している状態に戻すことです。 Azure Virtual Machines とディスクは、一般的なハードウェア障害から復旧するように設計されています。 Azure IaaS プラットフォームがこの回復性をどのように提供するのか見てみましょう。

仮想マシンは、主にコンピューティング サーバーと永続的なディスクの 2 つの部分で構成されています。 その両方が、仮想マシンのフォールト トレランスに影響します。

VM を格納する Azure のコンピューティング ホスト サーバーで、まれにハードウェア障害が発生する場合、Azure が別のサーバー上で VM を自動的に復元するように設計されています。 このシナリオの場合、コンピューターが再起動し、しばらくしてから VM が再び起動します。 Azure はこのようなハードウェア障害を自動的に検出して復旧し、VM をできるだけ早く使用可能にすることをお客様に保証します。

IaaS のディスクに関していえば、データの持続性は、永続的なストレージ プラットフォームにとって重要です。 Azure のお客様は、重要なビジネス アプリケーションを IaaS で実行し、データの持続性に依存しています。 Azure は、ローカルに格納されているデータの冗長コピーを 3 つ保持することで、これらの IaaS ディスクを保護するように設計されています。 これらのコピーによって、局所的な障害に対する高い持続性が提供されます。 ディスクを保持するハードウェア コンポーネントの 1 つが故障しても、ディスクの要求をサポートする別のコピーが 2 つあるため、VM は影響を受けません。 (まれですが) ディスクをサポートする別のハードウェア コンポーネントが 2 つ同時に故障した場合でも、正常に動作します。

常に 3 つのレプリカを維持できるように、Azure Storage では、3 つのコピーのいずれかが利用不可になった場合でも、データの新しいコピーをバックグラウンドで自動的に生成します。 そのため、フォールト トレランス用に Azure ディスクで RAID を使用する必要はありません。 大規模なボリュームの作成が必要な場合、ディスクのストライピングには、シンプルな RAID 0 構成で十分です。

このアーキテクチャにより、Azure は IaaS ディスクのエンタープライズ レベルの持続性を、業界トップ レベルの年間故障率 0% で一貫して提供できます。

コンピューティング ホストまたはストレージ プラットフォームの局所的なハードウェア障害によって、VM の可用性に関する Azure SLA で保証対象となっている VM が一時的に使用できなくなる場合があります。 Azure では、Azure Premium SSD を使用する単一の VM インスタンスを対象とする、業界トップ レベルの SLA も提供されています。

ディスクまたは VM が一時的に使用できないことによるダウンタイムからアプリケーション ワークロードを保護するために、お客様は可用性セットを使用できます。 可用性セット内にある複数の仮想マシンによって、アプリケーションの冗長性が確保されます。 Azure では、異なる電源、ネットワーク、サーバー コンポーネントを使用する別々の障害ドメインに、これらの VM とディスクが作成されます。

このような別々の障害ドメインにより、局所的なハードウェア障害は通常、セット内の複数の VM に同時に影響することはありません。 別々の障害ドメインを持つことで、アプリケーションの高可用性が実現されます。 高可用性が要求される場合に、可用性セットを使用することは優れた選択であると考えられます。 次のセクションでは、ディザスター リカバリーの側面について説明します。

バックアップと障害復旧

ディザスター リカバリーとは、まれに発生する大きなインシデントから復旧する能力です。 このようなインシデントには、リージョン全体に影響するサービス中断のように、一時的なものではない大規模な障害が含まれます。 ディザスター リカバリーには、データ バックアップやアーカイブの他に、バックアップからのデータベースの復元などの手動操作も含まれる場合があります。

局所的な障害に対する Azure プラットフォーム組み込みの保護機能は、大規模な障害を引き起こす可能性がある大きな災害の場合には、VM/ディスクを完全に保護できない場合があります。 このような大規模な障害には、データセンターがハリケーン、地震、火災に襲われた場合や、大規模なハードウェア ユニットの障害が発生した場合などの大惨事が含まれます。 さらに、アプリケーションやデータの問題による障害が発生する可能性もあります。

IaaS ワークロードを障害から保護するには、回復を可能にする冗長性とバックアップの計画を立てる必要があります。 ディザスター リカバリーのためには、プライマリ サイトから地理的に離れた別の場所でバックアップをとる必要があります。 この方法によって、VM またはディスクに最初に影響したものと同じ出来事がバックアップに影響することはなくなります。 詳細については、「Disaster recovery for Azure applications (Azure アプリケーションのディザスター リカバリー)」をご覧ください。

DR の考慮事項には、次の側面が含まれます。

  • 高可用性: 大幅なダウンタイムなしに、正常な状態で実行を継続するアプリケーションの能力です。 "正常な状態" とは、アプリケーションが応答し、ユーザーがアプリケーションに接続して対話できるという意味です。 特定のミッション クリティカルなアプリケーションとデータベースは、プラットフォームに障害が発生した場合でも、常に使用可能であることが求められます。 これらのワークロードについては、データだけでなく、アプリケーションの冗長性を計画する必要があります。

  • データの持続性: 主な検討事項が、災害が発生した場合にも確実にデータを保持することである場合もあります。 そのため、別のサイトでデータをバックアップする必要があるかもしれません。 このようなワークロードの場合、アプリケーションの完全な冗長性の必要はなく、ディスクの定期的なバックアップのみが必要となります。

バックアップと DR シナリオ

アプリケーション ワークロードのシナリオの一般的ないくつかの例と、ディザスター リカバリー計画に関する検討事項について考えてみましょう。

シナリオ 1: 大規模なデータベースのソリューション

高可用性をサポートできる SQL Server または Oracle のような実稼働データベース サーバーについて考えてみます。 重要な実稼働アプリケーションとユーザーは、このデータベースに依存しています。 このシステムのディザスター リカバリー計画は、次の要件をサポートする必要があります。

  • データは保護され、かつ回復可能である必要があります。
  • サーバーは使用可能である必要があります。

ディザスター リカバリー計画では、異なるリージョンにバックアップとしてデータベースのレプリカを維持する必要があります。 サーバーの可用性とデータ復旧の要件によっては、アクティブ/アクティブ レプリカ サイトまたはアクティブ/パッシブ レプリカ サイトから、データの定期的なオフライン バックアップまでに及ぶソリューションが考えられます。 SQL Server、Oracle などのリレーショナル データベースでは、レプリケーションに関するさまざまなオプションが提供されています。 SQL Server では、高可用性を実現するために、SQL Server AlwaysOn 可用性グループを使用します。

MongoDB のような NoSQL データベースでは、冗長性を実現するためにレプリカもサポートされています。 高可用性向けのレプリカが使用されます。

シナリオ 2: 冗長 VM のクラスター

冗長性と負荷分散を提供する VM クラスターによって処理されるワークロードを検討します。 一例として、リージョンにデプロイされた Cassandra クラスターがあります。 このタイプのアーキテクチャは、リージョン内で高レベルの冗長性を既に提供しています。 ただし、リージョン レベルの障害からワークロードを保護するには、クラスターを 2 つのリージョンに分散させるか、別のリージョンに定期的なバックアップを実行することを検討する必要があります。

シナリオ 3: IaaS アプリケーション ワークロード

IaaS アプリケーション ワークロードを見てみましょう。 たとえば、Azure VM で実行されている一般的な実稼働ワークロードが考えられます。 あるサイトのコンテンツと他のリソースを保持している Web サーバーまたはファイル サーバーが考えられます。 また、データ、リソース、アプリケーション状態などを VM ディスクに格納し、VM 上で実行されるカスタムビルドのビジネス アプリケーションかもしれません。 この場合は、定期的なバックアップを確実に行うことが重要です。 バックアップの頻度は、VM のワークロードの特性に基づいている必要があります。 たとえば、アプリケーションが毎日実行されてデータを変更している場合は、1 時間ごとにバックアップをとる必要があります。

別の例は、他のソースからデータをプルして集計レポートを生成するレポート サーバーです。 この VM やディスクが失われると、レポートが失われることがあります。 ただし、レポート プロセスを再実行し、出力を再生成できる場合があります。 その場合は、レポート サーバーが災害に遭っても、実際にはデータは失われません。 その結果、レポート サーバー上のデータの部分的な消失に対しては、耐性が高くなります。 その場合は、バックアップの頻度を下げることが、コスト削減の方法の 1 つになります。

シナリオ 4: IaaS アプリケーション データの問題

IaaS アプリケーション データの問題も別の可能性として存在します。 価格情報などの重要な商用データを計算し、保守し、提供するアプリケーションについて考えます。 新しいバージョンのアプリケーションには、価格を誤って計算するソフトウェア バグがあり、プラットフォームによって提供される既存の商用データが破損しました。 ここでの最善策は、アプリケーションとデータを以前のバージョンに戻すことです。 これを可能にするには、定期的にシステムのバックアップをとります。

ディザスター リカバリー ソリューション: Azure Backup

Azure Backup はバックアップとディザスター リカバリーに使用され、マネージド ディスクやアンマネージド ディスクと連携します。 時間ベースのバックアップ、VM の簡易復元、バックアップの保持ポリシーを使用して、バックアップ ジョブを作成することができます。

Premium SSD、マネージド ディスク、またはその他のディスクの種類を、ローカル冗長ストレージ オプションと共に使用する場合は、定期的な DR バックアップを行うことが特に重要です。 Azure Backup は、長期的に保有するためにデータを Recovery Services コンテナーに格納します。 バックアップの Recovery Services コンテナーには、geo 冗長ストレージ オプションを選択します。 このオプションにより、バックアップが別の Azure リージョンにレプリケートされ、地域的な災害から保護されます。

アンマネージド ディスクについては、IaaS ディスクの場合はローカル冗長ストレージ タイプを使用できますが、Recovery Services コンテナーの場合は、Azure Backup を geo 冗長ストレージ オプションで有効にしてください。

注意

非管理対象ディスクに対して geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージ オプションを使用する場合は、バックアップと DR の整合性スナップショットが必要です。 Azure Backup または整合性スナップショットを使用します。

DR に使用可能なソリューションの概要を次の表に示します。

シナリオ 自動レプリケーション DR ソリューション
Premium SSD ディスク ローカル (ローカル冗長ストレージ) Azure Backup
マネージド ディスク ローカル (ローカル冗長ストレージ) Azure Backup
非管理対象ローカル冗長ストレージ ディスク ローカル (ローカル冗長ストレージ) Azure Backup
非管理対象 geo 冗長ストレージ ディスク リージョン間 (geo 冗長ストレージ) Azure Backup
整合性スナップショット
非管理対象読み取りアクセス geo 冗長ストレージ ディスク リージョン間 (読み取りアクセス geo 冗長ストレージ) Azure Backup
整合性スナップショット

高可用性は、可用性セット内のマネージド ディスクを Azure Backup と共に使用することで最もよく対応できます。 非管理対象ディスクを使用する場合は、DR 用 Azure Backup を使用できます。 Azure Backup を使用できない場合、後のセクションで説明するように、整合性スナップショットを利用することがバックアップと DR の代替ソリューションとなります。

アプリケーションまたはインフラストラクチャ レベルでの高可用性、バックアップ、DRの選択は、次のように表すことができます。

レベル 高可用性 バックアップまたは DR
アプリケーション SQL Server AlwaysOn Azure バックアップ
インフラストラクチャ 可用性セット 整合性スナップショットと geo 冗長ストレージ

Azure Backup の使用

Azure Backup では、Azure Recovery Services コンテナーに Windows または Linux を実行する VM をバックアップできます。 業務に不可欠なデータのバックアップと復元は、その生成元となるアプリケーションの実行中にバックアップを行う必要があるため、簡単ではありません。

この課題に対処するために、Azure Backup は、Microsoft のワークロードに対してアプリケーション整合性バックアップを提供します。 ボリューム シャドウ サービスを使用して、データがストレージに正しく書き込まれるようにします。 Linux には Windows のボリューム シャドウ サービスに相当する機能がないため、Linux VM では、既定のバックアップ整合性モードはファイル整合バックアップです。 Linux マシンについては、「Azure Linux VM のアプリケーション整合性バックアップ」を参照してください。

Azure Backup flowAzure Backup のフロー

Azure Backup がスケジュールされた時刻にバックアップ ジョブを開始すると、VM にインストールされたバックアップ拡張機能をトリガーして特定の時点のスナップショットを作成します。 スナップショットはボリューム シャドウ サービスと連携して作成されるため、シャットダウンせずに、仮想マシンに使用されているディスクの一貫したスナップショットを取得することができます。 VM のバックアップの拡張機能は、すべての書き込みをフラッシュした後に、すべてのディスクの整合性スナップショットを作成します。 スナップショットが作成されると、データは Azure Backup によってバックアップ コンテナーに転送されます。 バックアップ プロセスの効率を高めるために、前回のバックアップ以降に変更されたデータ ブロックがサービスによって特定され、そのデータのみが転送されます。

復元するには、Azure Backup を使用して使用可能なバックアップを表示し、復元を開始します。 Azure Portal 経由で、PowerShell を使用して、または Azure CLI を使用して、Azure バックアップを作成および復元できます。

バックアップを有効にする手順

Azure Portal を使用して VM のバックアップを有効にするには次の手順に従います。 実際のシナリオに応じて、いくつかのバリエーションがあります。 完全な詳細情報については、Azure Backupに関するドキュメントをご覧ください。 Azure Backup はマネージド ディスクを使用する VM もサポートします。

  1. VM 用の Recovery Services コンテナーを作成する:

    a. Azure Portal を使用して、すべてのリソースを参照し、「Recovery Services コンテナー」を検索します。

    b。 Recovery Services コンテナー メニューで、 [追加] をクリックし、VM と同じリージョンで新しいコンテナーを作成する手順に従います。 たとえば、VM が米国西部リージョンにある場合は、コンテナーに米国西部を選択します。

  2. 新しく作成されたコンテナーのストレージ レプリケーションを確認します。 [Recovery Services コンテナー] でコンテナーにアクセスし、 [プロパティ]>[バックアップ構成]>[更新] に移動します。 [geo 冗長ストレージ] オプションが既定で選択されていることを確認します。 このオプションを選択すると、コンテナーがセカンダリ データセンターに自動的にレプリケートされます。 たとえば、米国西部のコンテナーは、米国東部に自動的にレプリケートされます。

  3. バックアップ ポリシーを構成し、同じ UI から VM を選択します。

  4. Backup エージェントが VM にインストールされていることを確認します。 VM が Azure ギャラリー イメージを使用して作成されている場合、Backup エージェントは既にインストールされています。 それ以外の場合は (つまりカスタム イメージを使用する場合)、仮想マシンに VM エージェントをインストールする手順を使用します。

  5. 上記の手順を完了すると、バックアップ ポリシーで指定されているとおり、バックアップが定期的に実行されます。 必要に応じて、Azure Portal のコンテナー ダッシュボードから、最初のバックアップを手動でトリガーできます。

スクリプトを使用した Azure Backup の自動化については、VM バックアップ用の PowerShell コマンドレットに関するページをご覧ください。

回復の手順

VM を修復またはリビルドする必要がある場合は、コンテナーのバックアップ復旧ポイントのいずれかから VM を復元できます。 復旧の実施方法には 2 つのオプションがあります。

  • 特定の時点のバックアップ VM として、新しい VM を作成できます。

  • ディスクを復元した後に VM のテンプレートを使用して、復元された VM をカスタマイズし、リビルドすることができます。

詳細については、「Azure Portal を使用した仮想マシンの復元」の手順をご覧ください。 このドキュメントでは、プライマリ データセンターの災害の場合に、geo 冗長バックアップ コンテナーを使用して、対となるデータセンターに VM のバックアップを復元するための特定の手順も説明します。 その場合、Azure Backup では、セカンダリ リージョンからコンピューティング サービスを使用して、復元された仮想マシンを作成します。

また、復元されたディスクからの新しい VM の作成には、PowerShell を使用できます。

代替のソリューション: 整合性スナップショット

Azure Backup を使用できない場合は、スナップショットを使用して、独自のバックアップ メカニズムを実装できます。 VM で使用されるすべてのディスクの整合性スナップショットを作成し、そのスナップショットを別のリージョンにレプリケートする方法は複雑です。 このため、Azure では、バックアップ サービスの使用はカスタム ソリューションの構築よりも良いオプションであると考えています。

ディスクの読み取りアクセス geo 冗長ストレージ/geo 冗長ストレージを使用する場合、スナップショットはセカンダリ データセンターに自動的にレプリケートされます。 ディスクのローカル冗長ストレージを使用する場合は、自分でデータをレプリケートする必要があります。 詳細については、「増分スナップショットを使用した Azure 非管理 VM ディスクのバックアップ」をご覧ください。

スナップショットは、特定の時点におけるオブジェクトを表現したものです。 スナップショットによって、保持しているデータのサイズの増分に対する請求が発生します。 詳細については、「BLOB のスナップショットの作成」をご覧ください。

VM の実行中にスナップショットを作成する

スナップショットはいつでも取得可能ですが、VM を実行している場合は、ディスクに送信されている最中のデータが存在します。 そのため、スナップショットには実行中のオペレーションが部分的に含まれる場合があります。 また、複数のディスクが対象となっている場合は、それぞれのディスクのスナップショットが異なる時刻に取得された可能性があります。 このようなシナリオでは、スナップショットが調整されないことがあります。 このような調整がない場合、バックアップ中に変更が行われた場合にファイルが破損する可能性があるストライプ ボリュームでは、特に問題です。

この状況を避けるために、バックアップ プロセスで次の手順を実施する必要があります。

  1. すべてのディスクを凍結します。

  2. 保留中のすべての書き込みをフラッシュします。

  3. すべてのディスクの BLOB スナップショットを作成します。

SQL Server などの一部の Windows アプリケーションは、アプリケーション整合性バックアップを作成するボリューム シャドウ サービスを通して、連携のとれたバックアップ メカニズムを提供します。 Linux では、ディスクを調整するために fsfreeze などのツールを使用できます。 このツールはファイル整合性バックアップを提供していますが、アプリケーション整合性スナップショットは提供していません。 このプロセスは複雑なため、Azure Backup を使用するか、既にこの手順を実装しているサード パーティーのバックアップ ソリューションを使用することを検討する必要があります。

上記のプロセスによって、すべての VM ディスクに対する連携のとれた一連のスナップショットが生成されます。これは、特定の時点の VM の状態を表します。 これが、VM のバックアップの復元ポイントです。 スケジュールされた間隔で処理を繰り返し、定期的にバックアップを作成できます。 DR のためにスナップショットを別のリージョンにコピーする手順については、「スナップショットを別のリージョンにコピーする」をご覧ください。

VM がオフラインのときにスナップショットを作成する

整合性バックアップを作成する別のオプションは、VM をシャット ダウンし、各ディスクの BLOB スナップショットを作成することです。 BLOB スナップショットの作成は、実行中の VM のスナップショットの連携よりも簡単ですが、数分間のダウンタイムが必要です。

  1. VM をシャット ダウンします。

  2. 各仮想ハード ドライブ BLOB のスナップショットを作成します。これにはほんの数秒しかかかりません。

    スナップショットを作成するには、PowerShell、Azure Storage REST API、Azure CLI、または .NET 用 ストレージ クライアント ライブラリなどの Azure Storage クライアント ライブラリのいずれかを使用できます。

  3. VM を起動します。これによってダウンタイムが終了します。 通常、プロセス全体が数分以内に完了します。

このプロセスによって、すべてのディスクに対する一連の整合性スナップショットが生成され、VM のバックアップの復元ポイントが得られます。

スナップショットを別のリージョンにコピーする

スナップショットを作成しただけでは、DR には不十分です。 別のリージョンにスナップショット バックアップをレプリケートする必要もあります。

ディスクの geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージを使用する場合、スナップショットはセカンダリ リージョンに自動的にレプリケートされます。 レプリケーション前に数分の遅延が発生する可能性があります。 スナップショットのレプリケートが完了する前にプライマリ データセンターがダウンした場合は、セカンダリ データセンターからスナップショットにアクセスすることはできません。 この可能性は低いです。

注意

geo 冗長ストレージ アカウントまたは読み取りアクセス geo 冗長ストレージ アカウントにディスクを持っているだけでは、VM は障害から保護されません。 ユーザーは、連携のとれたスナップショットを作成するか、Azure Backup を使用する必要もあります。 これは、VM を整合性のある状態に回復するために必要です。

ローカル冗長ストレージを使用する場合は、スナップショットを作成した後、別のストレージ アカウントにスナップショットをすぐにコピーする必要があります。 コピーのターゲットは、異なるリージョンのローカル冗長ストレージ ストレージ アカウントであり、結果的にリモート リージョンのコピーになります。 同じリージョン内の読み取りアクセス geo 冗長ストレージ アカウントにスナップショットをコピーすることもできます。 この場合、スナップショットはリモート セカンダリ リージョンにゆっくりとレプリケートされます。 コピーとレプリケーションが完了すると、バックアップはプライマリ サイトの障害から保護されます。

DR 用の増分スナップショットを効率的にコピーするには、「増分スナップショットを使用した Azure 非管理 VM ディスクのバックアップ」の手順を確認してください。

Back up Azure unmanaged VM disks with incremental snapshots増分スナップショットを使用した Azure 非管理 VM ディスクのバックアップ

スナップショットからの復旧

スナップショットを取得するには、スナップショットをコピーして新しい BLOB を作成します。 プライマリ アカウントからスナップショットをコピーする場合は、スナップショットをスナップショットのベース BLOB にコピーできます。 このプロセスにより、ディスクがスナップショットに戻ります。 このプロセスは、スナップショットの昇格として知られています。 読み取りアクセス geo 冗長ストレージ アカウントでセカンダリ アカウントからスナップショット バックアップをコピーする場合は、プライマリ アカウントにコピーする必要があります。 PowerShell を使用して、または AzCopy ユーティリティを使用して、スナップショットをコピーすることができます。 詳細については、AzCopy コマンド ライン ユーティリティを使用したデータの転送に関するページをご覧ください。

複数のディスクを持つ VM の場合は、連携のとれた同じ復元ポイントの一部であるスナップショットをすべてコピーする必要があります。 書き込み可能な VHD BLOB にスナップショットをコピーしたら、BLOB を使用して、VM のテンプレートを利用して VM を再作成できます。

その他のオプション

SQL Server

VM で実行されている SQL Server には、SQL Server データベースを Azure Blob Storage やファイル共有にバックアップする独自の組み込み機能があります。 ストレージ アカウントが geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージである場合は、障害発生時にストレージ アカウントのセカンダリ データセンターにあるバックアップにアクセスできます。前述したものと同じ制約があります。 詳細については、「Azure Virtual Machines における SQL Server のバックアップと復元」をご覧ください。 バックアップと復元に加えて、SQL Server AlwaysOn 可用性グループではデータベースのセカンダリ レプリカを管理できます。 この機能により、ディザスター リカバリーの時間が大幅に短縮されます。

その他の考慮事項

この記事では、ディザスター リカバリーをサポートするために、VM とそのディスクのバックアップやスナップショットを取得する方法と、そのバックアップまたはスナップショットを使用してデータを復旧する方法について説明しました。 Azure Resource Manager モデルでは、多くのユーザーはテンプレートを使用して、Azure で各自の VM とその他のインフラストラクチャを作成します。 テンプレートを使用すると、毎回同じ構成を持つ VM を作成できます。 VM の作成にカスタム イメージを使用する場合は、イメージを格納する読み取りアクセス geo 冗長ストレージ アカウントを使用して、イメージが保護されていることも確認する必要があります。

そのため、バックアップ プロセスには次の 2 つの組み合わせがあります。

  • データ (ディスク) をバックアップします。
  • 構成 (テンプレートとカスタム イメージ) をバックアップします。

選択したバックアップ オプションに応じて、ユーザーがデータと構成の両方のバックアップを処理する必要があるか、バックアップ サービスがすべてを処理します。

付録: データの冗長性の影響を理解する

Azure のストレージ アカウントについては、ディザスター リカバリーに関して考慮すべき 3 種類のデータの冗長性があります。すなわち、ローカル冗長、geo 冗長、読み取りアクセスを伴う geo 冗長です。

ローカル冗長ストレージには、同じデータセンター内のデータのコピーが 3 つ保持されています。 VM がデータを書き込むと、3 つのすべてのコピーが更新され、処理が成功したことが呼び出し元に返されるため、3 つが同じものであることがわかります。 3 つのすべてのコピーが同時に影響を受ける可能性は低いため、ディスクは局所的な障害から保護されています。 ローカル冗長ストレージの場合は geo 冗長性がないため、データセンター全体またはストレージ ユニット全体に影響するような壊滅的な障害からは、ディスクは保護されていません。

geo 冗長ストレージと読み取りアクセス geo 冗長ストレージでは、データの 3 つのコピーはユーザーが選択したプライマリ リージョンに保持されます。 さらに 3 つのデータのコピーが、Azure 側で設定された対応するセカンダリ リージョンに保持されます。 たとえば、米国西部にデータを格納する場合、データは米国東部にレプリケートされます。 コピーの保持は非同期で行われ、プライマリ サイトとセカンダリ サイトの更新の間には小さな遅延が発生します。 セカンダリ サイト上のディスクのレプリカにはディスクごとに一貫性がありますが (遅延あり)、複数のアクティブなディスクのレプリカは、互いに同期していない可能性があります。 複数のディスクにわたって一貫性のあるレプリカを持つには、一貫性のあるスナップショットが必要です。

geo 冗長ストレージと読み取りアクセス geo 冗長ストレージの主な違いは、読み取りアクセス geo 冗長ストレージを使えば、セカンダリ コピーをいつでも読み取ることができる点です。 プライマリ リージョンのデータにアクセスできない問題がある場合、Azure チームはデータへのアクセスを復元するために、あらゆる努力をします。 プライマリがダウンしていても、読み取りアクセス geo 冗長ストレージを有効にした場合は、セカンダリ データセンターのデータにアクセスできます。 そのため、プライマリにアクセスできないときにレプリカから読み取る計画である場合は、読み取りアクセス geo 冗長ストレージを検討する必要があります。

重大な停止であることが判明した場合、Azure チームは geo フェールオーバーをトリガーし、プライマリ DNS エントリを変更して 2 次記憶装置を指すようにすることができます。 この時点でgeo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージが有効になっている場合は、セカンダリとして使用されていたリージョンのデータにアクセスできます。 つまり、ストレージ アカウントが geo 冗長ストレージであり、かつ問題が発生する場合は、geo フェールオーバーを実行する場合にのみ、2 次記憶装置にアクセスできます。

詳細については、「Azure Storage の停止が発生した場合の対処方法」をご覧ください。

次のステップ

「Azure の非管理対象の仮想マシン ディスクを増分スナップショットでバックアップする」を参照してください。