Azure SQL Database によるビジネス継続性の概要Overview of business continuity with Azure SQL Database

Azure SQL Database でのビジネス継続性とは、中断 (特にそのコンピューティング インフラストラクチャに対する) が発生した場合でもビジネス活動を続けることができるようにするメカニズム、ポリシー、手順を指します。Business continuity in Azure SQL Database refers to the mechanisms, policies, and procedures that enable your business to continue operating in the face of disruption, particularly to its computing infrastructure. ほとんどの場合、Azure SQL Database はクラウド環境で発生する可能性がある破壊的なイベントを処理し、アプリケーションとビジネス プロセスの実行を維持します。In the most of the cases, Azure SQL Database will handle the disruptive events that might happen in the cloud environment and keep your applications and business processes running. ただし、次のような SQL Database では対処できない破壊的なイベントがあります。However, there are some disruptive events that cannot be handled by SQL Database such as:

  • ユーザーが誤ってテーブルの行を削除または更新した。User accidentally deleted or updated a row in a table.
  • 悪意のある攻撃者がデータの削除やデータベースの削除に成功した。Malicious attacker succeeded to delete data or drop a database.
  • 地震により停電が発生し、データ センターが一時的に利用不可になった。Earthquake caused a power outage and temporary disabled data-center.

これらの場合は Azure SQL Database では制御できないので、データを回復し、アプリケーションの実行を維持できるようにする SQL Database のビジネス継続性機能を使用する必要があります。These cases cannot be controlled by Azure SQL Database, so you would need to use the business continuity features in SQL Database that enables you to recover your data and keep your applications running.

この概要では、Azure SQL Database に用意されているビジネス継続性と障害復旧の機能について説明し、This overview describes the capabilities that Azure SQL Database provides for business continuity and disaster recovery. データ損失につながる、またはデータベースやアプリケーションを使用不能状態に追い込む破壊的なイベントから復旧するためのオプション、推奨事項、およびチュートリアルについて説明します。Learn about options, recommendations, and tutorials for recovering from disruptive events that could cause data loss or cause your database and application to become unavailable. ユーザーまたはアプリケーション エラーがデータ整合性に影響を及ぼすとき、Azure リージョンでシステム停止が発生したとき、あるいはアプリケーションにメンテナンスが必要なときの対処方法について説明します。Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

ビジネス継続性を提供するときに使用できる SQL Database の機能SQL Database features that you can use to provide business continuity

データベースの観点からは、発生する可能性のある 4 つの主要な障害シナリオがあります。From a database perspective, there are four major potential disruption scenarios:

  • ディスク ドライブの障害など、データベース ノードに影響するローカルなハードウェアまたはソフトウェアの障害。Local hardware or software failures affecting the database node such as a disk-drive failure.
  • 通常はアプリケーションのバグや人的ミスによって発生するデータの破損または削除。Data corruption or deletion typically caused by an application bug or human error. このようなエラーは本質的にアプリケーションに固有であり、一般に、インフラストラクチャによって自動的に検出または軽減することはできません。Such failures are intrinsically application-specific and cannot as a rule be detected or mitigated automatically by the infrastructure.
  • 自然災害による可能性がある、データ センターの停止。Datacenter outage, possibly caused by a natural disaster. このシナリオでは、代替データ センターへのアプリケーションのフェールオーバーを含む何らかのレベルの geo 冗長性が必要です。This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • アップグレードまたはメンテナンスのエラー。アプリケーションまたはデータベースの計画的なアップグレードまたはメンテナンスの間に予期しない問題が発生したときは、以前のデータベースの状態に迅速にロールバックすることが必要な場合があります。Upgrade or maintenance errors, unanticipated issues that occur during planned upgrades or maintenance to an application or database may require rapid rollback to a prior database state.

SQL Database には、自動バックアップやオプションのデータベース レプリケーションなど、これらのシナリオを軽減できるビジネス継続性の機能がいくつか用意されており、SQL Database provides several business continuity features, including automated backups and optional database replication that can mitigate these scenarios. 最初に、ビジネス プロセスに影響を与える可能性がある破壊的なイベントに対して、SQL Database の高可用性アーキテクチャが 99.99% の可用性と回復性を提供する方法を理解しておく必要があります。First, you need to understand how SQL Database high availability architecture provides 99.99% availability and resiliency to some disruptive events that might affect your business process. その後は、SQL Database の高可用性アーキテクチャでは処理できない破壊的なイベントから回復するために使用できる、次のような他のメカニズムについて学習できます。Then, you can learn about the additional mechanisms that you can use to recover from the disruptive events that cannot be handled by SQL Database high availability architecture, such as:

