Azure Stack Hub 上のファイルとアプリケーションのバックアップ

Azure Stack Hub が、ユーザー ワークロードを実行する仮想マシン (VM) をホストする状況を考えてみましょう。 ワークロードのファイルとアプリケーションをバックアップして復元する必要があります。 この参照アーキテクチャの記事では、バックアップおよび復元のアクティビティ用に最適化されたソリューションを提供する方法について説明します。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

クラウド コンポーネントには次のサービスが含まれます。

• このソリューションに含まれるすべてのクラウド リソースをホストする Azure サブスクリプション。
• Azure サブスクリプションに関連付けられている Microsoft Entra テナント。 Azure リソースへのアクセスを承認するために Microsoft Entra セキュリティ プリンシパルの認証を提供します。
• Azure Recovery Services コンテナー。Azure Stack Hub デプロイのホストとなるオンプレミス データセンターに最も近い Azure リージョンに置かれます。

この記事で提示する基準によっては、次のサービスもクラウド コンポーネントに含まれる場合があります。

• オンプレミスのデータセンターと Azure Recovery Services コンテナーをホストする Azure リージョンを接続する Azure ExpressRoute 回線。 この回線は、より大きなバックアップ サイズに対応するために Microsoft ピアリングを使用するように構成されています。

• Azure への MABS オフライン バックアップを有効にするための Azure Import/Export サービス。

  Note

  8 月 20 日の時点で、Azure Data Box を使用する Azure への MABS オフライン バックアップはプレビュー段階です。

Azure への MABS オフライン バックアップのために Azure Import/Export サービスを使用する場合、ソリューションでは、Recovery Services コンテナーと同じ Azure リージョンでも Azure ストレージ アカウントを使用することがあります。

オンプレミス コンポーネントには次のサービスが含まれます。

• 接続型デプロイ モデルの Azure Stack Hub 統合システム。最新の更新プログラム (2020 年 8 月時点では 2002) が適用され、カスタマーのオンプレミス データセンター内に配置されます。

• Azure Stack Hub 統合システムによってホストされ、MABS v3 Update Release (UR) 1 を実行している Windows Server 2016 または Windows Server 2019 VM。

• MABS 保護エージェントを備えた Azure Stack Hub VM。このエージェントは、MABS Azure Stack Hub VM へのバックアップとこの VM からの復元を管理します。 MABS 保護エージェントは、保護されたワークロードへの変更を追跡し、変更を MABS データ ストアに転送します。 また、保護エージェントは、保護可能なそのローカル コンピューター上のデータを特定し、回復プロセスでの役割を果たします。

• MABS を実行するサーバーにインストールされている Microsoft Azure Recovery Services (MARS) エージェント。 このエージェントは MABS と Azure Recovery Services コンテナーを統合します。

  Note

  MARS エージェントは "Azure Backup エージェント" とも呼ばれます。

Components

• Azure Stack Hub
• Microsoft Entra ID
• Azure Storage アカウント
• Azure ExpressRoute

代替

この記事で説明している推奨ソリューションは、Azure Stack Hub で実行されているユーザー ワークロードにバックアップと復元の機能を提供する唯一の方法ではありません。 その他の手段を選ぶこともできます。その例を次に示します。

• Windows Server オペレーティング システムに含まれている Windows Server バックアップ機能を使用したローカル バックアップと復元。 ユーザーはその後、ローカル バックアップを長期ストレージにコピーできます。 この方法では、Windows VSS プロバイダーに依存することにより、アプリケーションと整合性のあるバックアップがサポートされますが、ローカル ディスク領域の使用量とバックアップのメンテナンスのオーバーヘッドが増加します。
• Azure Backup と、ローカルにインストールされた MARS エージェントを使用したバックアップと復元。 この方法では、ローカル ディスク領域の使用が最小限に抑えられ、バックアップをクラウドベースのストレージにアップロードするプロセスが自動化されます。 ただし、アプリケーションと整合性のあるバックアップはサポートされません。
• 同じデータセンター (ただし、Azure Stack Hub の外部) にインストールされるバックアップ ソリューションを使用したバックアップと復元。 この方法は、Azure Stack Hub の非接続型デプロイ モデルを採用するシナリオで使用できます。
• ディスクのスナップショットを使用した Azure Stack Hub レベルのバックアップと復元。 この方法は、バックアップ中の VM を停止する必要があり、ビジネスに不可欠なワークロードでは通常は採用できませんが、シナリオによっては採用できる場合があります。

シナリオの詳細

バックアップと復元は、包括的な事業継続とディザスター リカバリー戦略に不可欠なコンポーネントです。 一貫性があって信頼性の高いバックアップ アプローチをハイブリッド環境で設計および実装することは困難ですが、Microsoft Azure サービスとの統合によって大幅に簡略化できます。 これは、従来のオンプレミス インフラストラクチャで実行されているワークロードだけでなく、サード パーティのパブリックおよびプライベートのクラウド プロバイダーによってホストされるワークロードにも適用されます。 ただし、Azure サービスとの統合の利点が際立つのは、Azure Stack Hub などの Azure Stack ポートフォリオ オファリングがハイブリッド環境に組み込まれている場合です。

Azure Stack Hub の主な利点の 1 つは、サービスとしてのプラットフォーム (PaaS) モデルをサポートすることですが、サービスとしてのインフラストラクチャ (IaaS) ワークロードが既にある場合はそれらを最新にするのにも役立ちます。 このようなワークロードには、ファイル共有、Microsoft SQL Server データベース、Microsoft SharePoint ファーム、Microsoft Exchange Server クラスターなどがあります。 Microsoft Azure との整合性がある管理およびプログラミング モデルがあるハイパーコンバージドで回復性の高いクラスターで実行される VM にそれらを移行すれば、管理とメンテナンスのオーバーヘッドを最小限に抑えることができます。

