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 リストア、および長期保有バックアップからの復元の任意の組み合わせに適用されます。

デプロイ オプション 処理される同時要求の最大数 送信される同時要求の最大数
単一のデータベース (サブスクリプションごと) 30 100
エラスティック プール (プールごと) 4 2,000

アクセス許可

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

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

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

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

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

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

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

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

重要

  • 同じサーバーに対してデータベースのポイントインタイム リストアを実行できます。 現在、サーバー間、サブスクリプション間、地域間をまたがるポイントインタイム リストアはサポートされていません。 geo レプリケートされたバックアップを使ってデータベースを別のリージョンに復元するには、「geo リストア」を参照してください。
  • geo セカンダリ データベースでは、ポイントインタイム リストアを実行できません。 これを実行できるのは、プライマリ データベースだけです。
  • BackupFrequency パラメーターは Hyperscale データベースではサポートされていません。
  • データベースの復元操作はリソースを集中的に使用するため、復元する (ターゲット) データベースには S3 以上のサービス レベルが必要になる場合があります。 復元が完了したら、必要に応じてデータベースまたはエラスティック プールをスケールダウンできます。
  • データベースの置換

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

  • データの復旧

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

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

Azure portal を使用してデータベースを特定の時点に復旧するには、データベースの概要ページを開き、ツール バーの [復元] を選択します。 バックアップ ソースを選択し、新しいデータベースを作成する特定の時点のバックアップ ポイントを選択します。

SQL Database のデータベース復元オプションのスクリーンショット。

長期バックアップの復元

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

Azure portal を使って長期バックアップを復元するには、論理サーバーに移動します。 [設定][バックアップ] を選び、復元するデータベースの [Available LTR backups] (使用できる LTR バックアップ)[管理] を選びます。

使用できる長期保持バックアップを表示する Azure portal のスクリーンショット。

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

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

重要

サーバーを削除すると、そのデータベースはすべて削除され、PITR バックアップは復旧することもできなくなります。 削除されたサーバーを復元することはできません。削除されたデータベースを PITR バックアップから復元することはできません。 それらのデータベースに対して LTR バックアップを構成した場合、それらのバックアップを使用して、データベースを別のサーバーに復元できます。

Azure portal を使用して削除済みデータベースを削除時刻まで復旧するには、サーバーの概要ページを開き、[削除済みデータベース] を選択します。 復元する削除されたデータベースを選択し、次にバックアップから復元されたデータを使用して作成される新しいデータベースの名前を入力します。

削除されたデータベースの復元方法を示す Azure portal のスクリーンショット。

ヒント

最近削除されたデータベースを Azure portal の [削除されたデータベース] ページに表示するか、プログラムで削除されたデータベースを表示するには、数分かかる場合があります。

geo リストア

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

重要

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

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

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

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

geo リストアの図。

Azure portal から、新しい単一データベースを作成し、使用可能な geo リストア バックアップを選択します。 新しく作成されたデータベースに、geo リストアされたバックアップ データが格納されます。

選択したリージョンとサーバーの単一データベースを Azure portal から geo リストアするには、次の手順に従います。

  1. ダッシュボードから、 [追加]>[SQL データベースの作成] を選択します。 [基本] タブで、必要な情報を入力します。
  2. [追加設定] を選択します。
  3. [既存のデータを使用します][バックアップ] を選択します。
  4. 使用可能な geo リストア バックアップの一覧からバックアップを選択します。

Azure portal でデータベースを作成するためのオプションを示すスクリーンショット。

データベースをバックアップから作成するプロセスを完了します。 Azure SQL Database でデータベースを作成すると、復元された geo リストア バックアップが格納されます。

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

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

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

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

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

注意

geo リストアをディザスター リカバリー ソリューションとして使う予定の場合、復旧手順のすべての運用面と共に、最近のデータ変更の損失に対するアプリケーションの許容度を検証するために、定期的な訓練を実施することをお勧めします。

次の手順