推定復旧時間 (ERT) と、最近のトランザクションに対する潜在的なデータ損失の特徴が、それぞれ異なります。Each has different characteristics for estimated recovery time (ERT) and potential data loss for recent transactions. オプションについて理解したら、その中から適切なものを選択できます。これらのオプションは、ほとんどの場合、さまざまなシナリオに対して組み合わせて使用できます。Once you understand these options, you can choose among them - and, in most scenarios, use them together for different scenarios. ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解する必要があります。As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event. アプリケーションを完全に復旧するために必要な時間は、目標復旧時間 (RTO) と呼ばれます。The time required for application to fully recover is known as recovery time objective (RTO). さらに、破壊的なイベントの発生後、復旧中にアプリケーションが損失を許容できる最大データ更新 (期間) 量についても理解しなければなりません。You also need to understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering after the disruptive event. 損失を許容できる更新の期間は、目標復旧時点 (RPO) と呼ばれます。The time period of updates that you might afford to lose is known as recovery point objective (RPO).

次の表では、最も一般的なシナリオについて、サービス レベルごとの ERT と RPO を比較しています。The following table compares the ERT and RPO for each service tier for the most common scenarios.

機能Capability BasicBasic 標準Standard PremiumPremium 汎用General Purpose Business CriticalBusiness Critical
バックアップからのポイントインタイム リストアPoint in Time Restore from backup 7 日間以内のあらゆる復元ポイントAny restore point within seven days 35 日間以内のあらゆる復元ポイントAny restore point within 35 days 35 日間以内のあらゆる復元ポイントAny restore point within 35 days 構成済み期間内の任意の復元ポイント (最大 35 日間)Any restore point within configured period (up to 35 days) 構成済み期間内の任意の復元ポイント (最大 35 日間)Any restore point within configured period (up to 35 days)
Geo レプリケーション バックアップからの geo リストアGeo-restore from geo-replicated backups ERT < 12 時間ERT < 12 h
RPO < 1 時間RPO < 1 h
ERT < 12 時間ERT < 12 h
RPO < 1 時間RPO < 1 h
ERT < 12 時間ERT < 12 h
RPO < 1 時間RPO < 1 h
ERT < 12 時間ERT < 12 h
RPO < 1 時間RPO < 1 h
ERT < 12 時間ERT < 12 h
RPO < 1 時間RPO < 1 h
自動フェールオーバー グループAuto-failover groups RTO = 1 時間RTO = 1 h
RPO < 5 秒RPO < 5s
RTO = 1 時間RTO = 1 h
RPO < 5 秒RPO < 5 s
RTO = 1 時間RTO = 1 h
RPO < 5 秒RPO < 5 s
RTO = 1 時間RTO = 1 h
RPO < 5 秒RPO < 5 s
RTO = 1 時間RTO = 1 h
RPO < 5 秒RPO < 5 s
手動のデータベース フェールオーバーManual database failover ERT = 30 秒ERT = 30 s
RPO < 5 秒RPO < 5s
ERT = 30 秒ERT = 30 s
RPO < 5 秒RPO < 5 s
ERT = 30 秒ERT = 30 s
RPO < 5 秒RPO < 5 s
ERT = 30 秒ERT = 30 s
RPO < 5 秒RPO < 5 s
ERT = 30 秒ERT = 30 s
RPO < 5 秒RPO < 5 s

注意

手動のデータベース フェールオーバーは、計画外モードを使用して、単一データベースをその geo レプリケートされたセカンダリにフェールオーバーすることを指します。Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode.

既存のサーバーにデータベースを復旧するRecover a database to the existing server

SQL Database は、データ損失からビジネスを守るために、データベースの完全バックアップ (毎週)、データベースの差分バックアップ (通常は 12 時間ごと)、およびトランザクション ログのバックアップ (5 - 10 分ごと) を組み合わせて自動的に実行します。SQL Database automatically performs a combination of full database backups weekly, differential database backups generally taken every 12 hours, and transaction log backups every 5 - 10 minutes to protect your business from data loss. バックアップは、Basic DTU サービス レベルを除くすべてのサービス レベルで 35 日間 RA-GRS ストレージに保持されます。Basic DTU サービス レベルのバックアップは 7 日間保持されます。The backups are stored in RA-GRS storage for 35 days for all service tiers except Basic DTU service tiers where the backups are stored for 7 days. 詳細については、データベースの自動バックアップに関するページをご覧ください。For more information, see automatic database backups. Azure portal、PowerShell、または REST API を使用して、既存のデータベースを同じ SQL Database サーバー上の新しいデータベースとして、自動バックアップから以前の時点に復元できます。You can restore an existing database form the automated backups to an earlier point in time as a new database on the same SQL Database server using the Azure portal, PowerShell, or the REST API. 詳細については、「ポイントインタイム リストア」をご覧ください。For more information, see Point-in-time restore.