Azure Stack Hub VM で実行されるファイルとアプリケーションのバックアップを実装する場合、クラウド コンポーネントとオンプレミス コンポーネントの組み合わせを前提としたハイブリッド アプローチが推奨されます。これにより、スケーラブルで、パフォーマンスが高く、回復性があり、安全で、管理しやすく、コスト効率の高いバックアップ ソリューションを実現できます。 このソリューションの中心的なコンポーネントは、Azure Backup オファリングの一部である Microsoft Azure Backup Server (MABS) v3 です。 MABS では、コンピューティング、ネットワーク、短期ストレージのリソースを Azure Stack Hub インフラストラクチャに依存し、長期バックアップ ストアには Azure ベースのストレージを使用します。 このアプローチにより、テープなどの物理バックアップ メディアのメンテナンスの必要性を最小限またはゼロにすることができます。

コア機能

提案するソリューションは、Windows Server 2019、2016、2012 R2、2012、2008 R2 SP1 (64 ビット、Windows Management Framework 4.0 搭載)、2008 SP2 (64 ビット、Windows Management Framework 4.0 搭載)、および Windows 10 (64 ビット) を実行する Azure Stack Hub VM で次の機能をサポートします。

• New Technology File System (NTFS) および Resilient File System (ReFS) のボリューム、共有、フォルダー、ファイル、システム状態のバックアップと復元。

• SQL Server 2019、2017、2016 (必要なサービス パック (SP) を適用)、および 2014 (必要な SP を適用) インスタンスとそのデータベースのバックアップと復元。

• Exchange Server 2019 および Exchange Server 2016 サーバーおよびデータベース (データベース可用性グループ (DAG) 内のスタンドアロン サーバーおよびデータベースを含む) のバックアップと復元。

• DAG 内の個々のメールボックスとメールボックス データベースの復元。

• SharePoint 2019 および SharePoint 2016 (最新の SP を適用) のファームとフロントエンド Web サーバー コンテンツのバックアップと復元。

• SharePoint 2019 および SharePoint 2016 のデータベース、Web アプリケーション、ファイル、リスト アイテム、検索コンポーネントの復元。

  注意

  Azure Stack Hub で Windows 10 クライアント オペレーティング システムをデプロイするには、Windows のユーザーごとのライセンスを持っているか、Qualified Multitenant Hoster (QMTH) から購入済みである必要があります。

MABS では、ディスクからディスクからクラウドへ (D2D2C) バックアップ スキームを実装し、プライマリ バックアップは MABS のインストールをホストするサーバーにローカルで保存されます。 その後、ローカル バックアップが Azure Site Recovery コンテナーにコピーされます。 ローカル ディスクは短期的なストレージとして機能する一方、コンテナーは長期間のストレージを提供します。

バックアップ プロセスは次の 4 つの段階で構成されます。

1. 保護するコンピューターに MABS 保護エージェントをインストールし、保護グループに追加します。
2. コンピューターまたはそのアプリの保護を設定します。これには、短期保管用の MABS ローカル ディスクへのバックアップと、長期保管用の Azure へのバックアップが含まれます。 設定の一部として、両方の種類のバックアップについてバックアップ スケジュールを指定します。
3. 指定したスケジュールに従って、保護されたワークロードがローカル MABS ディスクにバックアップされます。
4. MABS ディスクに保存されるローカル バックアップは、MABS サーバーで実行されている MARS エージェントによって Azure Recovery Services コンテナーにバックアップされます。

前提条件

推奨ソリューションを実現するためには、次の前提条件を満たす必要があります。

• Azure サブスクリプションへのアクセス。Azure Stack Hub デプロイのホストになっているオンプレミスのデータセンターに最も近い Azure リージョンに Azure Recovery Services コンテナーをプロビジョニングするための十分なアクセス許可が必要です。

• MABS インスタンスのホストになる Azure Stack Hub VM からアクセス可能な Active Directory Domain Services (AD DS) ドメイン。

• Azure Stack Hub でホストされ MABS インスタンスを実行する VM が、「Azure Stack への Azure Backup Server のインストール」に記載されている前提条件を満たし、「DPM/MABS ネットワークのサポート」に記載されている URL への送信接続性を備えていること。

  Note

  ディスク領域とパフォーマンスに関する MABS のその他の考慮事項については、この記事の後半で詳しく説明します。

  Note

  MABS をホストする VM が Azure Backup サービスへの接続性を備えているかどうかを検証するために、(Azure Backup Server PowerShell モジュールに含まれている) Get-DPMCloudConnection コマンドレットを使用できます。

  注意

  MABS には SQL Server のローカル インスタンスも必要です。 SQL Server の要件の詳細については、「Azure Backup Server のインストールとアップグレード」を参照してください。

データ型

MABS の観点からは、次の 2 種類のデータを考慮する必要があります。

• "ファイル データ" は、通常はファイル サーバーに常駐し、フラット ファイルとして保護する必要がある、Microsoft Office ファイル、テキスト ファイル、メディア ファイルなどのデータです。
• "アプリケーション データ" は、(Exchange ストレージ グループ、SQL Server データベース、SharePoint ファームなどの) アプリケーション サーバー上に存在し、対応するアプリケーション要件を MABS 側で認識する必要があるデータです。

バックアップの種類

