Azure SQL Database のバックアップからデータベースを復元する

適用対象:Azure SQL Database

この記事では、Hyperscale データベースを含む、Azure SQL Database のバックアップから任意のデータベースを復元する手順について説明します。 Azure SQL Managed Instance については、「Azure SQL Managed Instance のバックアップからデータベースを復元する」を参照してください。

自動バックアップは、ユーザーやアプリケーションのエラー、偶発的なデータベースの削除、および長期間にわたる障害からデータベースを保護するのに役立ちます。 この組み込みの機能は、すべてのサービス レベルとコンピューティング サイズで使用できます。 自動バックアップを使用したデータベースの復旧には、次のオプションを使用できます。

• 同じサーバー上に、保有期間内の特定の時点に復旧された新しいデータベースを作成する。
• 同じサーバー上に、削除済みデータベースの削除時に復旧されたデータベースを作成する。
• 同じリージョンのサーバー上に、最新のバックアップの時点に復旧された新しいデータベースを作成する。
• 任意の他のリージョンのサーバー上に、最後にレプリケートされたバックアップの時点に復旧された新しいデータベースを作成する。

長期保有 (LTR) を構成している場合、任意の長期保有バックアップから任意のサーバー上に新しいデータベースを作成することもできます。

DTU 購入モデルの Standard または Premium のサービス レベルを使用している場合、データベースの復元によって追加のストレージ コストが発生する可能性があります。 復元されたデータベースの最大サイズが、ターゲット データベースのサービス レベルとサービス目標に含まれるストレージの量を超えると、追加のコストが発生します。

追加ストレージの価格について詳しくは、「SQL Database の価格」をご覧ください。 実際に使用される容量が、含まれるストレージの量より少ない場合、データベースの最大サイズを含まれる量に設定することで、この追加コストを回避できます。

復旧時間

自動データベース バックアップを使用してデータベースを復元する復旧時間には、さまざまな要因が影響します。

• データベースのサイズ
• データベースのコンピューティング サイズ
• 関連するトランザクション ログ数
• 復元時点に復旧するために再生の必要があるアクティビティ量
• 別のリージョンへの復元の場合は、ネットワーク帯域幅
• ターゲット リージョンで処理される、同時実行される復元要求の数

大規模なデータベースや、非常に活動の激しいデータベースの場合、復元に数時間かかることがあります。 リージョン内で長時間にわたる障害が発生した場合は、ディザスター リカバリーのために、多数の geo リストア要求が発生する可能性があります。 多数の要求がある場合、個々のデータベースでの復旧時間が長くなる可能性があります。 ほとんどのデータベースの復元は、12 時間未満で完了します。

単一サブスクリプションには、同時リストア要求の数に次の制限があります。 これらの制限は、ポイントインタイム リストア、geo リストア、および長期保有バックアップからの復元の任意の組み合わせに適用されます。

アクセス許可

自動バックアップを使用して復旧するには、次のいずれかである必要があります。

• 論理サーバーを含むサブスクリプションまたはリソース グループの共同作成者ロールまたは SQL Server 共同作成者ロールのメンバー
• サブスクリプションまたはリソース グループ所有者

詳細については、Azure RBAC: 組み込みのロールに関するページをご覧ください。

復旧には、Azure portal、PowerShell、または REST API を使用できます。 Transact-SQL は使用できません。

ポイントインタイム リストア

任意のデータベースを、その保持期間内の以前の時点に復元することができます。 復元要求では、復元されるデータベースに対して任意のサービス レベルまたはコンピューティング サイズを指定できます。 データベースをエラスティック プールに復元する場合、データベースに対応する十分なリソースがプールにあることを確認します。

復元が完了すると、元のデータベースと同じサーバー上に新しいデータベースが作成されます。 復元されたデータベースでは、サービス レベルとコンピューティング サイズに基づいて通常料金が発生します。 データベースの復元が完了するまでは、料金は発生しません。

通常、以前の時点へのデータベースの復元は、復旧の目的で行います。 復元されたデータベースは、元のデータベースの代わりとして扱うことも、元のデータベースを更新するためのデータ ソースとして使用することもできます。

• データベースの置換

  復元されたデータベースを元のデータベースの代わりとして使用する場合は、元のデータベースのコンピューティング サイズとサービス レベルを指定する必要があります。 次に、T-SQL の ALTER DATABASE コマンドを使用して、元のデータベース名を変更し、復元されたデータベースに元の名前を付けます。

• データの復旧

  ユーザーまたはアプリケーションのエラーから復旧するために、復元されたデータベースからデータを取得する場合は、復元されたデータベースからデータを抽出して元のデータベースに適用するデータ復旧スクリプトを作成して実行する必要があります。 復元操作が完了するまでに時間がかかる可能性がありますが、復元プロセスを通して、復元しているデータベースがデータベース一覧に表示されます。

  復元中にデータベースを削除すると、復元操作が取り消されます。 復元が完了しなかったデータベースに対しては課金されません。

長期バックアップの復元

長期バックアップに対して復元操作を実行するには、Azure portal、Azure CLI、Azure PowerShell、または REST API を使用できます。 詳細については、長期バックアップの復元に関する記事を参照してください。

削除されたデータベースの復元

削除されたデータベースは、Azure portal、Azure CLI、Azure PowerShell、REST API を使って、同じサーバー上で削除時刻またはそれ以前の時点に復元することができます。

geo リストア

Azure portal、Azure CLI、Azure PowerShell、REST API を使い、geo リストアを使って削除されたデータベースを復元できます。

geo リストアには、geo レプリケートされたバックアップがソースとして使われます。 geo レプリケートされた最新のバックアップから任意の Azure リージョン内の任意の論理サーバーでデータベースを復元することができます。 障害によってデータベースまたは全体のリージョンデータセンターにアクセスできない場合でも、geo リストアを要求できます。

geo リストアは、ホスティング リージョンでのインシデントが原因でデータベースが利用できない場合の既定の復旧オプションです。 データベースは他の任意のリージョンのサーバーに復元できます。

バックアップが取得される時刻と、別のリージョンの Azure BLOB にその差分バックアップが geo レプリケートされる時刻には時間差があります。 その結果、復元されたデータベースは、元のデータベースより最大 1 時間遅れることがあります。 次の図では、別のリージョン内の利用可能な最新のバックアップからのデータベースの復元を示します。

geo リストアに関する考慮事項

geo リストアの使用の詳細については、geo リストアを使用した復旧に関するページを参照してください。

geo リストアは、SQL Database で使用できる最も基本的なディザスター リカバリー ソリューションです。 これは、自動的に作成される geo レプリケートされたバックアップに依存し、目標復旧時点 (RPO) は最大 1 時間、推定復旧時間 (RTO) は最大 12 時間です。 リージョンの停止後は、需要が急激に増加する可能性があるため、目的のデータベースを復元する容量がターゲット リージョンに確保される保証はありません。 アプリケーションで使用されているデータベースが比較的小さく、アプリケーションがビジネスにとって重要でなければ、geo リストアは適切なディザスター リカバリー ソリューションです。

大規模なデータベースを必要とし、ビジネス継続性を保証する必要があるビジネス上不可欠なアプリケーションの場合は、フェールオーバー グループを使用します。 その機能により、大幅に低い RPO と RTO が実現され、容量が常に保証されます。

事業継続に関する選択肢の詳細については、ビジネス継続性の概要に関するページを参照してください。

次の手順

• SQL Database 自動バックアップ
• 長期保存
• より迅速な復旧オプションについては、アクティブ geo レプリケーションまたはフェールオーバー グループに関する記事を参照してください。