Azure IaaS ディスクのバックアップとディザスター リカバリーBackup and disaster recovery for Azure IaaS disks

この記事では、Azure の IaaS 仮想マシン (VM) とディスクのバックアップおよびディザスター リカバリー (DR) を計画する方法について説明します。This article explains how to plan for backup and disaster recovery (DR) of IaaS virtual machines (VMs) and disks in Azure. このドキュメントでは、マネージド ディスクと非管理対象ディスクの両方について説明しています。This document covers both managed and unmanaged disks.

最初に Azure プラットフォームに組み込まれているフォールト トレランス機能について説明します。この機能は、局所的な障害に対する保護となります。First, we cover the built-in fault tolerance capabilities in the Azure platform that helps guard against local failures. 次に、組み込みの機能では完全にはカバーされない障害のシナリオについて説明します。We then discuss the disaster scenarios not fully covered by the built-in capabilities. また、別のバックアップと DR の考慮事項を適用できるワークロード シナリオの例を複数紹介します。We also show several examples of workload scenarios where different backup and DR considerations can apply. そして、IaaS のディスクの DR に対して考えられる解決策を検討します。We then review possible solutions for the DR of IaaS disks.

はじめにIntroduction

Azure プラットフォームでは、局所的なハードウェア障害からお客様を保護するために、冗長性とフォールト トレランスに関するさまざまなメソッドが使用されています。The Azure platform uses various methods for redundancy and fault tolerance to help protect customers from localized hardware failures. 局所的な障害には、仮想ディスクのデータの一部を格納する Azure Storage サーバー マシンに関する問題や、これらのサーバー上の SSD または HDD の障害などが含まれます。Local failures can include problems with an Azure Storage server machine that stores part of the data for a virtual disk or failures of an SSD or HDD on that server. このような孤立したハードウェア コンポーネントの障害は通常の操作中に発生する可能性があります。Such isolated hardware component failures can happen during normal operations.

Azure プラットフォームはこのような障害から復旧するように設計されています。The Azure platform is designed to be resilient to these failures. 大規模災害によって、多数のストレージ サーバーまたはデータセンター全体にも障害が発生する可能性や、それらにアクセスできなくなる可能性があります。Major disasters can result in failures or the inaccessibility of many storage servers or even a whole datacenter. VM とディスクは通常、局所的な障害からは保護されていますが、VM とディスクに影響を与える可能性のある、リージョン全体にわたる致命的な障害 (大規模災害など) からワークロードを保護するためには、追加の手順が必要になります。Although your VMs and disks are normally protected from localized failures, additional steps are necessary to protect your workload from region-wide catastrophic failures, such as a major disaster, that can affect your VM and disks.

プラットフォームに障害が発生する可能性だけでなく、お客様のアプリケーションやデータに問題が発生する場合もあります。In addition to the possibility of platform failures, problems with a customer application or data can occur. たとえば、アプリケーションのバージョンを新しくしたことで、中断の原因となるデータ変更が意図せずに加えられる場合があります。For example, a new version of your application might inadvertently make a change to the data that causes it to break. その場合は、以前のバージョンのうち、正常な状態であることがわかっている最新のバージョンに、アプリケーションやデータを戻したいと思うでしょう。In that case, you might want to revert the application and the data to a prior version that contains the last known good state. これには、定期的なバックアップを継続する必要があります。This requires maintaining regular backups.

リージョンのディザスター リカバリーについては、IaaS VM ディスクを別のリージョンにバックアップする必要があります。For regional disaster recovery, you must back up your IaaS VM disks to a different region.

バックアップと DR のオプションについて考える前に、局所的な障害の処理に使用できるいくつかの方法を要約します。Before we look at backup and DR options, let’s recap a few methods available for handling localized failures.

Azure IaaS 回復性Azure IaaS resiliency

回復性とは、ハードウェア コンポーネントで発生する通常の障害の許容範囲のことです。Resiliency refers to the tolerance for normal failures that occur in hardware components. 回復性は、障害から回復して、機能を継続する能力です。Resiliency is the ability to recover from failures and continue to function. 障害を回避することではなく、ダウンタイムまたはデータの損失を回避するように障害に対応することです。It's not about avoiding failures, but responding to failures in a way that avoids downtime or data loss. 回復性の目的は、障害後にアプリケーションを完全に機能している状態に戻すことです。The goal of resiliency is to return the application to a fully functioning state following a failure. Azure Virtual Machines とディスクは、一般的なハードウェア障害から復旧するように設計されています。Azure virtual machines and disks are designed to be resilient to common hardware faults. Azure IaaS プラットフォームがこの回復性をどのように提供するのか見てみましょう。Let's look at how the Azure IaaS platform provides this resiliency.

仮想マシンは、主にコンピューティング サーバーと永続的なディスクの 2 つの部分で構成されています。A virtual machine consists mainly of two parts: a compute server and the persistent disks. その両方が、仮想マシンのフォールト トレランスに影響します。Both affect the fault tolerance of a virtual machine.

VM を格納する Azure のコンピューティング ホスト サーバーで、まれにハードウェア障害が発生する場合、Azure が別のサーバー上で VM を自動的に復元するように設計されています。If the Azure compute host server that houses your VM experiences a hardware failure, which is rare, Azure is designed to automatically restore the VM on another server. このシナリオの場合、コンピューターが再起動し、しばらくしてから VM が再び起動します。If this scenario, your computer reboots, and the VM comes back up after some time. Azure はこのようなハードウェア障害を自動的に検出して復旧し、VM をできるだけ早く使用可能にすることをお客様に保証します。Azure automatically detects such hardware failures and executes recoveries to help ensure the customer VM is available as soon as possible.

