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

この概要では、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

SQL Database には、自動バックアップ、オプションのデータベース レプリケーションなど、ビジネス継続性の機能がいくつか用意されており、SQL Database provides several business continuity features, including automated backups and optional database replication. 推定復旧時間 (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. ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解する必要があります。これが目標復旧時間 (RTO) です。As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event - this is your recovery time objective (RTO). さらに、破壊的なイベントの発生後、復旧中にアプリケーションが損失を許容できる最大データ更新 (期間) 量についても理解しなければなりません。これは目標復旧時点 (RPO) です。You also need to understand the maximum amount of recent data updates (time interval) the application can tolerate losing when recovering after the disruptive event - this is your recovery point objective (RPO).

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

機能Capability BasicBasic 標準Standard PremiumPremium 汎用General Purpose Business CriticalBusiness Critical
バックアップからのポイントインタイム リストアPoint in Time Restore from backup 7 日間以内のあらゆる復元ポイントAny restore point within 7 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 時間、RPO < 1 時間ERT < 12h, RPO < 1h ERT < 12 時間、RPO < 1 時間ERT < 12h, RPO < 1h ERT < 12 時間、RPO < 1 時間ERT < 12h, RPO < 1h ERT < 12 時間、RPO < 1 時間ERT < 12h, RPO < 1h ERT < 12 時間、RPO < 1 時間ERT < 12h, RPO < 1h
Azure Backup コンテナーからの復元Restore from Azure Backup Vault ERT < 12 時間、RPO < 1 週間ERT < 12h, RPO < 1 wk ERT < 12 時間、RPO < 1 週間ERT < 12h, RPO < 1 wk ERT < 12 時間、RPO < 1 週間ERT < 12h, RPO < 1 wk ERT < 12 時間、RPO < 1 週間ERT < 12h, RPO < 1 wk ERT < 12 時間、RPO < 1 週間ERT < 12h, RPO < 1 wk
アクティブ geo レプリケーションActive geo-replication ERT < 30 秒、RPO < 5 秒ERT < 30s, RPO < 5s ERT < 30 秒、RPO < 5 秒ERT < 30s, RPO < 5s ERT < 30 秒、RPO < 5 秒ERT < 30s, RPO < 5s ERT < 30 秒、RPO < 5 秒ERT < 30s, RPO < 5s ERT < 30 秒、RPO < 5 秒ERT < 30s, RPO < 5s

ポイントインタイム リストアを使用して、データベースを復旧しますUse point-in-time restore to recover a database

SQL Database は、データ損失からビジネスを守るために、データベースの完全バックアップ (毎週)、データベースの差分バックアップ (1 時間ごと)、およびトランザクション ログのバックアップ (5 ~ 10 分ごと) を組み合わせて自動的に実行します。SQL Database automatically performs a combination of full database backups weekly, differential database backups hourly, and transaction log backups every five - ten minutes to protect your business from data loss. これらのバックアップは、Standard および Premium サービス レベルの場合は 35 日間、Basic サービス レベルでは 7 日間、RA-GRS ストレージに格納されます。These backups are stored in RA-GRS storage for 35 days for databases in the Standard and Premium service tiers and 7 days for databases in the Basic service tier. General Purpose および Business Critical サービス レベル (プレビュー) では、バックアップ リテンション期間は最大 35 日に設定できます。In the General purpose and Business critical service tiers (preview), the backups retention is configurable up to 35 days. 詳細については、サービス レベルに関する記事をご覧ください。For more information, see service tiers. サービス階層のリテンション期間がビジネス要件を満たしていない場合、リテンション期間を長くするには、サービス階層を変更します。If the retention period for your service tier does not meet your business requirements, you can increase the retention period by changing the service tier. データベースの完全バックアップと差分バックアップは、データ センターの停止に対する保護のためにペアのデータ センターにもレプリケートされます。The full and differential database backups are also replicated to a paired data center for protection against a data center outage. 詳細については、データベースの自動バックアップに関するページをご覧ください。For more information, see automatic database backups.

サポートされている PITR リテンション期間がアプリケーションにとって十分でない場合は、データベースの長期リテンション期間 (LTR) ポリシーを構成することで、リテンション期間を拡張できます。If the maximum supported 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). 詳細については、「長期保存」をご覧ください。For more information, see Long-term 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. データベースの自動バックアップでの復旧時間は、同じリージョン内で同時に復旧するデータベースの合計数、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅など、複数の要因によって異なりますが、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. 通常は 12 時間もかかりません。The recovery time is usually less than 12 hours. 他のデータ リージョンに復旧する場合は、geo 冗長ストレージで 1 時間ごとにデータベースの差分バックアップが実行されるため、潜在的なデータ損失が 1 時間分の量を超えることはありません。When recovering to another data region, the potential data loss is limited to 1 hour by the geo-redundant storage of hourly differential database backups.


