次の方法で共有

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

  • [アーティクル]

適用対象: Azure SQL Managed Instance

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

概要

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

  • 同じマネージド インスタンス上に、保持期間内の特定の時点に復旧された新しいデータベースを作成する。
  • 同じマネージド インスタンスまたは異なるマネージド インスタンス上に、保有期間内の特定の時点に復旧された新しいデータベースを作成する。
  • 同じマネージド インスタンスまたは異なるマネージド インスタンス上に、削除されたデータベースの削除時に復旧されたデータベースを作成する。
  • 同じテナントおよび同じリージョン内の同じサブスクリプションまたは異なるサブスクリプション内の任意のマネージド インスタンス上に、最新のバックアップの時点に復旧された新しいデータベースを作成する。

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

重要

復元中に既存のデータベースを上書きすることはできません。

復旧時間

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

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

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

ヒント

Azure SQL Managed Instance では、システムの更新プログラムの方が進行中のデータベースの復元より優先されます。 SQL Managed Instance にシステムの更新プログラムがある場合は、保留中のすべての復元が中断され、更新プログラムが適用された後に再開されます。 このシステムの動作により、復元時間が長くなる場合があり、特に実行時間の長い復元に影響を与える可能性があります。

データベースの復元の予測可能な時間を実現するには、特定の日時にシステムの更新プログラムのスケジュールを設定できるメンテナンス期間を構成することを検討してください。 また、スケジュールされたメンテナンス期間外にデータベースの復元を実行することも検討してください。

アクセス許可

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

  • サブスクリプション内の SQL Server 共同作成者ロールまたは SQL Managed Instance 共同作成者ロール (復旧のターゲットによって決まります) のメンバー
  • サブスクリプションの所有者

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

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

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

データベースを前の時点に復元することができます。 要求では、復元されるデータベースに対して任意のサービス レベルまたはコンピューティング サイズを指定できます。 データベースを復元するインスタンスに十分なリソースを確保します。

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

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

重要

geo セカンダリ データベースでは、ポイントインタイム リストアを実行できません。 これを実行できるのは、プライマリ データベースだけです。

  • データベースの置換

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

  • データの復旧

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

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

Azure portal を使って SQL Managed Instance のデータベースを特定の時点に復旧するには、ポータルでデータベースに移動し、[復元] を選びます。 または、ターゲット SQL Managed Instance の概要ページを開き、ツール バーの [+ 新しいデータベース] を選んで、[Azure SQL マネージド データベースを作成する] ページを開きます。

新しいデータベースの追加が選ばれている、Azure portal の SQL Managed Instance の [概要] ペインを示すスクリーンショット。

[基本] タブでターゲット マネージド インスタンスの詳細を指定し、[データ ソース] タブでバックアップの種類を選びます。

[Azure SQL マネージド データベースを作成する] ページの [データ ソース] タブを示す Azure portal のスクリーンショット。[特定の時点に復旧] が選ばれています。

詳しくは、ポイントインタイム リストアに関する記事をご覧ください。

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

削除されたデータベースを、削除時点、またはそれ以前の時点の状態で、同じインスタンス、またはソース インスタンスとは異なるインスタンスに復元できます。 ターゲット インスタンスは、同じサブスクリプション内、またはソース インスタンスとは異なるサブスクリプション内に存在できます。 削除されたデータベースを復元するには、バックアップから新しいデータベースを作成します。

重要

削除されたマネージド インスタンスは復元できません。 マネージド インスタンスを削除すると、そのすべてのデータベースも削除され、削除時刻または以前の時点に復元することはできません。 長期保有 (LTR) を構成した場合でも、削除されたインスタンスから別のインスタンスにデータベースを復元し、LTR バックアップが作成された時点を指定できます。

Azure portal を使用してデータベースを復旧するには、マネージド インスタンスの [概要] ページを開き、[バックアップ] を選択します。 [削除済み] バックアップを表示することを選んでから、回復する削除済みバックアップの横にある [復元] を選択して、[Azure SQL マネージド データベースを作成する] ページを開きます。 [基本] タブでターゲット マネージド インスタンスの詳細を指定し、[データ ソース] タブでソース マネージド インスタンスの詳細を指定します。[追加の設定] タブでは保有設定を構成します。

Azure portal の SQL Managed Instance の [バックアップ] ページのスクリーンショット。削除済みデータベースが示され、[復元] アクションが選択されています。

ヒント

最近削除されたデータベースを Azure portal の [削除されたデータベース] ページに表示するか、コマンド ラインを使用して削除されたデータベースを表示するには、数分かかる場合があります。

geo リストア

重要

  • geo リストアは、geo 冗長バックアップ ストレージを使用して構成されたマネージド インスタンスでのみ利用できます。 現在、データベースに geo レプリケートされたバックアップを使用していない場合は、バックアップ ストレージの冗長性を構成することでこれを変更できます。
  • geo リストアは、同じサブスクリプションにのみ存在するマネージド インスタンスに対して実行できます。