IaaS のディスクに関していえば、データの持続性は、永続的なストレージ プラットフォームにとって重要です。Regarding IaaS disks, the durability of data is critical for a persistent storage platform. Azure のお客様は、重要なビジネス アプリケーションを IaaS で実行し、データの持続性に依存しています。Azure customers have important business applications running on IaaS, and they depend on the persistence of the data. Azure は、ローカルに格納されているデータの冗長コピーを 3 つ保持することで、これらの IaaS ディスクを保護するように設計されています。Azure designs protection for these IaaS disks, with three redundant copies of the data that is stored locally. これらのコピーによって、局所的な障害に対する高い持続性が提供されます。These copies provide for high durability against local failures. ディスクを保持するハードウェア コンポーネントの 1 つが故障しても、ディスクの要求をサポートする別のコピーが 2 つあるため、VM は影響を受けません。If one of the hardware components that holds your disk fails, your VM is not affected, because there are two additional copies to support disk requests. (まれですが) ディスクをサポートする別のハードウェア コンポーネントが 2 つ同時に故障した場合でも、正常に動作します。It works fine, even if two different hardware components that support a disk fail at the same time (which is rare).

常に 3 つのレプリカを維持できるように、Azure Storage では、3 つのコピーのいずれかが利用不可になった場合でも、データの新しいコピーをバックグラウンドで自動的に生成します。To ensure that you always maintain three replicas, Azure Storage automatically spawns a new copy of the data in the background if one of the three copies becomes unavailable. そのため、フォールト トレランス用に Azure ディスクで RAID を使用する必要はありません。Therefore, it should not be necessary to use RAID with Azure disks for fault tolerance. 大規模なボリュームの作成が必要な場合、ディスクのストライピングには、シンプルな RAID 0 構成で十分です。A simple RAID 0 configuration should be sufficient for striping the disks, if necessary, to create larger volumes.

このアーキテクチャにより、Azure は IaaS ディスクのエンタープライズ レベルの持続性を、業界トップ レベルの年間故障率 0% で一貫して提供できます。Because of this architecture, Azure has consistently delivered enterprise-grade durability for IaaS disks, with an industry-leading zero percent annualized failure rate.

コンピューティング ホストまたはストレージ プラットフォームの局所的なハードウェア障害によって、VM の可用性に関する Azure SLA で保証対象となっている VM が一時的に使用できなくなる場合があります。Localized hardware faults on the compute host or in the Storage platform can sometimes result in of the temporary unavailability of the VM that is covered by the Azure SLA for VM availability. Azure では、Azure Premium SSD を使用する単一の VM インスタンスを対象とする、業界トップ レベルの SLA も提供されています。Azure also provides an industry-leading SLA for single VM instances that use Azure premium SSDs.

ディスクまたは VM が一時的に使用できないことによるダウンタイムからアプリケーション ワークロードを保護するために、お客様は可用性セットを使用できます。To safeguard application workloads from downtime due to the temporary unavailability of a disk or VM, customers can use availability sets. 可用性セット内にある複数の仮想マシンによって、アプリケーションの冗長性が確保されます。Two or more virtual machines in an availability set provide redundancy for the application. Azure では、異なる電源、ネットワーク、サーバー コンポーネントを使用する別々の障害ドメインに、これらの VM とディスクが作成されます。Azure then creates these VMs and disks in separate fault domains with different power, network, and server components.

このような別々の障害ドメインにより、局所的なハードウェア障害は通常、セット内の複数の VM に同時に影響することはありません。Because of these separate fault domains, localized hardware failures typically do not affect multiple VMs in the set at the same time. 別々の障害ドメインを持つことで、アプリケーションの高可用性が実現されます。Having separate fault domains provides high availability for your application. 高可用性が要求される場合に、可用性セットを使用することは優れた選択であると考えられます。It's considered a good practice to use availability sets when high availability is required. 次のセクションでは、ディザスター リカバリーの側面について説明します。The next section covers the disaster recovery aspect.

バックアップと障害復旧Backup and disaster recovery

ディザスター リカバリーとは、まれに発生する大きなインシデントから復旧する能力です。Disaster recovery is the ability to recover from rare, but major, incidents. このようなインシデントには、リージョン全体に影響するサービス中断のように、一時的なものではない大規模な障害が含まれます。These incidents include non-transient, wide-scale failures, such as service disruption that affects an entire region. ディザスター リカバリーには、データ バックアップやアーカイブの他に、バックアップからのデータベースの復元などの手動操作も含まれる場合があります。Disaster recovery includes data backup and archiving, and might include manual intervention, such as restoring a database from a backup.

局所的な障害に対する Azure プラットフォーム組み込みの保護機能は、大規模な障害を引き起こす可能性がある大きな災害の場合には、VM/ディスクを完全に保護できない場合があります。The Azure platform’s built-in protection against localized failures might not fully protect the VMs/disks if a major disaster causes large-scale outages. このような大規模な障害には、データセンターがハリケーン、地震、火災に襲われた場合や、大規模なハードウェア ユニットの障害が発生した場合などの大惨事が含まれます。These large-scale outages include catastrophic events, such as if a datacenter is hit by a hurricane, earthquake, fire, or if there is a large-scale hardware unit failure. さらに、アプリケーションやデータの問題による障害が発生する可能性もあります。In addition, you might encounter failures due to application or data issues.

IaaS ワークロードを障害から保護するには、回復を可能にする冗長性とバックアップの計画を立てる必要があります。To help protect your IaaS workloads from outages, you should plan for redundancy and have backups to enable recovery. ディザスター リカバリーのためには、プライマリ サイトから地理的に離れた別の場所でバックアップをとる必要があります。For disaster recovery, you should back up in a different geographic location away from the primary site. この方法によって、VM またはディスクに最初に影響したものと同じ出来事がバックアップに影響することはなくなります。This approach helps ensure your backup is not affected by the same event that originally affected the VM or disks. 詳細については、「Disaster recovery for Azure applications (Azure アプリケーションのディザスター リカバリー)」をご覧ください。For more information, see Disaster recovery for Azure applications.