自動バックアップを使って復旧するには、SQL Server の共同作業者ロールのメンバーまたはサブスクリプション所有者である必要があります。「RBAC: 組み込みのロール」をご覧ください。To recover using automated backups, you must be a member of the SQL Server Contributor role or the subscription owner - see RBAC: Built-in roles. 復旧には、Azure ポータル、PowerShell、または REST API を使用できます。You can recover using the Azure portal, PowerShell, or the REST API. Transact-SQL は使用できません。You cannot use Transact-SQL.

次のようなアプリケーションについては、ビジネス継続性と復旧メカニズムとして自動バックアップを使用します。Use automated backups 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 (discussed next). 35 日より前の期間のデータを回復する能力が必要な場合は、長期リテンション期間を使用します。If you need to be able to recover data from a period older than 35 days, use Long-term retention.

アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) を使用して、復旧時間を短縮し、復旧に伴うデータ損失を抑えるUse active geo-replication and auto-failover groups (in-preview) to reduce recovery time and limit data loss associated with a recovery

ビジネス中断が発生した場合、データベース バックアップを使用してデータベースを復旧するほか、アクティブ geo レプリケーションを使用して、最大 4 つの読み取り可能なセカンダリ データベースが任意のリージョンに作成されるように、データベースを構成することもできます。In addition to using database backups for database recovery if a business disruption occurs, you can use active geo-replication to configure a database to have up to four readable secondary databases in the regions of your choice. このセカンダリ データベースは、非同期レプリケーション メカニズムを使用して、プライマリ データベースと同期し続けます。These secondary databases are kept synchronized with the primary database using an asynchronous replication mechanism. この機能は、データ センター停止が発生した場合、またはアプリケーションのアップグレード中のビジネス中断を防ぐために使用されます。This feature is used to protect against business disruption if a data center outage occurs or during an application upgrade. また、アクティブ geo レプリケーションを使用して、地理的に分散したユーザーの読み取り専用クエリのパフォーマンスを高めることもできます。Active geo-replication can also be used to provide better query performance for read-only queries to geographically dispersed users.

自動的かつ透過的なフェールオーバーを有効にするには、SQL Database の自動フェールオーバー グループ機能 (プレビュー段階) を使用して、geo レプリケートされたデータベースをグループにまとめる必要があります。To enable automated and transparent failover you should organize your geo-replicated databases into groups using the auto-failover group feature of SQL Database (in-preview).

プライマリ データベースが予期せずオフラインになった場合、またはメンテナンスのためにプライマリ データベースをオフラインにする必要がある場合は、セカンダリ データベースをすばやくプライマリに昇格し ("フェールオーバー" とも呼ばれます)、プライマリに昇格したデータベースに接続されるようにアプリケーションを構成できます。If the primary database goes offline unexpectedly or you need to take it offline for maintenance activities, you can quickly promote a secondary to become the primary (also called a failover) and configure applications to connect to the promoted primary. アプリケーションがフェールオーバー グループ リスナーを使用してデータベースに接続している場合は、SQL 接続文字列構成をフェールオーバーの後で変更する必要がありません。If your application is connecting to the databases using the failover group listener, you don’t need to change the SQL connection string configuration after failover. 計画フェールオーバーの場合、データ損失は発生しません。With a planned failover, there is no data loss. 計画外フェールオーバーについては、非同期レプリケーションの性質上、最近のトランザクションのデータが多少失われます。With an unplanned failover, there may be some small amount of data loss for very recent transactions due to the nature of asynchronous replication. 自動フェールオーバー グループ (プレビュー段階) を使用すると、フェールオーバー ポリシーをカスタマイズしてデータ損失の可能性を最小限に抑えることができます。Using auto-failover groups (in-preview), you can customize the failover policy to minimize the potential data loss. フェールオーバー後は、後でフェールバックできます。このフェールバックは、計画に従って、またはデータ センターがオンラインに戻ったときに行います。After a failover, you can later failback - either according to a plan or when the data center comes back online. いずれにしても、ユーザーのダウンタイムはわずかで、再接続が必要です。In all cases, users experience a small amount of downtime and need to reconnect.


アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) を使用するには、サブスクリプション所有者であるか、SQL Server の管理アクセス許可を持っている必要があります。To use active geo-replication and auto-failover groups (in-preview), 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.

アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) は、アプリケーションが次のいずれかの条件を満たす場合に使用します。Use active geo-replication and auto-failover groups (in preview) if your application meets any of these criteria:

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

ユーザーまたはアプリケーション エラーの発生後にデータベースを復旧するRecover a database after a user or application error

ミスをしない人など存在しません。No one is perfect! 一部のデータ、重要なテーブル、そしてデータベース全体さえも、うっかり削除してしまう場合があります。A user might accidentally delete some data, inadvertently drop an important table, or even drop an entire database. アプリケーションの欠陥で、正しいデータが不良データによって誤って上書きされることもあります。Or, an application might accidentally overwrite good data with bad data due to an application defect.

ここでは、このような場合の復旧オプションを紹介します。In this scenario, these are your recovery options.

ポイントインタイム リストアを実行するPerform a point-in-time restore

自動バックアップを使用すると、データベースのコピーを、データベース リテンション期間内の既知の適切な時点まで遡って復旧できます。You can use the automated backups to recover a copy of your database to a known good point in time, provided that time is within the database retention period. データベースを復元したら、元のデータベースを復元したデータベースに置き換えるか、復元したデータから必要なデータを元のデータベースにコピーできます。After the database is restored, you can either replace the original database with the restored database or copy the needed data from the restored data into the original database. データベースでアクティブ geo レプリケーションが使用されている場合は、復元されたコピーから元のデータベースに必要なデータをコピーすることをお勧めします。If the database uses active geo-replication, we recommend copying the required data from the restored copy into the original database. 元のデータベースを復元したデータベースに置き換える場合は、アクティブ geo レプリケーションを再構成して再同期する必要があります (大きなデータベースの場合はかなり時間がかかることがあります)。If you replace the original database with the restored database, you need to reconfigure and resynchronize active geo-replication (which can take quite some time for a large database). これにより、データベースは利用可能な最新のポイント イン タイムまでリストアされますが、geo セカンダリの任意のポイント イン タイムへのリストアは現在サポートされていません。While this restores a database to the last available point in time, restoring the geo-secondary to any point in time is not currently supported.

詳細情報、および Azure ポータルまたは PowerShell を使用してデータベースを特定の時点に復元する詳細な手順については、「 ポイントインタイム リストア」をご覧ください。For more information and for detailed steps for restoring a database to a point in time using the Azure portal or using PowerShell, see point-in-time restore. Transact-SQL を使用して回復することはできません。You cannot recover using Transact-SQL.

削除されたデータベースの復元Restore a deleted database

データベースだけが削除され、論理サーバーが削除されていない場合は、削除されたデータベースを、そのデータベースが削除された時点に戻すことができます。If the database is deleted but the logical server has not been deleted, you can restore the deleted database to the point at which it was deleted. この場合、データベースが削除された論理 SQL サーバーに、データベース バックアップが復元されます。This restores a database backup to the same logical SQL server from which it was deleted. このデータベースの復元は元の名前を使用して実行することも、復元したデータベースに新しいに名前を付けることもできます。You can restore it using the original name or provide a new name or the restored database.

詳細情報、および削除されたデータベースを Azure ポータルまたは PowerShell を使用して復元する詳細な手順については、 削除されたデータベースの復元に関するページをご覧ください。For more information and for detailed steps for restoring a deleted database using the Azure portal or using PowerShell, see restore a deleted database. Transact-SQL を使用して復元することはできません。You cannot restore using Transact-SQL.


