Azure Backupの信頼性

Azure Backup は、クラウドとオンプレミスのワークロードを安全に保護する組み込みのAzure サービスです。 バックアップは、複数のワークロードにわたる保護をスケーリングでき、Azureのワークロードとネイティブに統合します。統合されるサービスには、仮想マシン (VM)、Azure VM での SAP HANA、Azure VM の SQL、Azure Files、Azure Blob Storage、Azure Data Lake Storage、Azure マネージド ディスク、Azure Elastic SAN ボリューム、および Azure Kubernetes Service (AKS) が含まれます。 自動化やインフラストラクチャの管理、スクリプトの記述、ストレージのプロビジョニングは必要ありません。

Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対するバックアップの回復性について説明します。 また、バックアップ サービス レベル アグリーメント (SLA) に関する重要な情報も示します。

信頼性のための運用環境のデプロイに関する推奨事項

運用ワークロードをバックアップするには、次の方法でボールトを構成することをお勧めします。

この記事の以降のセクションでは、これらの構成について詳しく説明します。

信頼性に重点を置いた推奨事項など、バックアップに関するその他の推奨事項の一覧については、「 クラウドとオンプレミスのワークロードをクラウドにバックアップする」を参照してください。

信頼性アーキテクチャの概要

このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。

論理アーキテクチャ

バックアップでは、さまざまな データ ソースをバックアップおよび復元できます。 バックアップは、操作するデータ ソースによって異なる方法で構成します。 次のデータ ソースが一般的です。

• Azure の VM
• さまざまなデータベース
• Blob Storage アカウント
• AKS クラスター
• Microsoft Azure Recovery Services (MARS) エージェントを介したオンプレミス サーバー

バックアップでは、バックアップされたデータがコンテナーに格納 されます。 コンテナーは、バックアップ コピー、復旧ポイント、バックアップ ポリシーなどのデータを保持する、Azure内のオンライン ストレージ エンティティです。 Recovery Services ボールト と バックアップ ボールト は、2 種類のボールトです。 保護する必要がある内容に応じて、一方または両方の型を使用できます。 各コンテナーの種類でサポートされるデータ ソースの一覧については、 バックアップと復元でサポートされているコンテナーに関する FAQ を参照してください。

ジョブ は、データのバックアップまたは復元のアクティビティを表します。 バックアップ ジョブには、ソースから保管庫にデータをコピーするスケジュールされた操作またはオンデマンド操作が含まれます。 復元ジョブには、バックアップ ストレージからターゲットの場所にデータを回復する操作が含まれます。 各ジョブには一意の識別子と状態の追跡があるため、進行状況を監視し、バックアップ操作と復元操作中に発生する問題のトラブルシューティングを行うことができます。 ジョブに関連付けられている バックアップ ポリシー も作成します。 ポリシーでは、バックアップ スケジュールやデータを保持する期間などの構成を指定します。

コンテナーには、バックアップ ポリシーと構成と、ジョブに関するメタデータが格納されます。これにより、ジョブを追跡したり、トラブルシューティングを行うことができます。

物理アーキテクチャ

Microsoftは、コア バックアップ サービス インフラストラクチャを管理します。 このインフラストラクチャは、ジョブのトリガーや監視など、サービスの管理と運用を担当します。

バックアップは保管庫に格納されます。 ボールトは、Azure Storageを基盤にして構築されています。 コンテナーはバックアップ データを自動的にレプリケートします。バックアップの持続性と回復性は、コンテナーのストレージの冗長性によって異なります。

• ローカル冗長ストレージ (LRS) は、コンテナー内のデータを、選択したプライマリ リージョンにある 1 つ以上のAzure可用性ゾーンにレプリケートします。 優先する可用性ゾーンを選択することはできませんが、Azureは、負荷分散を向上させるために、ゾーン間で LRS アカウントを移動または拡張する可能性があります。 データがゾーン間で分散されるとは限りません。 詳細については、「 可用性ゾーンの概要」を参照してください。