DR の考慮事項には、次の側面が含まれます。Your DR considerations might include the following aspects:

  • 高可用性:大幅なダウンタイムなしに、正常な状態で実行を継続するアプリケーションの能力です。High availability: The ability of the application to continue running in a healthy state, without significant downtime. "正常な状態" とは、アプリケーションが応答し、ユーザーがアプリケーションに接続して対話できるという意味です。By healthy state, this state means that the application is responsive, and users can connect to the application and interact with it. 特定のミッション クリティカルなアプリケーションとデータベースは、プラットフォームに障害が発生した場合でも、常に使用可能であることが求められます。Certain mission-critical applications and databases might be required to always be available, even when there are failures in the platform. これらのワークロードについては、データだけでなく、アプリケーションの冗長性を計画する必要があります。For these workloads, you might need to plan redundancy for the application, as well as the data.

  • データの持続性:主な検討事項が、災害が発生した場合にも確実にデータを保持することである場合もあります。Data durability: In some cases, the main consideration is ensuring that the data is preserved if a disaster happens. そのため、別のサイトでデータをバックアップする必要があるかもしれません。Therefore, you might need a backup of your data in a different site. このようなワークロードの場合、アプリケーションの完全な冗長性の必要はなく、ディスクの定期的なバックアップのみが必要となります。For such workloads, you might not need full redundancy for the application, but only a regular backup of the disks.

バックアップと DR シナリオBackup and DR scenarios

アプリケーション ワークロードのシナリオの一般的ないくつかの例と、ディザスター リカバリー計画に関する検討事項について考えてみましょう。Let’s look at a few typical examples of application workload scenarios and the considerations for planning for disaster recovery.

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

高可用性をサポートできる SQL Server または Oracle のような実稼働データベース サーバーについて考えてみます。Consider a production database server, like SQL Server or Oracle, that can support high availability. 重要な実稼働アプリケーションとユーザーは、このデータベースに依存しています。Critical production applications and users depend on this database. このシステムのディザスター リカバリー計画は、次の要件をサポートする必要があります。The disaster recovery plan for this system might need to support the following requirements:

  • データは保護され、かつ回復可能である必要があります。The data must be protected and recoverable.
  • サーバーは使用可能である必要があります。The server must be available for use.

ディザスター リカバリー計画では、異なるリージョンにバックアップとしてデータベースのレプリカを維持する必要があります。The disaster recovery plan might require maintaining a replica of the database in a different region as a backup. サーバーの可用性とデータ復旧の要件によっては、アクティブ/アクティブ レプリカ サイトまたはアクティブ/パッシブ レプリカ サイトから、データの定期的なオフライン バックアップまでに及ぶソリューションが考えられます。Depending on the requirements for server availability and data recovery, the solution might range from an active-active or active-passive replica site to periodic offline backups of the data. SQL Server、Oracle などのリレーショナル データベースでは、レプリケーションに関するさまざまなオプションが提供されています。Relational databases, such as SQL Server and Oracle, provide various options for replication. SQL Server では、高可用性を実現するために、SQL Server AlwaysOn 可用性グループを使用します。For SQL Server, use SQL Server AlwaysOn Availability Groups for high availability.

MongoDB のような NoSQL データベースでは、冗長性を実現するためにレプリカもサポートされています。NoSQL databases, like MongoDB, also support replicas for redundancy. 高可用性向けのレプリカが使用されます。The replicas for high availability are used.

シナリオ 2:冗長 VM のクラスターScenario 2: A cluster of redundant VMs

冗長性と負荷分散を提供する VM クラスターによって処理されるワークロードを検討します。Consider a workload handled by a cluster of VMs that provide redundancy and load balancing. 一例として、リージョンにデプロイされた Cassandra クラスターがあります。One example is a Cassandra cluster deployed in a region. このタイプのアーキテクチャは、リージョン内で高レベルの冗長性を既に提供しています。This type of architecture already provides a high level of redundancy within that region. ただし、リージョン レベルの障害からワークロードを保護するには、クラスターを 2 つのリージョンに分散させるか、別のリージョンに定期的なバックアップを実行することを検討する必要があります。However, to protect the workload from a regional-level failure, you should consider spreading the cluster across two regions or making periodic backups to another region.

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

IaaS アプリケーション ワークロードを見てみましょう。Let's look at the IaaS application workload. たとえば、Azure VM で実行されている一般的な実稼働ワークロードが考えられます。For example, this application might be a typical production workload running on an Azure VM. あるサイトのコンテンツと他のリソースを保持している Web サーバーまたはファイル サーバーが考えられます。It might be a web server or file server holding the content and other resources of a site. また、データ、リソース、アプリケーション状態などを VM ディスクに格納し、VM 上で実行されるカスタムビルドのビジネス アプリケーションかもしれません。It might also be a custom-built business application running on a VM that stored its data, resources, and application state on the VM disks. この場合は、定期的なバックアップを確実に行うことが重要です。In this case, it's important to make sure you take backups on a regular basis. バックアップの頻度は、VM のワークロードの特性に基づいている必要があります。Backup frequency should be based on the nature of the VM workload. たとえば、アプリケーションが毎日実行されてデータを変更している場合は、1 時間ごとにバックアップをとる必要があります。For example, if the application runs every day and modifies data, then the backup should be taken every hour.

別の例は、他のソースからデータをプルして集計レポートを生成するレポート サーバーです。Another example is a reporting server that pulls data from other sources and generates aggregated reports. この VM やディスクが失われると、レポートが失われることがあります。The loss of this VM or disks might lead to the loss of the reports. ただし、レポート プロセスを再実行し、出力を再生成できる場合があります。However, it might be possible to rerun the reporting process and regenerate the output. その場合は、レポート サーバーが災害に遭っても、実際にはデータは失われません。In that case, you don’t really have a loss of data, even if the reporting server is hit with a disaster. その結果、レポート サーバー上のデータの部分的な消失に対しては、耐性が高くなります。As a result, you might have a higher level of tolerance for losing part of the data on the reporting server. その場合は、バックアップの頻度を下げることが、コスト削減の方法の 1 つになります。In that case, less frequent backups are an option to reduce costs.

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

IaaS アプリケーション データの問題も別の可能性として存在します。IaaS application data issues are another possibility. 価格情報などの重要な商用データを計算し、保守し、提供するアプリケーションについて考えます。Consider an application that computes, maintains, and serves critical commercial data, such as pricing information. 新しいバージョンのアプリケーションには、価格を誤って計算するソフトウェア バグがあり、プラットフォームによって提供される既存の商用データが破損しました。A new version of your application had a software bug that incorrectly computed the pricing and corrupted the existing commerce data served by the platform. ここでの最善策は、アプリケーションとデータを以前のバージョンに戻すことです。Here, the best course of action is to revert to the earlier version of the application and the data. これを可能にするには、定期的にシステムのバックアップをとります。To enable this, take periodic backups of your system.

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