ファイル データとアプリケーション データのどちらを保護する場合も、MABS インスタンスのローカル ストレージにあるデータ ソースのレプリカを作成することから保護が始まります。 レプリカは、設定に構成した定期的な間隔で同期または更新されます。 MABS でレプリカの同期に使用する方法は、保護されているデータの種類によって決まります。 レプリカに整合性がないことが特定されると、MABS はデータ ソースに対してレプリカをブロックごとに検証する整合性チェックを実行します。

サーバー上のファイル ボリュームまたは共有の場合、最初の完全バックアップの後、MABS 保護エージェントはボリューム フィルターと変更ジャーナルを使用して、変更されたファイルを特定します。 次に、これらのファイルに対してチェックサム手順を実行して、変更されたブロックのみを同期します。 同期時には、これらの変更が MABS に転送された後、レプリカに適用されることによって、レプリカがデータ ソースと同期されます。

レプリカとデータ ソースの整合性が失われると、MABS はどのコンピューターとどのデータ ソースが影響を受けるかを示すアラートを生成します。 この問題を解決するには、整合性チェック付きの同期をレプリカで開始するとレプリカを修復できます。 整合性チェック中に MABS はブロックごとの検証を実行し、レプリカを修復して、データ ソースとの整合性を回復します。 保護グループの毎日の整合性チェックをスケジュールするか、手動で整合性チェックを開始することができます。

構成できる定期的な間隔で、MABS は保護されたデータ ソースの回復ポイントを作成します。 "回復ポイント" は、回復できるデータの 1 つのバージョンです。

アプリケーション データの場合、レプリカが MABS によって作成された後、アプリケーション ファイルに属するボリューム ブロックの変更をボリューム フィルターが追跡します。 変更を MABS サーバーに転送する方法は、アプリケーションと同期の種類によって決まります。 MABS 管理者コンソールで "同期" のラベルがついた操作は増分バックアップに似ており、レプリカと組み合わせたときに、トランザクション上で整合している、アプリケーション データの正確な反映を作成します。

MABS 管理者コンソールで "高速完全バックアップ" のラベルがついた種類の同期中、フル ボリューム シャドウ コピー サービス (VSS) スナップショットが作成されますが、変更されたブロックだけが MABS サーバーに転送されます。

1 回の高速完全バックアップで、アプリケーション データの回復ポイントが 1 つ作成されます。 アプリケーションが増分バックアップに対応している場合は、さらに同期のたびに回復ポイントが作成されます。 同期プロセスはアプリケーションに依存します。

• Exchange データでは、同期は Exchange VSS ライターを使用して増分 VSS スナップショットを転送します。 同期ごとに、また高速完全バックアップごとに回復ポイントが作成されます。
• ログ配布の対象である、読み取り専用モードである、または単純復旧モデルを使用する SQL Server データベースでは、増分バックアップはサポートされません。 回復ポイントは高速完全バックアップごとにのみ作成されます。 他のすべての SQL Server データベースでは、同期によってトランザクション ログのバックアップが転送され、増分同期および高速完全バックアップごとに回復ポイントが作成されます。 トランザクション ログとは、最後にバックアップされた時点からデータベースに実行されてきた、すべてのトランザクションの連続レコードです。
• SharePoint サーバーは増分バックアップをサポートしていません。 回復ポイントは高速完全バックアップごとにのみ作成されます。

増分同期は、高速完全バックアップほど時間がかかりません。 ただし、同期の数が増えるにつれて、データを回復するために必要な時間も長くなります。 これは、MABS では、最後の完全バックアップを復元してから、回復に指定された時点までのすべての増分同期を復元して適用する必要があるためです。

より高速な回復時間を可能にするため、MABS では定期的に高速完全バックアップを実行します。これにより、変更されたブロックを含めるようにレプリカが更新されます。 高速完全バックアップ中に、変更されたブロックを使用してレプリカを更新する前に、MABS はレプリカのスナップショットをとります。 より頻繁な RPO を有効にしてデータ損失期間を短くするために、MABS では 2 回の高速完全バックアップの合間に増分同期も実行します。

ファイル データ保護と同様に、レプリカのデータ ソースとの整合性がなくなると、MABS はどのサーバーとどのデータ ソースがその影響を受けたかを示すアラートを生成します。 不整合を解決するために、整合性チェック付きの同期をレプリカで開始することによってレプリカを修復できます。 整合性チェック中、MABS ではブロック単位でレプリカの検証を実行し、レプリカを修復してデータ ソースとの整合性を回復します。 保護グループの毎日の整合性チェックをスケジュールするか、手動で整合性チェックを開始することができます。

保護ポリシー

MABS 保護エージェント ソフトウェアをコンピューターにインストールし、コンピューターまたはそのワークロードのデータを保護グループに追加すると、コンピューターまたはそのワークロードは保護された状態になります。 保護グループは、コンピューターのデータ ソースの保護を構成および管理するために使用されます。 "保護グループ" とは、同一の保護構成を共有するデータ ソースの集合です。 保護構成は保護グループに共通した設定の集合で、保護グループ名、保護ポリシー、ストレージの割り当て、レプリカ作成方法などが含まれます。

MABS は、各保護グループ メンバーの個々のレプリカを記憶域プールに保存します。 保護グループのメンバーには、次のようなデータ ソースを含めることができます。

• ファイル サーバーまたはサーバー クラスター上のボリューム、共有、またはフォルダー。
• Exchange サーバーまたはサーバー クラスター上のストレージ グループ。
• SQL Server またはサーバー クラスターのインスタンスのデータベース。