• ZRS と GRS により、追加の保護が提供されます。 この記事では、これらのオプションについて詳しく説明します。

一時的な障害に対する回復性

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされているすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure一時的な障害処理ガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

バックアップを使用する場合、バックアップワークフローと復元ワークフローの両方が断続的な障害に対する回復性を備えています。 サービスは、一時的なネットワーク 障害または一時的なサービスの中断が発生したときに自動的に再試行します。 再試行ロジックは構成しません。 障害が繰り返し発生する場合は、「 バックアップ コンテナーの管理操作のトラブルシューティング」を参照してください。

可用性ゾーンの障害に対する回復性

Availability zones は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

バックアップでは、サービスとデータの可用性ゾーンの構成を個別に管理します。

• サービス： バックアップ サービスは、サポートされているリージョンで自動的にゾーン回復性を備えています。 ただし、この組み込みのゾーンの回復性は、バックアップされたデータには適用されません。

• バックアップ ストレージの冗長性: Recovery Services コンテナーまたは Backup コンテナーを構成して、バックアップ データに必要な冗長性のレベルを選択します。 ZRS を選択した場合、バックアップ データのコピーは、使用するAzure リージョン内の複数の可用性ゾーンに自動的に格納されます。

  ZRS を使用しない場合、バックアップ データは 非ゾーン と見なされ、任意のゾーンに格納される可能性があります。 リージョン内のゾーンに問題がある場合は、非ゾーン バックアップ データが使用できない可能性があります。

Requirements

• リージョンのサポート: サービスは、可用性ゾーンを 持つすべてのリージョンで自動的にゾーン回復性があります。 ZRS ボールトは、同じリージョンでサポートされています。

• 新しいコンテナーのみ: 最初のバックアップの前に、コンテナーで ZRS を構成します。

費用

バックアップに対して ZRS を有効にすると、レプリケーションとストレージのオーバーヘッドが増えるため、LRS とは異なるレートで課金されます。 詳細については、「 バックアップの価格」を参照してください。

可用性ゾーンのサポートを設定する

• ZRS を使用する新しいコンテナーを作成します 。コンテナーの作成時にストレージの冗長性を構成します。 ボールトの種類に応じて異なる手順を踏みます。 詳細については、次の記事を参照してください。

  • バックアップ コンテナーの作成と削除
  • Recovery Services 保管庫を作成して構成する

• 既存のコンテナーで ZRS を構成します。 バックアップ コンテナーの場合は、コンテナーの作成時にストレージの冗長性を構成します。 バックアップ コンテナーを作成すると、設定はロックされ、変更することはできません。

  Recovery Services コンテナーの場合は、ワークロードを保護する前にストレージの冗長性を構成する必要があります。 ワークロードを保護すると、設定はロックされ、変更することはできません。

  ZRS を使用するように構成された新しいコンテナーを作成し、ワークロードを新しいコンテナーに再割り当てできます。 ただし、この方法ではダウンタイムが必要です。 詳細については、「既定の 設定を変更する」を参照してください。 古いボールトの保持ポリシーが適用されなくなったため、既存のリカバリポイントやその他のデータを手動で削除する責任もあります。 詳細については、「 バックアップ コンテナーの削除 」または「 Recovery Services コンテナーの削除」を参照してください。

すべてのゾーンが正常な場合の動作

このセクションでは、ZRS 用にボルトを構成し、すべてのゾーンが運用されている状態で期待されることについて説明します。

• ゾーン間操作: バックアップ ジョブは、ゾーン間でレプリケートされたインフラストラクチャで実行されます。 Azureは、任意のゾーンのインフラストラクチャからのジョブを管理します。

• ゾーン間データ レプリケーション: ZRS は、バックアップされたデータをゾーン間でレプリケートします。 レプリケーションは同期的に行われます。つまり、完了する前に、複数のゾーンが各書き込み操作を確認します。