Azure Backup はバックアップとディザスター リカバリーに使用され、マネージド ディスクやアンマネージド ディスクと連携します。Azure Backup is used for backups and DR, and it works with managed disks as well as unmanaged disks. 時間ベースのバックアップ、VM の簡易復元、バックアップの保持ポリシーを使用して、バックアップ ジョブを作成することができます。You can create a backup job with time-based backups, easy VM restoration, and backup retention policies.

Premium SSDマネージド ディスク、またはその他のディスクの種類を、ローカル冗長ストレージ オプションと共に使用する場合は、定期的な DR バックアップを行うことが特に重要です。If you use premium SSDs, managed disks, or other disk types with the locally redundant storage option, it's especially important to make periodic DR backups. Azure Backup は、長期的に保有するためにデータを Recovery Services コンテナーに格納します。Azure Backup stores the data in your recovery services vault for long-term retention. バックアップの Recovery Services コンテナーには、geo 冗長ストレージ オプションを選択します。Choose the geo-redundant storage option for the backup recovery services vault. このオプションにより、バックアップが別の Azure リージョンにレプリケートされ、地域的な災害から保護されます。That option ensures that backups are replicated to a different Azure region for safeguarding from regional disasters.

アンマネージド ディスクについては、IaaS ディスクの場合はローカル冗長ストレージ タイプを使用できますが、Recovery Services コンテナーの場合は、Azure Backup を geo 冗長ストレージ オプションで有効にしてください。For unmanaged disks, you can use the locally redundant storage type for IaaS disks, but ensure that Azure Backup is enabled with the geo-redundant storage option for the recovery services vault.

注意

非管理対象ディスクに対して geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージ オプションを使用する場合は、バックアップと DR の整合性スナップショットが必要です。If you use the geo-redundant storage or read-access geo-redundant storage option for your unmanaged disks, you still need consistent snapshots for backup and DR. Azure Backup または整合性スナップショットを使用します。Use either Azure Backup or consistent snapshots.

DR に使用可能なソリューションの概要を次の表に示します。The following table is a summary of the solutions available for DR.

シナリオScenario 自動レプリケーションAutomatic replication DR ソリューションDR solution
Premium SSD ディスクPremium SSD disks ローカル (ローカル冗長ストレージ)Local (locally redundant storage) Azure BackupAzure Backup
マネージド ディスクManaged disks ローカル (ローカル冗長ストレージ)Local (locally redundant storage) Azure BackupAzure Backup
非管理対象ローカル冗長ストレージ ディスクUnmanaged locally redundant storage disks ローカル (ローカル冗長ストレージ)Local (locally redundant storage) Azure BackupAzure Backup
非管理対象 geo 冗長ストレージ ディスクUnmanaged geo-redundant storage disks リージョン間 (geo 冗長ストレージ)Cross region (geo-redundant storage) Azure BackupAzure Backup
整合性スナップショットConsistent snapshots
非管理対象読み取りアクセス geo 冗長ストレージ ディスクUnmanaged read-access geo-redundant storage disks リージョン間 (読み取りアクセス geo 冗長ストレージ)Cross region (read-access geo-redundant storage) Azure BackupAzure Backup
整合性スナップショットConsistent snapshots

高可用性は、可用性セット内のマネージド ディスクを Azure Backup と共に使用することで最もよく対応できます。High availability is best met by using managed disks in an availability set along with Azure Backup. 非管理対象ディスクを使用する場合は、DR 用 Azure Backup を使用できます。If you use unmanaged disks, you can still use Azure Backup for DR. Azure Backup を使用できない場合、後のセクションで説明するように、整合性スナップショットを利用することがバックアップと DR の代替ソリューションとなります。If you are unable to use Azure Backup, then taking consistent snapshots, as described in a later section, is an alternative solution for backup and DR.

アプリケーションまたはインフラストラクチャ レベルでの高可用性、バックアップ、DRの選択は、次のように表すことができます。Your choices for high availability, backup, and DR at application or infrastructure levels can be represented as follows:

LevelLevel 高可用性High availability バックアップまたは DRBackup or DR
ApplicationApplication SQL Server AlwaysOnSQL Server AlwaysOn Azure BackupAzure Backup
インフラストラクチャInfrastructure 可用性セットAvailability set 整合性スナップショットと geo 冗長ストレージGeo-redundant storage with consistent snapshots

Azure Backup の使用Using Azure Backup

Azure Backup では、Azure Recovery Services コンテナーに Windows または Linux を実行する VM をバックアップできます。Azure Backup can back up your VMs running Windows or Linux to the Azure recovery services vault. 業務に不可欠なデータのバックアップと復元は、その生成元となるアプリケーションの実行中にバックアップを行う必要があるため、簡単ではありません。Backing up and restoring business-critical data is complicated by the fact that business-critical data must be backed up while the applications that produce the data are running.

この課題に対処するために、Azure Backup は、Microsoft のワークロードに対してアプリケーション整合性バックアップを提供します。To address this issue, Azure Backup provides application-consistent backups for Microsoft workloads. ボリューム シャドウ サービスを使用して、データがストレージに正しく書き込まれるようにします。It uses the volume shadow service to ensure that data is written correctly to storage. Linux にはボリューム シャドウ サービスに相当する機能がないため、Linux VM についてはファイル整合バックアップのみが可能です。For Linux VMs, only file-consistent backups are possible, because Linux does not have functionality equivalent to the volume shadow service.

Azure Backup のフロー