保護グループごとに、その保護グループの回復目標に基づく保護ポリシーを構成します。 "回復の目標" は、組織の RTO および RPO に対応するデータ保護要件を表します。 MABS 内で、次のパラメーターの組み合わせに基づいて定義されます。

• 短期的な保有期間の範囲。 これにより、ローカル MABS ストレージにバックアップ データを保持する期間が決まります。

• 同期と回復ポイントの頻度。 これは、データ損失の許容範囲に直接対応します。この範囲は、組織の RPO を反映します。 さらに、データの変更を収集することによって MABS でそのローカル レプリカを保護されたデータ ソースと同期する頻度もこれによって決まります。 15 分～ 24 時間の間の任意の期間に同期頻度を設定できます。 指定した時間スケジュールではなく、回復ポイントを作成する直前に、同期を選択することもできます。

• 短期的な回復ポイントのスケジュール。 これによって、保護グループ用のローカル ストレージに作成される回復ポイントの数が決まります。 ファイルを保護する場合、回復ポイントを作成する日付と時刻を選択します。 増分バックアップをサポートするアプリケーションのデータ保護では、同期頻度によって回復ポイントのスケジュールが決まります。

• 高速完全バックアップのスケジュール。 これは、増分バックアップをサポートせず、高速完全バックアップをサポートするアプリケーションのデータ保護用の回復ポイントのスケジュールです。

• オンライン バックアップ スケジュール。 これによって、ローカル MABS インスタンスに関連付けられている Azure Recovery Services コンテナーにローカル バックアップのコピーを作成する頻度が決まります。 日、週、月、または年の単位で、最大で 1 日あたり 2 回のバックアップ頻度でスケジュールを設定できます。 MABS は、保護されたデータ ソースから新しいデータを転送することなく、最新のローカル レプリカを使用してオンライン バックアップの回復ポイントを自動的に作成します。

  Note

  Recovery Services コンテナーでは、最大 9,999 個の回復ポイントがサポートされます。

• オンライン保持ポリシー。 ローカルの MABS インスタンスに関連付けられた Azure Site Recovery コンテナーに、毎日、毎週、毎月、および毎年のバックアップが保持される期間を指定します。

  注意

  データ ソースの最新の内容をオンラインで保護するには、オンライン回復ポイントを作成する前に新しい回復ポイントをローカル ディスク上に作成します。

  注意

  既定では、Azure Recovery Services コンテナーは "geo 冗長" であり、そのストレージにコピーされたバックアップは、定義済みのリージョン ペアに属している Azure リージョンに自動的にレプリケートされます。 ローカル冗長でも回復性のニーズに十分であり、ストレージ コストを最小限に抑える必要がある場合、レプリケーション設定をローカル冗長に変更することもできます。 ただし、設定は既定のままにすることをお勧めします。 保護対象の項目がコンテナーに含まれている場合、このオプションは変更できません。

  Note

  Azure リージョン ペアの一覧については、ビジネス継続性とディザスター リカバリー (BCDR): Azure のペアになっているリージョンに関するページをご覧ください。

復元のテスト

バックアップ戦略を最適に設計および実装することに加えて、保護するワークロードの種類ごとに復元プロセスを定義、文書化、テストすることも同様に重要です。 データ バックアップの整合性を自動的に検証する組み込みの整合性チェックは MABS によって提供されますが、復元テストを日常の運用手順に組み込む必要があります。 このテストでは、復元されたワークロードの状態を調べることで復元を検証します。 テストの結果を、ワークロードの所有者が参照できるようにしてください。

一般的には、保護対象のワークロードをホストしている環境によく似た環境を用意する必要があることから、復元のテストには困難が伴う傾向があります。 組み込みの DevOps 機能と、コードとしてのインフラストラクチャ機能を備えた Azure Stack Hub により、この課題への対応が大幅に簡素化されます。

ロールと責任

Azure Stack Hub ベースのワークロードのバックアップと復元を計画し、実装するにあたっては、通常、多くの関係者間でのやり取りが伴います。

• Azure Stack Hub オペレーター。 Azure Stack Hub オペレーターは、Azure Stack Hub のインフラストラクチャを管理します。包括的なバックアップと復元のソリューションを実装し、それらのリソースをテナントに提供するために必要な十分なコンピューティング、ストレージ、ネットワーク リソースを確保します。 また、アプリケーションとデータの所有者とも連携し、Azure Stack Hub にワークロードをデプロイするための最適なアプローチを判断します。
• Azure 管理者。 Azure 管理者は、ハイブリッドのバックアップ ソリューションの実装に必要な Azure リソースを管理します。
• Microsoft Entra 管理者。 Microsoft Entra リソース (Azure リソースのプロビジョニング、構成、管理に使用されるユーザー オブジェクトとグループ オブジェクトを含む) は、Microsoft Entra 管理者が管理します。
• Azure Stack Hub テナント IT スタッフ。 これらの関係者は MABS の設計、実装、管理を行います。これには、MABS のバックアップと復元が含まれます。
• Azure Stack Hub ユーザー。 これらのユーザーは、RPO と RTO の要件を提供し、データおよびアプリケーションのバックアップと復元のリクエストを送信します。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

Azure Stack Hub には、そのインフラストラクチャがもともと備えている回復性があるため、ワークロードの可用性が高まる効果があります。 ワークロード保護のスコープを拡張するソリューションを設計して実装することで、可用性をさらに高めることができます。 これが MABS によって提供される付加価値です。 Azure Stack Hub 上で実行される MABS のコンテキストでは、可用性について、次の 2 つの側面を詳しく吟味する必要があります。