サポートされているポイントインタイム リストア (PITR) リテンション期間がアプリケーションにとって十分でない場合は、データベースの長期リテンション期間 (LTR) ポリシーを構成することで、リテンション期間を拡張できます。If the maximum supported point-in-time restore (PITR) retention period is not sufficient for your application, you can extend it by configuring a long-term retention (LTR) policy for the database(s). 詳細については、「Long-term backup retention」(長期バックアップ リテンション) をご覧ください。For more information, see Long-term backup retention.

これらのデータベースの自動バックアップを使用して、さまざまな中断イベントから、データ センター内または別のデータ センターにデータベースを回復することができます。You can use these automatic database backups to recover a database from various disruptive events, both within your data center and to another data center. 通常は 12 時間もかかりません。The recovery time is usually less than 12 hours. 非常に大規模な、またはアクティブなデータベースの復旧には時間がかかることがあります。It may take longer to recover a very large or active database. データベースの自動バックアップでの復旧時間は、同じリージョン内で同時に復旧するデータベースの合計数、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅など、複数の要因によって異なりますが、Using automatic database backups, the estimated time of recovery depends on several factors including the total number of databases recovering in the same region at the same time, the database size, the transaction log size, and network bandwidth. 復旧時間について詳しくは、データベースの復旧時間に関するページをご覧ください。For more information about recovery time, see database recovery time. 他のデータ リージョンに復旧する場合は、geo 冗長バックアップの使用で、潜在的なデータ損失が 1 時間分の量を超えることはありません。When recovering to another data region, the potential data loss is limited to 1 hour with use of geo-redundant backups.

次のようなアプリケーションについては、ビジネス継続性と復旧メカニズムとして自動バックアップとポイントインタイム リストアを使用します。Use automated backups and point-in-time restore as your business continuity and recovery mechanism if your application:

  • ミッション クリティカルではない。Is not considered mission critical.
  • 拘束力のある SLA がない。24 時間以上のダウンタイムで財務責任が課せられることがない。Doesn't have a binding SLA - a downtime of 24 hours or longer does not result in financial liability.
  • データ変更率 (1 時間あたりのトランザクション数など) が低く、最大 1 時間分の変更に対するデータ損失を許容できる。Has a low rate of data change (low transactions per hour) and losing up to an hour of change is an acceptable data loss.
  • コスト重視である。Is cost sensitive.

迅速に復旧する必要がある場合は、アクティブ geo レプリケーションまたは自動フェールオーバー グループを使用してください。If you need faster recovery, use active geo-replication or auto-failover groups. 35 日より前の期間のデータを回復する能力が必要な場合は、長期リテンション期間を使用します。If you need to be able to recover data from a period older than 35 days, use Long-term retention.

別のリージョンにデータベースを復旧するRecover a database to another region

まれではありますが、Azure データ センターが停止することもあります。Although rare, an Azure data center can have an outage. 停止が発生すると、ビジネスが中断します。この中断はわずか数分で解消されることもありますが、数時間に及ぶ場合もあります。When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • オプションの 1 つは、データ センターの停止が終了し、データベースがオンラインに戻るのを待つことです。One option is to wait for your database to come back online when the data center outage is over. このオプションは、オフラインのデータベースが許容されるアプリケーションで有効です。This works for applications that can afford to have the database offline. たとえば、常時作業する必要のない開発プロジェクトや無料試用版がこれに該当します。For example, a development project or free trial you don't need to work on constantly. また、データ センターが停止したときに、復旧までの時間を予測できないため、当面はデータベースが必要ない場合にのみ使用できます。When a data center has an outage, you do not know how long the outage might last, so this option only works if you don't need your database for a while.
  • もう 1 つのオプションは、geo 冗長データベース バックアップ (geo リストア) を使用して、任意の Azure リージョン内の任意のサーバーにデータベースを復元する方法です。Another option is to restore a database on any server in any Azure region using geo-redundant database backups (geo-restore). geo リストアではソースとして geo 冗長バックアップが使用され、障害によってデータベースまたはデータセンターにアクセスできない場合でも、geo リストアを使用してデータベースを復旧できます。Geo-restore uses a geo-redundant backup as its source and can be used to recover a database even if the database or datacenter is inaccessible due to an outage.
  • 最後に、アクティブ geo レプリケーションを使用した geo セカンダリか、または 1 つまたは複数のデータベースの自動フェールオーバー グループのどちらかを構成している場合は、障害からすばやく復旧できます。Finally, you can quickly recover from an outage if you have configured either geo-secondary using active geo-replication or an auto-failover group for your database or databases. 選択するテクノロジに応じて、手動または自動フェールオーバーを使用できます。Depending on your choice of these technologies, you can use either manual or automatic failover. フェールオーバーそのものにかかる時間はほんの数秒ですが、サービスをアクティブにするために少なくとも 1 時間はかかります。While failover itself takes only a few seconds, the service will take at least 1 hour to activate it. これは、機能停止の規模に見合ったフェールオーバーを確実に行ううえで必要な時間です。This is necessary to ensure that the failover is justified by the scale of the outage. また、非同期レプリケーションの特性上、フェールオーバーによって少量のデータが失われることがあります。Also, the failover may result in small data loss due to the nature of asynchronous replication. 自動フェールオーバーの RTO と RPO について詳しくは、この記事の前出の表を参照してください。See the table earlier in this article for details of the auto-failover RTO and RPO.