Azure Backup がスケジュールされた時刻にバックアップ ジョブを開始すると、VM にインストールされたバックアップ拡張機能をトリガーして特定の時点のスナップショットを作成します。When Azure Backup initiates a backup job at the scheduled time, it triggers the backup extension installed in the VM to take a point-in-time snapshot. スナップショットはボリューム シャドウ サービスと連携して作成されるため、シャットダウンせずに、仮想マシンに使用されているディスクの一貫したスナップショットを取得することができます。A snapshot is taken in coordination with the volume shadow service to get a consistent snapshot of the disks in the virtual machine without having to shut it down. VM のバックアップの拡張機能は、すべての書き込みをフラッシュした後に、すべてのディスクの整合性スナップショットを作成します。The backup extension in the VM flushes all writes before taking a consistent snapshot of all of the disks. スナップショットが作成されると、データは Azure Backup によってバックアップ コンテナーに転送されます。After taking the snapshot, the data is transferred by Azure Backup to the backup vault. バックアップ プロセスの効率を高めるために、前回のバックアップ以降に変更されたデータ ブロックがサービスによって特定され、そのデータのみが転送されます。To make the backup process more efficient, the service identifies and transfers only the blocks of data that have changed after the last backup.

復元するには、Azure Backup を使用して使用可能なバックアップを表示し、復元を開始します。To restore, you can view the available backups through Azure Backup and then initiate a restore. Azure Portal 経由で、PowerShell を使用して、または Azure CLI を使用して、Azure バックアップを作成および復元できます。You can create and restore Azure backups through the Azure portal, by using PowerShell, or by using the Azure CLI.

バックアップを有効にする手順Steps to enable a backup

Azure Portal を使用して VM のバックアップを有効にするには次の手順に従います。Use the following steps to enable backups of your VMs by using the Azure portal. 実際のシナリオに応じて、いくつかのバリエーションがあります。There is some variation depending on your exact scenario. 完全な詳細情報については、Azure Backupに関するドキュメントをご覧ください。Refer to the Azure Backup documentation for full details. Azure Backup はマネージド ディスクを使用する VM もサポートします。Azure Backup also supports VMs with managed disks.

  1. VM 用の Recovery Services コンテナーを作成する:Create a recovery services vault for a VM:

    a.a. Azure Portal を使用して、すべてのリソースを参照し、「Recovery Services コンテナー」を検索します。In the Azure portal, browse All resources and find Recovery Services vaults.

    b.b. Recovery Services コンテナー メニューで、[追加] をクリックし、VM と同じリージョンで新しいコンテナーを作成する手順に従います。On the Recovery Services vaults menu, click Add and follow the steps to create a new vault in the same region as the VM. たとえば、VM が米国西部リージョンにある場合は、コンテナーに米国西部を選択します。For example, if your VM is in the West US region, pick West US for the vault.

  2. 新しく作成されたコンテナーのストレージ レプリケーションを確認します。Verify the storage replication for the newly created vault. [Recovery Services コンテナー] でコンテナーにアクセスし、[設定] > [構成のバックアップ] に移動します。Access the vault under Recovery Services vaults and go to Settings > Backup Configuration. [geo 冗長ストレージ] オプションが既定で選択されていることを確認します。Ensure the geo-redundant storage option is selected by default. このオプションを選択すると、コンテナーがセカンダリ データセンターに自動的にレプリケートされます。This option ensures that your vault is automatically replicated to a secondary datacenter. たとえば、米国西部のコンテナーは、米国東部に自動的にレプリケートされます。For example, your vault in West US is automatically replicated to East US.

  3. バックアップ ポリシーを構成し、同じ UI から VM を選択します。Configure the backup policy and select the VM from the same UI.

  4. Backup エージェントが VM にインストールされていることを確認します。Make sure the Backup Agent is installed on the VM. VM が Azure ギャラリー イメージを使用して作成されている場合、Backup エージェントは既にインストールされています。If your VM is created by using an Azure gallery image, then the Backup Agent is already installed. それ以外の場合は (つまりカスタム イメージを使用する場合)、仮想マシンに VM エージェントをインストールする手順を使用します。Otherwise (that is, if you use a custom image), use the instructions to install the VM agent on a virtual machine.

  5. バックアップ サービスが動作するために、ネットワーク接続が VM によって許可されていることを確認します。Make sure that the VM allows network connectivity for the backup service to function. ネットワーク接続に関する手順に従ってください。Follow the instructions for network connectivity.

  6. 上記の手順を完了すると、バックアップ ポリシーで指定されているとおり、バックアップが定期的に実行されます。After the previous steps are completed, the backup runs at regular intervals as specified in the backup policy. 必要に応じて、Azure Portal のコンテナー ダッシュボードから、最初のバックアップを手動でトリガーできます。If necessary, you can trigger the first backup manually from the vault dashboard on the Azure portal.

スクリプトを使用した Azure Backup の自動化については、VM バックアップ用の PowerShell コマンドレットに関するページをご覧ください。For automating Azure Backup by using scripts, refer to PowerShell cmdlets for VM backup.

回復の手順Steps for recovery

VM を修復またはリビルドする必要がある場合は、コンテナーのバックアップ復旧ポイントのいずれかから VM を復元できます。If you need to repair or rebuild a VM, you can restore the VM from any of the backup recovery points in the vault. 復旧の実施方法には 2 つのオプションがあります。There are a couple of different options for performing the recovery:

  • 特定の時点のバックアップ VM として、新しい VM を作成できます。You can create a new VM as a point-in-time representation of your backed-up VM.

  • ディスクを復元した後に VM のテンプレートを使用して、復元された VM をカスタマイズし、リビルドすることができます。You can restore the disks, and then use the template for the VM to customize and rebuild the restored VM.

詳細については、「Azure Portal を使用した仮想マシンの復元」の手順をご覧ください。For more information, see the instructions to use the Azure portal to restore virtual machines. このドキュメントでは、プライマリ データセンターの災害の場合に、geo 冗長バックアップ コンテナーを使用して、対となるデータセンターに VM のバックアップを復元するための特定の手順も説明します。This document also explains the specific steps for restoring backed-up VMs to a paired datacenter by using your geo-redundant backup vault if there is a disaster at the primary datacenter. その場合、Azure Backup では、セカンダリ リージョンからコンピューティング サービスを使用して、復元された仮想マシンを作成します。In that case, Azure Backup uses the Compute service from the secondary region to create the restored virtual machine.

また、復元されたディスクからの新しい VM の作成には、PowerShell を使用できます。You can also use PowerShell for creating a new VM from restored disks.

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