• MABS とそのデータ ストアの可用性
• MABS で保護するワークロードのポイントインタイム リストア機能の可用性

回復ポイントの目標 (RPO) と目標復旧時間 (RTO) を軸としたバックアップ戦略を立てる際には、これらの両方を考慮する必要があります。 RTO と RPO は、組織内の事業区分ごとに規定された継続性要件を表します。 RPO は、一定期間データを使用できなくなるインシデントが発生したために許容される最大データ損失を表す時間を指定します。 RTO が意味するのは、事業機能が使用できなくなるインシデントの発生後、その事業機能へのアクセスを回復するために必要な時間として許容できる最大時間です。

MABS とそのデータ ストアの可用性は、MABS のインストールと、そのローカルおよびクラウドベースのストレージをホストしている VM の可用性によって決まります。 Azure Stack Hub VM は、設計によって高可用性を実現します。 MABS で障害が発生した場合、MABS をホストしている他のどの Azure Stack Hub VM からでも、Azure Backup で保護された項目を復元できます。 ただし、MABS をホストしているサーバーで、別のサーバーで実行されている MABS を使用して実行されたバックアップを復旧するには、両方のサーバーが同じ Azure Site Recovery コンテナーに登録されている必要があります。

MABS で保護するワークロードのポイントインタイム リストア機能は、データの種類、そのバックアップ、およびその保護ポリシーに大きく依存します。 これらの依存関係を理解するには、これらの概念をさらに詳しく検討する必要があります。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

ハイブリッドのシナリオでユーザー データとアプリケーションを管理するにあたっては、セキュリティに関する追加の考慮事項があります。 それらの考慮事項は、次のカテゴリに分けることができます。

• バックアップの暗号化
• Azure Recovery Services コンテナーの保護

MABS と Azure Backup では、次のように保存時および転送中のバックアップの暗号化が行われます。

• 保存時の暗号化。 MABS のインストール中に、ユーザーはパスフレーズを提供します。 このパスフレーズは、Azure Recovery Services コンテナーにアップロードされる前にすべてのバックアップを暗号化するために使用されます。 復号化解除は、そのコンテナーからバックアップがダウンロードされた後にしか行われません。 このパスフレーズは、パスフレーズを作成したユーザーと、ローカルにインストールされた MARS エージェントのみが利用できます。 このパスフレーズは、バックアップが実行された場所と異なる MABS サーバーでクラウドベースの復元を実行するときの認証メカニズムとして機能するため、必ず安全な場所に保管してください。
• 転送中の暗号化。 MABS v3 では、Azure への接続を保護するために、トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2 に依存します。

Azure Recovery Services コンテナーは、次に示すように、オンライン バックアップをさらに保護するいくつかのメカニズムを提供します。

• Azure ロールベースのアクセス制御 (Azure RBAC)。 Azure RBAC を使用すると、最小限の特権の原則に従って責任を委任および分離することができます。 バックアップ管理操作へのアクセスを制限する Azure Backup 関連の組み込みロールには、次の 3 つがあります。
  • バックアップ共同作成者。 バックアップを作成および管理するためのアクセスを提供しますが、Recovery Services コンテナーの削除と、他のユーザーへのアクセスの委任は除きます。
  • バックアップ オペレーター。 バックアップの削除とバックアップ ポリシーの管理を除き、バックアップ共同作成者と同等のアクセスを提供します。
  • バックアップ閲覧者。 バックアップ管理操作を監視するためのアクセスを提供します。
• Azure リソース ロック。 読み取り専用ロックおよび削除ロックを作成して Azure Site Recovery コンテナーに割り当てることで、不注意または悪意によってコンテナーが変更されたり削除されたりするリスクを軽減することができます。
• 論理的な削除。 論理的な削除は、コンテナーとバックアップ データを、不注意または悪意による削除から保護するために役立ちます。 論理的な削除を使用すると、ユーザーがバックアップ項目を削除した場合でも、対応するデータが 14 日間保持され、その期間中はデータを失うことなくバックアップを回復できます。 バックアップ データが論理的な削除状態にあるこの 14 日間の保有期間中は、コストは発生しません。 論理的な削除は既定で有効になっています。
• セキュリティに気を配る必要のある操作の保護。 パスフレーズの変更など、セキュリティに気を配る必要のある操作が試行されるたびに、Azure Recovery Services コンテナーによって別の認証レイヤーが自動的に実装されます。 この追加の検証によって、許可されているユーザーのみがこれらの操作を実行しているという確証が得られます。
• 疑わしいアクティビティの監視とアラート。 Azure Backup には、Azure Backup 操作に関連する、セキュリティに気を配る必要のあるイベントを監視し、アラートを生成する機能が組み込まれています。 バックアップ レポートを使用すると、使用状況の追跡、バックアップと復元の監査、重要なバックアップ傾向の特定が容易になります。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

この記事で説明しているバックアップ ソリューションのコストを考えるときは、忘れずに、オンプレミスとクラウドベースの両方のコンポーネントを考慮に入れてください。 オンプレミス コンポーネントの価格は、Azure Stack Hub の価格モデルによって決まります。 Azure と同様、Azure Stack Hub には従量課金体系が用意されていて、マイクロソフト エンタープライズ契約およびクラウド ソリューション プロバイダー プログラムを通じて利用することができます。 この体系には、Windows Server VM ごとの月額料金が含まれています。 既存の Windows Server ライセンスを使用できれば、ベース VM の価格にまでコストを大幅に削減することができます。 MABS はそのデータ ストアを SQL Server に依存しますが、MABS 専用であれば、SQL Server インスタンスの実行にはライセンス コストがかかりません。