重要

アクティブ geo レプリケーションと自動フェールオーバー グループを使用するには、サブスクリプション所有者であるか、SQL Server の管理アクセス許可を持っている必要があります。To use active geo-replication and auto-failover groups, you must either be the subscription owner or have administrative permissions in SQL Server. Azure ポータル、PowerShell、または REST API で構成およびフェールオーバーを行う場合は、Azure サブスクリプションのアクセス許可を使用できます。Transact-SQL で行う場合は、SQL Server のアクセス許可を使用できます。You can configure and fail over using the Azure portal, PowerShell, or the REST API using Azure subscription permissions or using Transact-SQL with SQL Server permissions.

自動フェールオーバー グループは、アプリケーションが次のいずれかの条件を満たす場合に使用します。Use auto-failover groups if your application meets any of these criteria:

  • ミッション クリティカルである。Is mission critical.
  • サービス レベル アグリーメント (SLA) で 12 時間以上のダウンタイムが許可されていない。Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • ダウンタイムによって財務責任が発生する。Downtime may result in financial liability.
  • データの変更頻度が高く、1 時間分のデータが失われることも許されない。Has a high rate of data change and 1 hour of data loss is not acceptable.
  • アクティブ geo レプリケーションの追加コストが、潜在的な財務責任と関連するビジネス損失を下回る。The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

アクションを実行するタイミング、復旧にかかる時間、および発生するデータ損失の量は、ビジネス継続性機能をアプリケーションでどのように使用するかによって異なります。When you take action, how long it takes you to recover, and how much data loss you incur depends upon how you decide to use these business continuity features in your application. 実際は、アプリケーションの要件に応じて、データベース バックアップとアクティブ geo レプリケーションを組み合わせて使用できます。Indeed, you may choose to use a combination of database backups and active geo-replication depending upon your application requirements. ビジネス継続性機能を使用したスタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計に関するページと Elastic Pool のディザスター リカバリー戦略に関するページをご覧ください。For a discussion of application design considerations for stand-alone databases and for elastic pools using these business continuity features, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.

以下のセクションでは、データベース バックアップまたは アクティブ geo レプリケーションのいずれかを使用して復旧する手順の概要について説明します。The following sections provide an overview of the steps to recover using either database backups or active geo-replication. 要件の計画、復旧後の手順、障害をシミュレートしてディザスター リカバリー訓練を実施する方法など、詳細な手順については、障害からの SQL Database 復旧に関するページをご覧ください。For detailed steps including planning requirements, post recovery steps, and information about how to simulate an outage to perform a disaster recovery drill, see Recover a SQL Database from an outage.

障害に備えるPrepare for an outage

使用するビジネス継続性機能に関係なく、次の操作を行う必要があります。Regardless of the business continuity feature you use, you must:

  • サーバー レベルの IP ファイアウォール規則、ログイン、マスター データベース レベルのアクセス許可など、ターゲット サーバーを特定して準備します。Identify and prepare the target server, including server-level IP firewall rules, logins, and master database level permissions.
  • クライアントとクライアント アプリケーションを、新しいサーバーにリダイレクトする方法を決めますDetermine how to redirect clients and client applications to the new server
  • 監査の設定、アラートなど、他の依存関係を文書化しますDocument other dependencies, such as auditing settings and alerts

準備が不十分な状態で、フェールオーバーまたはデータベースの復旧後にアプリケーションをオンラインにすると、余計な時間がかかり、負荷がかかったときにトラブルシューティングが必要になる場合があります。良くない組み合わせです。If you do not prepare properly, bringing your applications online after a failover or a database recovery takes additional time and likely also require troubleshooting at a time of stress - a bad combination.