Azure Backup を使用できない場合は、スナップショットを使用して、独自のバックアップ メカニズムを実装できます。If you are unable to use Azure Backup, you can implement your own backup mechanism by using snapshots. VM で使用されるすべてのディスクの整合性スナップショットを作成し、そのスナップショットを別のリージョンにレプリケートする方法は複雑です。Creating consistent snapshots for all the disks used by a VM and then replicating those snapshots to another region is complicated. このため、Azure では、バックアップ サービスの使用はカスタム ソリューションの構築よりも良いオプションであると考えています。For this reason, Azure considers using the Backup service as a better option than building a custom solution.

ディスクの読み取りアクセス geo 冗長ストレージ/geo 冗長ストレージを使用する場合、スナップショットはセカンダリ データセンターに自動的にレプリケートされます。If you use read-access geo-redundant storage/geo-redundant storage for disks, snapshots are automatically replicated to a secondary datacenter. ディスクのローカル冗長ストレージを使用する場合は、自分でデータをレプリケートする必要があります。If you use locally redundant storage for disks, you need to replicate the data yourself. 詳細については、「増分スナップショットを使用した Azure 非管理 VM ディスクのバックアップ」をご覧ください。For more information, see Back up Azure-unmanaged VM disks with incremental snapshots.

スナップショットは、特定の時点におけるオブジェクトを表現したものです。A snapshot is a representation of an object at a specific point in time. スナップショットによって、保持しているデータのサイズの増分に対する請求が発生します。A snapshot incurs billing for the incremental size of the data it holds. 詳細については、「BLOB のスナップショットの作成」をご覧ください。For more information, see Create a blob snapshot.

VM の実行中にスナップショットを作成するCreate snapshots while the VM is running

スナップショットはいつでも取得可能ですが、VM を実行している場合は、ディスクに送信されている最中のデータが存在します。Although you can take a snapshot at any time, if the VM is running, there is still data being streamed to the disks. そのため、スナップショットには実行中のオペレーションが部分的に含まれる場合があります。The snapshots might contain partial operations that were in flight. また、複数のディスクが対象となっている場合は、それぞれのディスクのスナップショットが異なる時刻に取得された可能性があります。Also, if there are several disks involved, the snapshots of different disks might have occurred at different times. このようなシナリオでは、スナップショットが調整されないことがあります。These scenarios may cause to the snapshots to be uncoordinated. このような調整がない場合、バックアップ中に変更が行われた場合にファイルが破損する可能性があるストライプ ボリュームでは、特に問題です。This lack of co-ordination is especially problematic for striped volumes whose files might be corrupted if changes were being made during backup.

この状況を避けるために、バックアップ プロセスで次の手順を実施する必要があります。To avoid this situation, the backup process must implement the following steps:

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

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

  3. すべてのディスクの BLOB スナップショットを作成します。Create a blob snapshot for all the disks.

SQL Server などの一部の Windows アプリケーションは、アプリケーション整合性バックアップを作成するボリューム シャドウ サービスを通して、連携のとれたバックアップ メカニズムを提供します。Some Windows applications, like SQL Server, provide a coordinated backup mechanism via a volume shadow service to create application-consistent backups. Linux では、ディスクを調整するために fsfreeze などのツールを使用できます。On Linux, you can use a tool like fsfreeze for coordinating the disks. このツールはファイル整合性バックアップを提供していますが、アプリケーション整合性スナップショットは提供していません。This tool provides file-consistent backups, but not application-consistent snapshots. このプロセスは複雑なため、Azure Backup を使用するか、既にこの手順を実装しているサード パーティーのバックアップ ソリューションを使用することを検討する必要があります。This process is complex, so you should consider using Azure Backup or a third-party backup solution that already implements this procedure.

上記のプロセスによって、すべての VM ディスクに対する連携のとれた一連のスナップショットが生成されます。これは、特定の時点の VM の状態を表します。The previous process results in a collection of coordinated snapshots for all of the VM disks, representing a specific point-in-time view of the VM. これが、VM のバックアップの復元ポイントです。This is a backup restore point for the VM. スケジュールされた間隔で処理を繰り返し、定期的にバックアップを作成できます。You can repeat the process at scheduled intervals to create periodic backups. DR のためにスナップショットを別のリージョンにコピーする手順については、「スナップショットを別のリージョンにコピーする」をご覧ください。See Copy the backups to another region for steps to copy the snapshots to another region for DR.

VM がオフラインのときにスナップショットを作成するCreate snapshots while the VM is offline

整合性バックアップを作成する別のオプションは、VM をシャット ダウンし、各ディスクの BLOB スナップショットを作成することです。Another option to create consistent backups is to shut down the VM and take blob snapshots of each disk. BLOB スナップショットの作成は、実行中の VM のスナップショットの連携よりも簡単ですが、数分間のダウンタイムが必要です。Taking blob snapshots is easier than coordinating snapshots of a running VM, but it requires a few minutes of downtime.

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

  2. 各仮想ハード ドライブ BLOB のスナップショットを作成します。これにはほんの数秒しかかかりません。Create a snapshot of each virtual hard drive blob, which only takes a few seconds.

    スナップショットを作成するには、PowerShellAzure Storage REST APIAzure CLI、または .NET 用 ストレージ クライアント ライブラリなどの Azure Storage クライアント ライブラリのいずれかを使用できます。To create a snapshot, you can use PowerShell, the Azure Storage REST API, Azure CLI, or one of the Azure Storage client libraries, such as the Storage client library for .NET.

  3. VM を起動します。これによってダウンタイムが終了します。Start the VM, which ends the downtime. 通常、プロセス全体が数分以内に完了します。Typically, the entire process finishes within a few minutes.

このプロセスによって、すべてのディスクに対する一連の整合性スナップショットが生成され、VM のバックアップの復元ポイントが得られます。This process yields a collection of consistent snapshots for all the disks, providing a backup restore point for the VM.

スナップショットを別のリージョンにコピーするCopy the snapshots to another region

スナップショットを作成しただけでは、DR には不十分です。Creation of the snapshots alone might not be sufficient for DR. 別のリージョンにスナップショット バックアップをレプリケートする必要もあります。You must also replicate the snapshot backups to another region.