次のリソースの使用には、Azure に関連した料金が発生します。

• Azure Backup。 Azure Backup の料金は、おおよそ、保護するワークロードの数と、ワークロードごとのデータ バックアップ (圧縮および暗号化前) のサイズによって決まります。 Azure Recovery Services コンテナーの内容のレプリケーション用に、ローカル冗長ストレージ (LRS) と geo 冗長ストレージ (GRS) のどちらを選択するかも、コストに影響します。 詳細については、「Azure Backup の価格」を参照してください。
• Azure ExpressRoute。 Azure ExpressRoute の価格は、次の 2 つのモデルのいずれかに基づきます。
  • 無制限のデータ。 この月額料金には、すべての受信および送信データ転送が含まれます。
  • 従量制課金データ。 この月額料金では、受信データ転送はすべて無料であり、送信データ転送は GB 単位で課金されます。
• Azure Import/Export。 Azure Import/Export のコストには、デバイスの処理のためのデバイス単位の均一料金が含まれます。
• Azure Storage です。 Azure Import/Export を使用する場合、Standard の Azure Storage 料金およびトランザクション料金が適用されます。

ExpressRoute を使用しない場合、バックアップと復元には、インターネット接続の帯域幅使用が増加することを考慮に入れる必要があります。 コストは、地理的領域、現在の帯域幅使用状況、インターネット サービス プロバイダなど、さまざまな要因によって変動します。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

管理の容易性

バックアップと復元の戦略に影響を与える主な考慮事項の 1 つは、保護グループの構成と、どの保護対象ワークロードを同じ保護グループに入れるかの決定に使用する基準です。 この記事で既に説明したように、保護グループとは、共通のバックアップおよび復元の設定を持つボリューム、共有、またはアプリケーション データ ストアなどのデータ ソースのコレクションです。 保護グループを定義するときは、次を指定する必要があります。

• 保護するサーバーやワークロードなどのデータ ソース。
• 短期的および長期的な保護設定を含むバックアップ ストレージ。
• バックアップされたデータをその時点から回復できる回復ポイント。
• 割り当てられたディスク領域。これは、バックアップのために割り当てられた記憶域プールからのディスク領域の容量です。
• 初期レプリケーション。これは、データ ソースの初期バックアップに使用される方法です。 この方法には、オンライン転送 (ネットワーク経由) またはオフライン転送 (Azure Import/Export サービス経由など) があります。
• 整合性チェック方法。これは、データ バックアップの整合性を検証する方法です。

次の方法は、多くの場合、どの保護対象ワークロードを同じ保護グループに入れるかを決めるのに使用されます。

• コンピューター別。 この方法では、コンピューターのすべてのデータ ソースを同じ保護グループにまとめます。
• ワークロード別。 この方法では、ファイルと各アプリケーションのデータ種類を別の保護グループに分けます。 ただし、複数のワークロードをホストしているサーバーの回復には、異なる保護グループからの複数回の復元が必要な場合があります。
• RPO および RTO 別。 この方法では、RPO が近いデータ ソースをグループ化します。 RPO の制御は、保護グループの同期頻度を設定することによって行います。これにより、予期しない停止中に失われる可能性があるデータの量 (時間で測定) が決まります。 この記事で説明するシナリオでは、短期ストレージ内の保持期間を設定することによって RTO を制御します。 これにより、クラウドベースの長期ストレージからではなくローカルの短期ストレージからバックアップを復元できる期間が決まります。 ローカルの短期ストレージからバックアップした方が、復元が速くなります。
• データの特性別。 この方法では、グループ化の基準として、データ変更の頻度、データ増加率、またはそのストレージ要件を考慮します。

保護グループに名前を付けるときは、一意のわかりやすい名前を使用します。 名前は、最大 64 文字の英数字とスペースを任意に組み合わせることができます。

保護グループを作成する際に、初期レプリカの作成方法を選択します。 初期レプリケーションでは、保護のために選択したすべてのデータを、MABS をホストしているサーバーにコピーしてから、Azure Site Recovery コンテナーにコピーします。 両方のコピーの整合性がチェックされます。 MABS ではネットワーク経由で自動的にレプリカを作成できますが、オフラインでデータをバックアップ、転送、復元することによって手動でレプリカを作成することもできます。

レプリカの作成方法の選択については、「ネットワーク経由での初期レプリケーション」を参照してください。 この記事には、MABS がさまざまな保護対象データ サイズとネットワーク速度で、ネットワーク経由でレプリカを自動的に作成するのにかかる時間の見積もりを示す表が記載されています。

オフライン シード処理プロセスでは、SATA ディスクを使用して Azure Storage アカウントにデータを転送できる Azure Import/Export サービスの使用がサポートされています。 この機能は、バックアップ データの量や Azure へのネットワーク接続速度が原因でオンライン バックアップが遅すぎる場合に使用できます。

オフライン シード処理のワークフローには、次の手順があります。

1. AzureOfflineBackupDiskPrep ツールを使用して、初期バックアップ データを 1 つ以上の SATA ディスクにコピーします。
2. このツールにより、ターゲットの Azure Storage アカウントと Azure Recovery Services コンテナーをホストしているサブスクリプションに Azure インポート ジョブと Microsoft Entra アプリが自動的に生成されます。 このアプリは、オフライン シード処理プロセスに必要な、Azure インポート サービスに対するセキュリティで保護されて範囲を制限されたアクセスを Azure Backup に提供します。
3. ターゲットの Azure Storage アカウントをホストする Azure データセンターにディスクを発送します。
4. Azure データセンターのスタッフがディスクから Azure Storage アカウントにデータをコピーします。
5. このワークフローにより、Azure Storage アカウントから Azure Recovery Services コンテナーへのコピーがトリガーされます。