geo レプリケートされたセカンダリ データベースにフェールオーバーするFail over to a geo-replicated secondary database

復旧メカニズムとしてアクティブ geo レプリケーションまたは自動フェールオーバー グループを使用している場合は、自動フェールオーバー ポリシーを構成するか、または手動の計画外フェールオーバーを使用できます。If you are using active geo-replication or auto-failover groups as your recovery mechanism, you can configure an automatic failover policy or use manual unplanned failover. いったん開始すると、フェールオーバーによってセカンダリは新しいプライマリになり、新しいトランザクションを記録してクエリに応答できるようになります。失われるのは、レプリケートされなかった最小限のデータだけです。Once initiated, the failover causes the secondary to become the new primary and ready to record new transactions and respond to queries - with minimal data loss for the data not yet replicated. フェールオーバー プロセスの設計については、クラウド障害復旧用のアプリケーション設計に関するページをご覧ください。For information on designing the failover process, see Design an application for cloud disaster recovery.

注意

データ センターがオンラインに戻ると、古いプライマリは自動的に新しいプライマリに再接続し、セカンダリ データベースになります。When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. プライマリを元のリージョンに再配置する場合は、計画されたフェールオーバーを手動で開始することができます (フェールバック)。If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

geo リストアを実行するPerform a geo-restore

geo 冗長ストレージ (既定で有効) で自動バックアップを使用している場合、データベースは geo リストアを使用して復旧できます。If you are using the automated backups with geo-redundant storage (enabled by default), you can recover the database using geo-restore. 通常、復旧は 12 時間以内に実行され、最大 1 時間分のデータ損失が発生します。これは、最後のログ バックアップが実行およびレプリケートされたタイミングによって決まります。Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last log backup was taken and replicated. 復旧処理が完了するまで、データベースは、トランザクションを記録したり、クエリに応答したりすることはできません。Until the recovery completes, the database is unable to record any transactions or respond to any queries. なお、geo リストアでは最後の使用可能な一時点までしかデータベースを復元できません。Note, geo-restore only restores the database to the last available point in time.

注意

復旧されたデータベースにアプリケーションを切り替える前に、データ センターがオンラインに戻った場合は、復旧をキャンセルすることができます。If the data center comes back online before you switch your application over to the recovered database, you can cancel the recovery.

フェールオーバー後のタスク/復旧タスクを実行するPerform post failover / recovery tasks

復旧にどちらのメカニズムを使ったとしても、ユーザーおよびアプリケーションの動作を元に戻す前に、次の追加タスクを実行する必要があります。After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • クライアントとクライアント アプリケーションを、新しいサーバーおよび復元されたサーバーにリダイレクトするRedirect clients and client applications to the new server and restored database
  • ユーザーが接続できるように、適切なサーバー レベルの IP ファイアウォール規則が適用されていることを確認する。または、データベース レベルのファイアウォールを使用して、適切な規則を有効にする。Ensure appropriate server-level IP firewall rules are in place for users to connect or use database-level firewalls to enable appropriate rules.
  • 適切なログインとマスター データベース レベルのアクセス許可が適切に指定されていることを確認する (または 包含ユーザーを使用する)Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • 必要に応じて、監査を構成するConfigure auditing, as appropriate
  • 必要に応じて、アラートを構成するConfigure alerts, as appropriate

注意

フェールオーバー グループを使用している場合で、かつ読み取り/書き込みリスナーを使用してデータベースに接続している場合、フェールオーバー後のリダイレクトは、自動的かつアプリケーションに対して透過的に実行されます。If you are using a failover group and connect to the databases using the read-write lstener, the redirection after failover will happen automatically and transparently to the application.

最小のダウンタイムでアプリケーションをアップグレードするUpgrade an application with minimal downtime

アプリケーションのアップグレードなど、計画されたメンテナンスのために、アプリケーションをオフラインにしなければならないことがあります。Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. アプリケーション アップグレードの管理 に関するページでは、アクティブ geo レプリケーションを使用してクラウド アプリケーションのローリング アップグレードを有効化し、アップグレード中のダウンタイムを最小限に抑え、問題が発生した場合の復旧パスを提供する方法について説明します。Manage application upgrades describes how to use active geo-replication to enable rolling upgrades of your cloud application to minimize downtime during upgrades and provide a recovery path if something goes wrong.

次の手順Next steps

スタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計に関するページと Elastic Pool のディザスター リカバリー戦略に関するページをご覧ください。For a discussion of application design considerations for stand-alone databases and for elastic pools, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.