ディスクの geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージを使用する場合、スナップショットはセカンダリ リージョンに自動的にレプリケートされます。If you use geo-redundant storage or read-access geo-redundant storage for your disks, then the snapshots are replicated to the secondary region automatically. レプリケーション前に数分の遅延が発生する可能性があります。There can be a few minutes of lag before the replication. スナップショットのレプリケートが完了する前にプライマリ データセンターがダウンした場合は、セカンダリ データセンターからスナップショットにアクセスすることはできません。If the primary datacenter goes down before the snapshots finish replicating, you cannot access the snapshots from the secondary datacenter. この可能性は低いです。The likelihood of this is small.

注意

geo 冗長ストレージ アカウントまたは読み取りアクセス geo 冗長ストレージ アカウントにディスクを持っているだけでは、VM は障害から保護されません。Only having the disks in a geo-redundant storage or read-access geo-redundant storage account does not protect the VM from disasters. ユーザーは、連携のとれたスナップショットを作成するか、Azure Backup を使用する必要もあります。You must also create coordinated snapshots or use Azure Backup. これは、VM を整合性のある状態に回復するために必要です。This is required to recover a VM to a consistent state.

ローカル冗長ストレージを使用する場合は、スナップショットを作成した後、別のストレージ アカウントにスナップショットをすぐにコピーする必要があります。If you use locally redundant storage, you must copy the snapshots to a different storage account immediately after creating the snapshot. コピーのターゲットは、異なるリージョンのローカル冗長ストレージ ストレージ アカウントであり、結果的にリモート リージョンのコピーになります。The copy target might be a locally redundant storage account in a different region, resulting in the copy being in a remote region. 同じリージョン内の読み取りアクセス geo 冗長ストレージ アカウントにスナップショットをコピーすることもできます。You can also copy the snapshot to a read-access geo-redundant storage account in the same region. この場合、スナップショットはリモート セカンダリ リージョンにゆっくりとレプリケートされます。In this case, the snapshot is lazily replicated to the remote secondary region. コピーとレプリケーションが完了すると、バックアップはプライマリ サイトの障害から保護されます。Your backup is protected from disasters at the primary site after the copying and replication is complete.

DR 用の増分スナップショットを効率的にコピーするには、「増分スナップショットを使用した Azure 非管理 VM ディスクのバックアップ」の手順を確認してください。To copy your incremental snapshots for DR efficiently, review the instructions in Back up Azure unmanaged VM disks with incremental snapshots.

増分スナップショットを使用した Azure 非管理 VM ディスクのバックアップ

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

スナップショットを取得するには、スナップショットをコピーして新しい BLOB を作成します。To retrieve a snapshot, copy it to make a new blob. プライマリ アカウントからスナップショットをコピーする場合は、スナップショットをスナップショットのベース BLOB にコピーできます。If you are copying the snapshot from the primary account, you can copy the snapshot over to the base blob of the snapshot. このプロセスにより、ディスクがスナップショットに戻ります。This process reverts the disk to the snapshot. このプロセスは、スナップショットの昇格として知られています。This process is known as promoting the snapshot. 読み取りアクセス geo 冗長ストレージ アカウントでセカンダリ アカウントからスナップショット バックアップをコピーする場合は、プライマリ アカウントにコピーする必要があります。If you are copying the snapshot backup from a secondary account, in the case of a read-access geo-redundant storage account, you must copy it to a primary account. PowerShell を使用して、または AzCopy ユーティリティを使用して、スナップショットをコピーすることができます。You can copy a snapshot by using PowerShell or by using the AzCopy utility. 詳細については、AzCopy コマンド ライン ユーティリティを使用したデータの転送に関するページをご覧ください。For more information, see Transfer data with the AzCopy command-line utility.

複数のディスクを持つ VM の場合は、連携のとれた同じ復元ポイントの一部であるスナップショットをすべてコピーする必要があります。For VMs with multiple disks, you must copy all the snapshots that are part of the same coordinated restore point. 書き込み可能な VHD BLOB にスナップショットをコピーしたら、BLOB を使用して、VM のテンプレートを利用して VM を再作成できます。After you copy the snapshots to writable VHD blobs, you can use the blobs to recreate your VM by using the template for the VM.

その他のオプションOther options

SQL ServerSQL Server

VM で実行されている SQL Server には、SQL Server データベースを Azure Blob Storage やファイル共有にバックアップする独自の組み込み機能があります。SQL Server running in a VM has its own built-in capabilities to back up your SQL Server database to Azure Blob storage or a file share. ストレージ アカウントが geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージである場合は、障害発生時にストレージ アカウントのセカンダリ データセンターにあるバックアップにアクセスできます。前述したものと同じ制約があります。If the storage account is geo-redundant storage or read-access geo-redundant storage, you can access those backups in the storage account’s secondary datacenter in the event of a disaster, with the same restrictions as previously discussed. 詳細については、「Azure Virtual Machines における SQL Server のバックアップと復元」をご覧ください。For more information, see Back up and restore for SQL Server in Azure virtual machines. バックアップと復元に加えて、SQL Server AlwaysOn 可用性グループではデータベースのセカンダリ レプリカを管理できます。In addition to back up and restore, SQL Server AlwaysOn availability groups can maintain secondary replicas of databases. この機能により、ディザスター リカバリーの時間が大幅に短縮されます。This ability greatly reduces the disaster recovery time.

その他の考慮事項Other considerations

この記事では、ディザスター リカバリーをサポートするために、VM とそのディスクのバックアップやスナップショットを取得する方法と、そのバックアップまたはスナップショットを使用してデータを復旧する方法について説明しました。This article has discussed how to back up or take snapshots of your VMs and their disks to support disaster recovery and how to use those backups or snapshots to recover your data. Azure Resource Manager モデルでは、多くのユーザーはテンプレートを使用して、Azure で各自の VM とその他のインフラストラクチャを作成します。With the Azure Resource Manager model, many people use templates to create their VMs and other infrastructures in Azure. テンプレートを使用すると、毎回同じ構成を持つ VM を作成できます。You can use a template to create a VM that has the same configuration every time. VM の作成にカスタム イメージを使用する場合は、イメージを格納する読み取りアクセス geo 冗長ストレージ アカウントを使用して、イメージが保護されていることも確認する必要があります。If you use custom images for creating your VMs, you must also make sure that your images are protected by using a read-access geo-redundant storage account to store them.