DevOps

バックアップと復元は IT 運用の一部と見なされますが、包括的なバックアップ戦略に組み込む価値がある DevOps 固有の考慮事項がいくつかあります。 Azure Stack Hub は、VM ベースのアプリケーションやサービスなど、さまざまなワークロードの自動デプロイを容易にします。 この機能を使用すると、Azure Stack Hub VM への MABS のデプロイを効率化でき、マルチテナント シナリオでの初期セットアップが簡素化されます。 Azure Resource Manager テンプレート、VM 拡張機能、DPM PowerShell モジュールを組み合わせることにより、その保護グループのセットアップ、保持設定、バックアップ スケジュールなど、MABS の構成を自動化できます。 DevOps のベスト プラクティスに従って、テンプレートとスクリプトをソース管理機能に保存し、パイプラインを使用してそれらのデプロイを構成する必要があります。 これらのプラクティスは、ファイルとアプリケーション データの復元に必要なインフラストラクチャを再作成する必要がある場合の回復時間を最小限に抑えるのに役立ちます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

Azure Stack Hub に MABS をデプロイする予定の場合、デプロイのホストになる VM に割り当てる処理、ストレージ、およびネットワーク リソースの量を考慮する必要があります。 Microsoft では、MABS 処理のニーズに対応するために 2.33 ギガヘルツ (GHz) のクアッドコア CPU を、またインストール バイナリを格納するために約 10 GB のディスク領域を割り当てることをお勧めします。 その他のストレージ要件は、次のように分類できます。

• バックアップ用のディスク領域。 バックアップ ディスク領域の一般的な推奨事項は、バックアップするすべてのデータのサイズの約 1.5 倍に相当するディスク領域の記憶域プールを割り当てることです。 ディスクが VM にアタッチされた後は、MABS によってボリュームとディスク領域が管理されます。 VM にアタッチできるディスクの数は VM のサイズによって異なります。

  注意

  バックアップは、5 日間を超えてローカルに保存しないようにしてください。 5 日を経過したバックアップは、Azure Site Recovery コンテナーにオフロードする必要があります。

• MARS エージェント キャッシュの場所のディスク領域。 MABS のインストールをホストしている VM 上のドライブ C を使用することを検討してください。

• 復元中のローカル ステージング領域用のディスク領域。 MABS のインストールをホストしている VM 上の一時ドライブ D を使用することを検討してください。

MABS のインストールをホストしている VM 用にストレージをプロビジョニングするには、Premium パフォーマンス レベルのマネージド ディスクを使用します。 期待されるパフォーマンス特性は、ディスクあたり 2,300 I/O 操作/秒 (IOPS) および 145 MB/秒です。 Azure とは異なり、Azure Stack Hub にはパフォーマンスの保証がありません。

Azure Stack Hub ベースのワークロード バックアップに対応するために必要なストレージについて、より正確な見積もりを得るためには、Microsoft ダウンロードから入手できる Azure Stack VM Size Calculator for MABS の使用を検討してください。 この計算ツールは、指定されたいくつかのパラメーターに基づく、Azure Stack Hub の最適なサイズ設定情報を算出するマクロを搭載した Microsoft Excel ワークブックとして実装されています。 これらのパラメーターには、以下のものがあります。

• 次のそれぞれに対するものなど、保護する VM の一覧を含むソースの詳細。
  • 保護対象データのサイズ
  • ワークロードの種類 (Windows Server、SharePoint、または SQL Server)
• データ保持期間の範囲 (日)

ワークロードの種類ごとに、あらかじめ定義された 1 日あたりの変更率 ("チャーン") が既定で関連付けられています。 これらの値が環境での使用パターンを反映していない場合、値を調整することができます。

Azure Stack VM Size Calculator for MABS は、指定された情報を使用して次のものを提供します。

• MABS のインストールをホストする Azure Stack Hub VM の推定サイズ。
• バックアップしたデータをホストするために必要な MABS ディスク領域の推定量。
• それぞれ 1 テラバイト (TB) のディスクの総数。
• MABS の用途に使用できる IOPS レート。
• 初期バックアップの推定所要時間。 この見積もりは、保護データの合計サイズと、MABS の用途に利用可能な IOPS に基づいています。
• 毎日のバックアップの推定所要時間。 この見積もりは、毎日のチャーンの合計サイズと、MABS の用途に利用可能な IOPS に基づいています。

MABS のグラフィカル インターフェイスを使用して保護グループを作成する場合、データ ソースを保護グループに追加するたびに、指定された短期的な回復目標に基づくローカル ディスク領域の割り当てが MABS によって計算されます。 グループ内のデータ ソースごとに、記憶域プール内でどれだけの領域をレプリカおよび回復ポイントに割り当てるかを決定することができます。 保護されるサーバーのローカル ディスク上に、変更ジャーナル用の十分な領域があることを確認する必要があります。 MABS は保護グループのメンバーに対して既定の領域割り当てを提供します。 さまざまな MABS コンポーネントの既定の領域割り当ての詳細については、保護グループのデプロイに関するドキュメントを参照してください。