ゾーン障害時の動作

このセクションでは、ZRS 用にバルツを構成し、いずれかのゾーンで障害が発生した場合に予期されることについて説明します。

• 検出と応答: バックアップ サービス自体の場合、Microsoftは可用性ゾーンでの障害の検出と応答を担当します。 ゾーンのフェールオーバーを開始するために何もする必要はありません。

  Important

  ゾーンの停止が原因で使用できないデータまたはリソースについては、障害を検出し、正常なゾーンへのバックアップの復元を含む復旧アクションを実行する必要があります。

• Notification: ゾーンがダウンしても、Microsoftから自動的に通知は行われません。 ただし、Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Healthアラートを設定して問題を通知することができます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。

• アクティブな要求: アクティブなジョブの動作は、失敗するゾーンによって異なります。

  • 障害が発生した可用性ゾーン内のデータ ソースの場合、ゾーンの障害によってデータ ソースが使用できなくなります。 アクティブなジョブは一時停止または失敗する可能性があります。

  • アクティブなジョブを実行する正常な可用性ゾーン内のデータ ソースでは、プラットフォームがバックアップ サービスの正常な可用性ゾーンに切り替わる間に、少量のダウンタイム (通常は数秒) が発生する可能性があります。

• 予想されるデータ損失: 予想されるデータ損失量は、 目標復旧ポイント (RPO) とも呼ばれます。 バックアップ データの RPO は、バックアップ スケジュールなど、複数の要因によって異なります。 一般に、ゾーンの停止では、すべてのデータがゾーン間で同期的にレプリケートされるため、バックアップされたデータの損失は予想されません。

• 予想されるダウンタイム: 予想されるダウンタイムの量は、 目標復旧時間 (RTO) とも呼ばれます。 RTO は、次のシナリオごとに異なります。

  • 障害が発生した可用性ゾーン内のデータ ソースの場合、ゾーンが復旧するまでデータ ソースを使用できない場合があります。 データ ソースが再び使用可能になるまで、バックアップ ジョブの実行に失敗する場合があります。 RTO は未定義です。

  • 正常な可用性ゾーン内のデータ ソースの場合、プラットフォームがバックアップ サービスの正常な可用性ゾーンに切り替わる間、わずかなダウンタイム (通常は数秒) が発生する可能性があります。

• 再 分配： 後続のジョブ実行では、データ ソースが使用可能な限り、正常なゾーンのインフラストラクチャが自動的に使用されます。

  バックアップを正常なゾーンのインフラストラクチャに復元し、新しいゾーンの正常なインフラストラクチャにトラフィックをリダイレクトするようにロード バランサー、クライアント、その他のシステムを再構成する責任があります。

ゾーンの回復

可用性ゾーンが復旧すると、Backup によって可用性ゾーン内の操作が自動的に復元され、通常どおりゾーン間のトラフィックが再ルーティングされます。 ジョブは引き続き実行され、データは引き続き使用できます。

ゾーンエラーのテスト

Backup プラットフォームは、トラフィック ルーティング、データ レプリケーション、フェールオーバー、フェールバックを管理します。 この機能はフル マネージドであるため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。

リージョン全体の障害に対する回復性

バックアップでは、GRS と CRR を介した geo 冗長性とフェールオーバーがサポートされます。

地理的冗長ストレージとリージョン間の復元

バックアップ データのリージョン冗長を実現するには、GRS を使用して、バックアップを Azure ペア リージョン にレプリケートします。 GRS は、リージョンの障害からバックアップを保護します。

ボールトをデプロイするリージョンは、プライマリ リージョンと呼ばれます。 データ ソースは、プライマリ リージョンに配置する必要があります。 他のリージョンのボールトにバックアップを構成することはできません。

ペアになっているリージョンは、 セカンダリ リージョンとも呼ばれます。