geo リストアは、ホスティング リージョンでのインシデントが原因でデータベースが利用できない場合の既定の復旧オプションです。 データベースは他の任意のリージョンのインスタンスに復元できます。 geo レプリケートされた最新のバックアップから任意の Azure リージョン内の任意のマネージド インスタンスでデータベースを復元することができます。 geo リストアでは、geo レプリケートされたバックアップをソースとして使用します。 障害によってデータベースまたはデータセンターにアクセスできない場合でも、geo リストアを要求できます。

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

geo リストアを目的としてリージョン間でデータベースを復元している図。

Azure portal から、geo レプリケートされたバックアップを既存のインスタンスに復元することも、新しいマネージド インスタンスを作成して使用可能な geo リストア バックアップを選択することもできます。 新しく作成されたデータベースに、geo リストアされたバックアップ データが格納されます。

既存のインスタンスに復元するには、「ポイントインタイム リストア」の手順に従い、目的のインスタンスにデータベースを復元するための適切なソースおよびターゲット インスタンスを必ず選んでください。

Azure portal を使用して新しいインスタンスに geo リストアするには、次の手順に従います。

  1. 新しい Azure SQL Managed Instance に移動してください。
  2. [新しいデータベース] を選択します。
  3. データベース名を入力します。
  4. [データ ソース] で、適切な種類のバックアップを選んでから、データ ソースの詳細を指定します。
  5. 使用可能な geo リストア バックアップの一覧からバックアップを選択します。

完了したインスタンス データベースの作成プロセスには、復元された geo リストア バックアップが含まれます。

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

geo リストアは、Azure SQL Managed Instance で使用できる最も基本的なディザスター リカバリー ソリューションです。 これは、セカンダリ (ペア) リージョンに自動的に作成された geo レプリケート バックアップに依存します。 geo リストアに関する考慮事項を次に示します。

  • 回復ポイントの目標 (RPO) は最大で 1 時間です。
  • 回復プロセス (復元時間目標 - RTO) にかかる時間は、通常、12 時間未満ですが、データベースのサイズとアクティビティによって異なる場合があるため、復元時間はこれを超えて延長される可能性があります。
  • セカンダリ (ペア) リージョンは、プライマリ リージョンの Azure Storage 設定です。 セカンダリ リージョンを変更することはできません。
  • 新しいデータの設定に時間がかかるため、新規作成/復元されたデータベースは、他のリージョンで復元可能としてすぐに表示されない場合があります。 新しいデータベースのバックアップが表示されない場合は、最大 24 時間の待機期間が予想されます。

「geo リストア」は、ビジネス クリティカルではない、比較的小規模なデータベースを使用するアプリケーションに適用されるディザスター リカバリー ソリューションとして機能することを認識しておくことが重要です。 大規模なデータベースを必要とし、ビジネス継続性を保証する必要があるビジネス上不可欠なアプリケーションの場合は、フェールオーバー グループを使用します。 その機能により、大幅に低い RPO と RTO が実現され、容量が常に保証されます。

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

制限事項

バックアップと Azure SQL Managed Instance を使うときは、次の制限事項を考慮してください。

  • データベースの geo リストアは、ソース SQL マネージド インスタンスと同じサブスクリプション内のインスタンスに対してのみ実行できます。
  • Azure SQL Managed Instance のデータベースは、既定では TDE を使って暗号化されます。 ソース データベースがカスタマー マネージド キー (CMK) を TDE 保護機能として使用した場合に、ソース SQL Managed Instance 以外のインスタンスにデータベースを復元するには、Azure Key Vault でソース データベースの暗号化に使われるものと同じキーに、ターゲット インスタンスがアクセスできる必要があります。または、バックアップを作成する前に、ユーザーがソース データベースで TDE 暗号化を無効にする必要があります。
  • 復元プロセスの進捗を追跡するには、sys.dm_exec_requests と sys.dm_operation_status の動的管理ビューを使用してください。
  • Azure SQL Managed Instance に委任されたサブネットにサービス エンドポイント ポリシーが存在する場合、そのサブネット内のマネージド インスタンスへのポイントインタイム リストア (PITR) を、異なるリージョンのインスタンスから実行することはできません。
  • 回復ポイントの目標 (RPO) は最大で 1 時間です。
  • 復元時間目標 (RTO) は約 12 時間ですが、データベースのサイズによって異なる場合があり、アクティビティがこの時間枠を超える可能性があります。
  • セカンダリ (ペア) リージョンを変更することはできません。
  • 新しいデータの設定に時間がかかるため、新規作成/復元されたデータベースは、他のリージョンで復元可能としてすぐに表示されない場合があります。 新しいデータベースのバックアップが表示されるまでに、最大で 24 時間かかる場合があります。
  • 並行して復元できるデータベースの最大数は、1 つのサブスクリプションにつき 200 個です。 サポート チケットを開くことで、この制限を引き上げることができる場合があります。
  • SQL Server 2022 更新ポリシーを使用して構成されたインスタンスから取得されたデータベース バックアップは、SQL Server 2022 または Always-up-to-date 更新ポリシーのいずれかを使用して構成されたインスタンスに復元できます。 Always-up-to-date 更新ポリシーを使用して構成されたインスタンスから取得されたデータベース バックアップは、Always-up-to-date 更新ポリシーを使用して構成されたインスタンスにのみ復元できます。

関連するコンテンツ