既定の領域割り当てでは特定のニーズに適さないことがわかっている場合を除き、この割り当てを使用することをお勧めします。 既定の割り当てをオーバーライドすると、領域が不足したり過剰になったりすることがあります。 回復ポイントの領域の割り当てが少なすぎると、MABS が保有期間の範囲の目的に沿って十分な回復ポイントを保存することが妨げられてしまいます。 また、領域の割り当てが多すぎるとディスク容量が無駄になってしまいます。 保護グループを作成した後、データ ソースに割り当てた領域が少なすぎる場合は、各データ ソースのレプリカおよび回復ポイントのボリュームへの割り当てを増やすことができます。 保護グループに割り当てた領域が多すぎる場合は、保護グループからデータ ソースを削除し、レプリカを削除することができます。 その後、割り当てが少ない保護グループにデータ ソースを追加します。

デプロイ後、処理またはストレージ要件の変更に対応するために、MABS をホストする Azure Stack Hub VM の推定サイズ設定を調整する必要がある場合、次の 3 つのオプションがあります。

• 垂直スケーリングを実施する。 これには、MABS をホストする Azure Stack Hub VM のプロセッサ、メモリ、ディスク リソースの量や種類を変更する必要があります。
• 水平スケーリングを実施する。 これには、保護するワークロードの処理需要に合わせて、MABS をインストールする Azure Stack Hub VM をプロビジョニングまたはプロビジョニング解除する必要があります。
• 保護ポリシーを変更する。 これには、保持期間、回復ポイントのスケジュール、高速完全バックアップのスケジュールなど、保護ポリシーのパラメーターを変更する必要があります。

ボリュームを自動的に拡大することを選択した場合、MABS は、運用データの増大に合わせたバックアップ ボリュームの増加を考慮に入れます。 それ以外の場合、MABS はバックアップ ストレージを保護グループ内のデータ ソースのサイズに制限します。

利用可能な帯域幅を調整する方法には、主に次の 2 つがあります。

• VM のサイズを増やします。 Azure Stack Hub VM の場合、そのサイズによってネットワークの最大帯域幅が決まります。 ただし、帯域幅の保証はありません。 その代わり、VM は、そのサイズに規定された上限まで、使用可能な帯域幅を使用することができます。
• アップリンク スイッチのスループットを向上させます。 Azure Stack Hub システムでは、さまざまなアップリンク速度の選択肢を提供する、幅広いハードウェア スイッチをサポートしています。 Azure Stack Hub クラスター ノードはそれぞれ、フォールト トレランスを目的に、Top-of-Rack スイッチへのアップリンクを 2 つ備えています。 システムは、アップリンク容量の半分を重要なインフラストラクチャに割り当てます。残りは、Azure Stack サービスとすべてのユーザー トラフィックのための共有容量です。 より高い速度でデプロイされたシステムは、バックアップ トラフィックに使用できる帯域幅もそれだけ大きくなります。

第 2 のネットワーク アダプターをサーバーに接続することでネットワーク トラフィックを分離することはできますが、インターネットに向かうすべての Azure Stack Hub VM トラフィックが同じアップリンクを共有します。 仮想ネットワーク アダプターを追加しても、物理トランスポート レベルではトラフィックが分離されません。

バックアップ サイズの増加に対応したければ、Azure ExpressRoute を使用し、Azure Stack Hub 仮想ネットワークと Azure Recovery Services コンテナーの間の接続に Microsoft ピアリングを使用することを検討できます。 Azure ExpressRoute は、接続プロバイダーが提供するプライベート接続を介して、オンプレミスのネットワークを Microsoft クラウドに拡張します。 50 Mbps から 10 Gbps まで広範囲の帯域幅に適した ExpressRoute 回線を購入できます。

まとめ

Azure Stack Hub は、さまざまな点で他の仮想化プラットフォームとは一線を画した製品です。 したがって、その VM 上で実行されるワークロードのビジネス継続性戦略には特別な考慮事項が伴います。 Azure サービスを使用すると、設計と実装の戦略が簡素化されます。 この記事では、MABS を使用して、接続型デプロイ モデルの Azure Stack Hub VM 上のファイルおよびアプリケーション データをバックアップする方法について説明しました。 そのアプローチがユーザーにもたらす利点は、Azure Stack Hub の回復性と管理の容易性、そして、Azure クラウドのハイパースケールとグローバル プレゼンスです。

ここで説明したバックアップ ソリューションは、Azure Stack Hub VM 上のファイルおよびアプリケーション データのみに焦点を当てています。 ビジネス継続性の戦略では、ワークロードの可用性に影響を与えるシナリオを他にも色々と考慮に入れる必要がありますが、ここで取り上げたものは戦略全体のほんの一部にすぎません。 たとえば、ハードウェアやソフトウェアの局所的な障害、システムの停止、壊滅的な事象、大規模災害などがあります。

次のステップ

• 操作方法ガイド - Azure Stack 上のストレージ アカウントのバックアップ
• 操作方法ガイド - Commvault を使用した Azure Stack Hub 上の VM のバックアップ
• クラウドとオンプレミスのワークロードをクラウドにバックアップする
• Azure Backup Server のインストール
• Azure Stack 上のファイルとアプリケーションのバックアップ
• Azure Stack 上の SharePoint ファームのバックアップ
• Azure Stack 内の SQL Server のバックアップ

関連リソース

関連するハイブリッド ガイダンス:

• ハイブリッド アーキテクチャの設計
• Azure ハイブリッド オプション
• ハイブリッド アプリの設計上の考慮事項

関連アーキテクチャ

• Azure Stack Hub の VM のディザスター リカバリー
• オンプレミスのアプリケーションおよびデータをクラウドにバックアップする