GRS を構成せず、コンテナーのリージョンで停止が発生した場合は、コンテナーにアクセスしてバックアップ項目を表示できる可能性があります。 ただし、リージョンの冗長性がなければ、基になるバックアップ データは復元操作で使用できなくなります。

リージョン間の復元

ボールトで GRS を構成すると、プライマリ リージョンで障害が発生した後、Microsoft はペア リージョンのバックアップを利用可能にします。 データ ソースが CRR をサポートしている場合は、プライマリ リージョンで障害が発生しない場合でも、セカンダリ リージョンの復旧ポイントから復元できます。 CRR を使用すると、訓練を実行して、リージョンの停止に対する回復性を評価することもできます。 CRR を有効にすると、バックアップ ストレージが Microsoft の GRS から読み取りアクセス可能な geo 冗長ストレージ (RA-GRS) にアップグレードされます。

Requirements

• Region サポート: GRS for Backup は、ペアのAzure リージョン内でのみ機能します。

• 新しいコンテナーのみ: 最初のバックアップが行われる前に、コンテナーで GRS を構成する必要があります。

考慮事項

• CRR: CRR を有効にすると、バックアップ項目がセカンダリ リージョンで使用できるようになるまでに最大 48 時間かかることがあります。

費用

GRS コンテナーでは、セカンダリ リージョン内のリージョン間レプリケーションとストレージに対して追加のコストが発生します。 Azure リージョン間のデータ転送は、標準のリージョン間帯域幅レートに基づいて課金されます。 MicrosoftがボールトのストレージをGRSからRA-GRSにアップグレードしたため、CRRは異なる料金が課金されます。 詳細については、「 バックアップの価格」を参照してください。

複数リージョンのサポートを構成する

• GRS と CRR を使用する新しいコンテナーを作成します 。コンテナーを作成するときは、ストレージの冗長性も構成する必要があります。 GRS を選択した後、必要に応じてボールトで CRR を有効にすることができます。 実行する手順は、ボルトの種類によって異なります。 詳細については、次の記事を参照してください。

  • バックアップ コンテナーの作成と削除
  • Recovery Services 保管庫を作成して構成する

• 既存のコンテナーで GRS と CRR を構成します。 バックアップ コンテナーの場合は、コンテナーの作成時にストレージの冗長性を構成する必要があります。

  Recovery Services コンテナーの場合は、ワークロードを保護する前にストレージの冗長性を構成する必要があります。 ワークロードが保護されると、設定はロックされ、変更することはできません。

  既存の GRS ボールトで CRR を有効にすることができます。 CRR を有効にした後は、無効にすることはできません。

すべてのリージョンが正常な場合の動作

このセクションでは、ボールトを GRS 対応に構成し、すべてのリージョンが運用中の場合に期待される内容について説明します。

• リージョン間操作: バックアップは、コンテナーとデータ ソースがデプロイされているリージョンであるプライマリ リージョンで常に完了します。

• リージョン間データ レプリケーション: GRS を使用するようにコンテナーを構成すると、最初に LRS を使用してバックアップがプライマリ リージョンにコミットされます。 プライマリ リージョンで正常に完了すると、データはセカンダリ リージョンに非同期的にレプリケートされます。 セカンダリ リージョンでは、LRS を使用してデータが格納されます。 バックアップ データは、プライマリ リージョンからセカンダリ リージョンにレプリケートされるまでに最大 12 時間かかる場合があります。

リージョン障害時の動作

このセクションでは、GRS を使用するように暗号庫を構成し、プライマリ リージョンで停電が発生した場合に想定される内容について説明します。

• 検出と応答: CRR をサポートし、ボールトで CRR が有効になっているデータ ソースの場合、リージョンの停止や障害時を含め、ペアになっているリージョンに対して独自の CRR をいつでも開始できます。 障害を検出し、正常なリージョンにバックアップを復元するなど、復旧アクションを実行する必要があります。

  その他のすべてのシナリオでは、セカンダリリージョンに複製されたデータは、Azureがプライマリ リージョンで障害を宣言した場合にのみ、セカンダリリージョンで復元できます。 Microsoftは災害の宣言を担当します。 災害の宣言にかかる時間は、インシデントの重大度と状況の評価に必要な時間によって異なります。 Microsoftは通常、長期間経過した後にのみディザスターを宣言します。