論理サーバーが削除された場合、削除されたデータベースは回復できません。If the logical server is deleted, you cannot recover a deleted database.

長期リテンション期間からのバックアップの復元Restore backups from long-term retention

自動化されたバックアップの現在のリテンション期間外にデータの損失が発生したとき、お使いのデータベースが長期リテンション期間用に構成されている場合は、LTR ストレージの完全バックアップから、新しいデータベースにデータを復元できます。If the data loss occurred outside the current retention period for automated backups and your database is configured for long-term retention, you can restore from a full backup in the LTR storage to a new database. この時点で、元のデータベースを復元したデータベースに置き換えるか、復元したデータベースから必要なデータを元のデータベースにコピーできます。At this point, you can either replace the original database with the restored database or copy the needed data from the restored database into the original database. アプリケーションのメジャー アップグレードの前の古いバージョンのデータベースを取得し、監査担当者からの要求または法律上の要請に対応する必要がある場合は、Azure Backup コンテナーに保存されている完全バックアップを使用してデータベースを作成することができます。If you need to retrieve an old version of your database prior to a major application upgrade, satisfy a request from auditors or a legal order, you can create a database using a full backup saved in the Azure Backup Vault. 詳細については、「長期保存」をご覧ください。For more information, see Long-term retention.

Azure リージョン データ センターが停止した場合にデータベースを別のリージョンで回復するRecover a database to another region from an Azure regional data center outage

まれではありますが、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 冗長データベース バックアップ (geo リストア) を使用してデータベースを復旧するオプションです。Another option is to either fail over to another data region if you are using active geo-replication or the recover a database using geo-redundant database backups (geo-restore). フェールオーバーの所要時間はわずか数秒ですが、バックアップからデータベースが復旧する場合は数時間かかります。Failover takes only a few seconds while database recovery from backups takes hours.

アクションを実行するタイミング、復旧にかかる時間、および発生するデータ損失の量は、ビジネス継続性機能をアプリケーションでどのように使用するかによって異なります。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. ビジネス継続性機能を使用したスタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計) に関するページとエラスティック プールのディザスター リカバリー戦略に関するページをご覧ください。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:

  • サーバー レベルのファイアウォール規則、ログイン、マスター データベース レベルのアクセス許可など、ターゲット サーバーを特定して準備します。Identify and prepare the target server, including server-level 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 and auto-failover groups (in-preview) as your recovery mechanism, you can configure an automatic failover policy or use manual 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 automated backups with geo-redundant storage replication as your recovery mechanism, initiate a database recovery using geo-restore. ほとんどの場合、12 時間以内に復旧が実行され、最大 1 時間分のデータ損失が発生します。これは 1 時間ごとの差分バックアップによって、最後のバックアップが実行およびレプリケートされたタイミングによって決まります。Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last hourly differential backup with taken and replicated. 復旧処理が完了するまで、データベースは、トランザクションを記録したり、クエリに応答したりすることはできません。Until the recovery completes, the database is unable to record any transactions or respond to any queries. これにより、データベースは利用可能な最新のポイント イン タイムまでリストアされますが、geo セカンダリの任意のポイント イン タイムへのリストアは現在サポートされていません。While this restores a database to the last available point in time, restoring the geo-secondary to any point in time is not currently supported.


復旧されたデータベースにアプリケーションを切り替える前に、データ センターがオンラインに戻った場合は、復旧をキャンセルすることができます。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
  • ユーザーが接続できるように、適切なサーバー レベルのファイアウォール規則が適用されていることを確認する (または データベース レベルのファイアウォールを使用する)Ensure appropriate server-level firewall rules are in place for users to connect (or use database-level firewalls)
  • 適切なログインとマスター データベース レベルのアクセス許可が適切に指定されていることを確認する (または 包含ユーザーを使用する)Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • 必要に応じて、監査を構成するConfigure auditing, as appropriate
  • 必要に応じて、アラートを構成するConfigure alerts, as appropriate

最小のダウンタイムでアプリケーションをアップグレードする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

スタンドアロン データベースおよびエラスティック プール用アプリケーション設計に関する考慮事項については、クラウド ディザスター リカバリー用のアプリケーション設計に関するページとエラスティック プール ディザスター リカバリー戦略に関するページをご覧ください。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.