そのため、バックアップ プロセスには次の 2 つの組み合わせがあります。Consequently, your backup process can be a combination of two things:

  • データ (ディスク) をバックアップします。Back up the data (disks).
  • 構成 (テンプレートとカスタム イメージ) をバックアップします。Back up the configuration (templates and custom images).

選択したバックアップ オプションに応じて、ユーザーがデータと構成の両方のバックアップを処理する必要があるか、バックアップ サービスがすべてを処理します。Depending on the backup option you choose, you might have to handle the backup of both the data and the configuration, or the backup service might handle all of that for you.

付録:データの冗長性の影響を理解するAppendix: Understanding the impact of data redundancy

Azure のストレージ アカウントについては、ディザスター リカバリーに関して考慮すべき 3 種類のデータの冗長性があります。すなわち、ローカル冗長、geo 冗長、読み取りアクセスを伴う geo 冗長です。For storage accounts in Azure, there are three types of data redundancy that you should consider regarding disaster recovery: locally redundant, geo-redundant, or geo-redundant with read access.

ローカル冗長ストレージには、同じデータセンター内のデータのコピーが 3 つ保持されています。Locally redundant storage retains three copies of the data in the same datacenter. VM がデータを書き込むと、3 つのすべてのコピーが更新され、処理が成功したことが呼び出し元に返されるため、3 つが同じものであることがわかります。When the VM writes the data, all three copies are updated before success is returned to the caller, so you know they are identical. 3 つのすべてのコピーが同時に影響を受ける可能性は低いため、ディスクは局所的な障害から保護されています。Your disk is protected from local failures, because it's unlikely that all three copies are affected at the same time. ローカル冗長ストレージの場合は geo 冗長性がないため、データセンター全体またはストレージ ユニット全体に影響するような壊滅的な障害からは、ディスクは保護されていません。In the case of locally redundant storage, there is no geo-redundancy, so the disk is not protected from catastrophic failures that can affect an entire datacenter or storage unit.

geo 冗長ストレージと読み取りアクセス geo 冗長ストレージでは、データの 3 つのコピーはユーザーが選択したプライマリ リージョンに保持されます。With geo-redundant storage and read-access geo-redundant storage, three copies of your data are retained in the primary region that is selected by you. さらに 3 つのデータのコピーが、Azure 側で設定された対応するセカンダリ リージョンに保持されます。Three more copies of your data are retained in a corresponding secondary region that is set by Azure. たとえば、米国西部にデータを格納する場合、データは米国東部にレプリケートされます。For example, if you store data in West US, the data is replicated to East US. コピーの保持は非同期で行われ、プライマリ サイトとセカンダリ サイトの更新の間には小さな遅延が発生します。Copy retention is done asynchronously, and there is a small delay between updates to the primary and secondary sites. セカンダリ サイト上のディスクのレプリカにはディスクごとに一貫性がありますが (遅延あり)、複数のアクティブなディスクのレプリカは、互いに同期していない可能性があります。Replicas of the disks on the secondary site are consistent on a per-disk basis (with the delay), but replicas of multiple active disks might not be in sync with each other. 複数のディスクにわたって一貫性のあるレプリカを持つには、一貫性のあるスナップショットが必要です。To have consistent replicas across multiple disks, consistent snapshots are needed.

geo 冗長ストレージと読み取りアクセス geo 冗長ストレージの主な違いは、読み取りアクセス geo 冗長ストレージを使えば、セカンダリ コピーをいつでも読み取ることができる点です。The main difference between geo-redundant storage and read-access geo-redundant storage is that with read-access geo-redundant storage, you can read the secondary copy at any time. プライマリ リージョンのデータにアクセスできない問題がある場合、Azure チームはデータへのアクセスを復元するために、あらゆる努力をします。If there is a problem that renders the data in the primary region inaccessible, the Azure team makes every effort to restore access. プライマリがダウンしていても、読み取りアクセス geo 冗長ストレージを有効にした場合は、セカンダリ データセンターのデータにアクセスできます。While the primary is down, if you have read-access geo-redundant storage enabled, you can access the data in the secondary datacenter. そのため、プライマリにアクセスできないときにレプリカから読み取る計画である場合は、読み取りアクセス geo 冗長ストレージを検討する必要があります。Therefore, if you plan to read from the replica while the primary is inaccessible, then read-access geo-redundant storage should be considered.

重大な停止であることが判明した場合、Azure チームは geo フェールオーバーをトリガーし、プライマリ DNS エントリを変更して 2 次記憶装置を指すようにすることができます。If it turns out to be a significant outage, the Azure team might trigger a geo-failover and change the primary DNS entries to point to secondary storage. この時点でgeo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージが有効になっている場合は、セカンダリとして使用されていたリージョンのデータにアクセスできます。At this point, if you have either geo-redundant storage or read-access geo-redundant storage enabled, you can access the data in the region that used to be the secondary. つまり、ストレージ アカウントが geo 冗長ストレージであり、かつ問題が発生する場合は、geo フェールオーバーを実行する場合にのみ、2 次記憶装置にアクセスできます。In other words, if your storage account is geo-redundant storage and there is a problem, you can access the secondary storage only if there is a geo-failover.

詳細については、「Azure Storage の停止が発生した場合の対処方法」をご覧ください。For more information, see What to do if an Azure Storage outage occurs.

注意

フェールオーバーを実行するかどうかを制御するのは Microsoft です。Microsoft controls whether a failover occurs. フェールオーバーはストレージ アカウントごとに制御されるものではないため、個々のお客様が決定することはできません。Failover is not controlled per storage account, so it's not decided by individual customers. 特定のストレージ アカウントまたは仮想マシンのディスクのディザスター リカバリーを実装するには、この記事で既に説明した手法を使用する必要があります。To implement disaster recovery for specific storage accounts or virtual machine disks, you must use the techniques described previously in this article.