• Notification: Microsoftは、リージョンがダウンしたときに自動的にユーザーに通知しません。 しかし：

  • Azure Resource Health を使用して個々のリソースの正常性を監視し、Resource Health アラートを設定して問題を通知できます。

  • Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知できます。

• 予想されるデータ損失: バックアップ データの RPO は、バックアップ スケジュールなど、複数の要因によって異なります。 一般に、リージョンの停止の場合、プライマリ リージョンの RPO は 24 時間であり、プライマリ リージョンからセカンダリ リージョンへのバックアップ データのレプリケートには最大 12 時間かかるため、最大 36 時間のデータ損失が予想されます。

• 予想されるダウンタイム: RTO は、次のシナリオごとに異なります。

  • 障害が発生したリージョン内のデータ ソースやその他のリソースは、リージョンが復旧するまで使用できない可能性があるため、RTO は未定義です。

  • バックアップは、リージョンが復旧するまで、障害が発生したリージョンでバックアップ操作または復元操作を実行できない可能性があるため、RTO は未定義です。

  • CRR を使用する場合、ペアになっているリージョンに既にレプリケートされているバックアップの復元を開始するための RTO は 0 です。 CRR を使用しない場合、RTO は、障害が発生したリージョンでMicrosoftがディザスターを宣言するのにかかる時間によって異なります。

• 再 分配： プライマリ リージョンがオフラインの間はバックアップ ジョブを実行できません。 ボールト内のデータを復元することはできますが、新しいデータを追加することはできません。

  ペアリージョンのインフラストラクチャにバックアップを復元し、ロード バランサー、クライアント、その他のシステムを再構成して、ペアリージョンの正常なインフラストラクチャにトラフィックをリダイレクトする責任があります。

リージョンの復旧

プライマリ リージョンが復旧すると、Backup によってリージョン内の操作が自動的に復元されます。 ジョブが再開され、データは引き続き使用できます。

リージョン障害のテスト

CRR を使用して、ペアのリージョンへの復元操作を実行できます。 この方法を使用して、復元やその他の復旧プロセスを確認できます。

バックアップ データの損失に対する回復性

バックアップには、バックアップ データの偶発的または悪意のある削除を防ぐための 2 つの重要な回復機能が用意されています。

• ソフト削除により、構成可能な保持期間中に削除されたオブジェクトとボールトを回復できます。 既定では、この期間は 14 日間ですが、編集できます。 バックアップとボールトのごみ箱のようなものとして、ソフト削除を考えてください。 詳細については、「バックアップの 論理的な削除による既定のセキュリティ保護」を参照してください。

• 不変コンテナーは、 復旧ポイントの損失につながる可能性のある操作をブロックすることで、バックアップ データを保護するのに役立ちます。 不変のボルト設定をロックして、元に戻せないようにすることができます。 また、書き込みを 1 回使用し、多くの (WORM) ストレージをバックアップ用に読み取り、悪意のあるアクターが不変性を無効にしたり、バックアップを削除したりしないようにすることもできます。 詳細については、「 バックアップ用の不変コンテナー」を参照してください。

サービス水準合意書

Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンライン サービスの SLAを参照してください。

バックアップ SLA では、バックアップ操作と復元操作の両方に対するサービスの可用性について説明します。 SLA の対象にするには、失敗したバックアップまたは復元ジョブを 30 分ごとに少なくとも 1 回再試行する必要があります。

関連するコンテンツ

• Azure での信頼性
• Azure 仮想マシン の信頼性
• Azure Disk Storage における信頼性
• Azure Site Recovery における信頼性