すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:インスタンス全体のリストア

最終更新日:Jun 21, 2026

ソースインスタンスのデータバックアップとログバックアップを使用して、それらを新しいインスタンスにリストアできます。これは、誤操作からの復旧や過去データの分析などのシナリオで役立ちます。

前提条件

ソースインスタンスは、以下の要件を満たしている必要があります。

  • インスタンスが 実行中 で、ロックされていないこと。

  • 進行中の移行タスクがないこと。

  • 少なくとも1つのバックアップが完了しています。 ApsaraDB for RDS は、デフォルトで自動バックアップを実行します。 バックアップ方法の詳細については、「バックアップソリューションの概要」をご参照ください。

  • 特定の時点への復元には、ログバックアップを有効にする必要があります。詳細については、「ApsaraDB RDS for MySQL インスタンスのログバックアップ」をご参照ください。

  • バックアップセットからデータを復元するには、ソースインスタンスに少なくとも 1 つの物理バックアップが必要です。 詳細については、「自動バックアップ」をご参照ください。

仕組み

image

項目

説明

リストア範囲

インスタンス全体がリストアされます。

新しいインスタンスの設定

新しいインスタンスのホワイトリスト、バックアップ設定、およびパラメータ設定は、ソースインスタンスと同じになります。

新しいインスタンスのアカウント情報

新しいインスタンスには、選択したリストアポイントの時点、または選択したバックアップセットのソースインスタンスのアカウント情報が含まれます。

新しいインスタンスのデータ

新しいインスタンスのデータは、リストアに使用されたバックアップファイルのデータと同じです。

リストアポイント

  • ログバックアップが無効になっている場合、既存のデータバックアップが作成された時点にのみデータをリストアできます。

  • 通常のログバックアップが有効になっている場合、ログバックアップの保持期間内の任意の時点にデータをリストアできます。

  • ポイントインタイムリストア (ログバックアップの拡張版) が有効になっている場合、[ポイントインタイムリストアの利用可能日数] で指定された期間内の任意の時点にデータを復元できます。

説明

リストア時間

リストア時間は複数の要因に影響を受けます。例えば、200 GB のデータをリストアするには約 3 時間かかります。詳細については、本トピックの FAQ セクションをご参照ください。

課金

データをリストアすると新しいインスタンスが作成され、料金が発生します。

説明

機能の有効化

この機能を手動で有効にする必要はありません。新しいインスタンスが作成されると、システムは自動的に定期バックアップを実行します。生成されたデータバックアップとログバックアップを使用して、インスタンスをリストアできます。

操作手順

ソースインスタンスのバックアップからデータをリストアすると、新しいインスタンスが作成されます。このプロセスは、ソースインスタンスのパフォーマンスに影響を与えません。

  1. RDSインスタンスにアクセスし、上部のリージョンを選択し、対象のRDSインスタンスのIDをクリックします。
  2. 左側のナビゲーションペインで、復元 をクリックします。

  3. ページの左上隅で、データベースの復元 (元クローンインスタンス) をクリックします。

    説明

    また、基本情報 ページに移動し、インスタンスの分布 セクションにある データベースの回復 をクリックすることもできます。

  4. データベースの復元 ページで、復元時点またはバックアップセットを選択し、新規インスタンスの基本リソースを設定します。

    パラメータ

    説明

    [課金方法]

    • [サブスクリプション]:長期間のご利用に適した前払い方式です。サブスクリプション期間が長いほど、割引率が高くなります。

    • [従量課金]:短期的なニーズに適した、時間単位で課金される後払い方式です。不要になったインスタンスは解放できます。

    [復元タイプ]

    • [バックアップ ID]:指定されたバックアップセットからデータを復元します。論理バックアップはサポートされていません。

    • [時刻で]: 保持期間内の任意の時点にデータを復元します。これにはログバックアップが有効になっている必要があります。

    [制品タイプ]

    • ソースインスタンスが ベーシックエディション の場合、このパラメーターは利用できません。

    • ソースインスタンスが高可用性エディションの場合:

      • ストレージタイプESSDクラウドディスクまたはユニバーサルクラウドディスクの場合、スタンダード版または 天国版 を選択できます。 詳細については、「製品タイプ」をご参照ください。

      • ストレージタイプローカル SSD の場合、スタンダード版 のみがサポートされます。

    • ソースインスタンスが クラスターエディション の場合、スタンダード版 または 天国版 を選択できます。

    ゾーン

    インスタンスを、シングルゾーンデプロイ または マルチゾーンデプロイ に設定できます。

    • [シングルゾーンデプロイ]:プライマリノードとセカンダリノードが同じゾーンに配置されます。

    • [マルチゾーンデプロイ] (推奨):プライマリノードとセカンダリノードは、災害復旧のために異なるゾーンに配置されます。

    説明
    • インスタンスの作成後、インスタンスの可用性 ページでプライマリおよびセカンダリノードの情報を表示できます。

    • Basic Edition インスタンスは、シングル AZ 配置のみをサポートします。

    [インスタンスタイプ]

    • [汎用]: 専用のメモリと I/O リソースを提供しますが、同じサーバー上の他の汎用インスタンスと CPU およびストレージリソースを共有します。

    • [専用]: 専用の CPU、メモリ、ストレージ、および I/O リソースを提供します。最上位の専用ホストインスタンスは、サーバー上のすべてのリソースを専有します。

    説明

    各インスタンスタイプには、対応する CPU コア数、メモリサイズ、最大接続数、および最大 IOPS があります。詳細については、「プライマリインスタンスタイプ」をご参照ください。

    [ストレージ容量]

    • データ、システムファイル、バイナリログファイル、およびトランザクションファイル用の領域が含まれます。

    • 5 GB 単位で調整可能です。

  5. [次へ: インスタンス設定] をクリックして、インスタンスのネットワークタイプとリソースグループを設定し、次のパラメーターを設定します。

    パラメータ

    説明

    [ネットワークタイプ]

    • [クラシックネットワーク]: 従来型のネットワークタイプです。

    • [VPC] (推奨): 仮想プライベートクラウド (VPC) は、クラシックネットワークよりも高いセキュリティとパフォーマンスを提供する、隔離されたネットワーク環境です。 VPC を選択した場合は、対応する VPCプライマリノードの VSwitch も選択する必要があります。 前の 基本設定 ステップで マルチゾーンデプロイ を設定した場合は、セカンダリノードの VSwitch も選択する必要があります。

    説明

    RDS インスタンスと接続する ECS インスタンスが同じネットワークタイプであることを確認してください。VPC を選択する場合は、同じ VPC 内にある必要があります。そうでない場合、内部ネットワーク経由で通信できません。

    [リソースグループ]

    リソースグループは、Alibaba Cloud アカウントでリソースをグループごとに管理するための仕組みです。これにより、単一アカウントのリソースのグループ化と権限管理が簡素化されます。既存のリソースグループを選択するか、新しいリソースグループを作成できます。リソースをグループで管理する必要がない場合は、デフォルトのリソースグループ を選択します。

  6. [次へ: 注文の確認] をクリックします。

  7. パラメーターを確認し、購入プラン期間 (サブスクリプションインスタンスの場合のみ) を選択し、今すぐ支払いをクリックして、支払いを完了します。

    説明

    サブスクリプションインスタンスの場合、自動更新 を選択することをお勧めします。これにより、インスタンスを手動で更新する手間が省け、更新を忘れることによるサービスの中断を防ぐことができます。

  8. (任意) 新しいインスタンスの作成後、それにログオンして、データを確認できます。

ソースインスタンスのデータ修正

データが新しいインスタンスに復元された後、データ伝送サービス (DTS) を使用してデータベースやテーブルの一部またはすべてを移行することで、ソースインスタンスのデータを更新できます。

説明

データ移行タスクを作成するときは、復元された新しいインスタンスをソースとして、ソースインスタンスを宛先として指定します。ソースと宛先の両方で、[Alibaba Cloud インスタンス][アクセス方法] として選択します。

関連操作

よくある質問

1 つまたは複数のデータベースを誤って削除してしまった場合はどうすればよいですか。

データベースとテーブルの復元を実行できます。この機能に対応していないインスタンスでは、このトピックの手順に従って、すべてのデータを新しいインスタンスに復元できます。検証後、データを元のインスタンスに移行します。

ApsaraDB for RDS for MySQL インスタンスを特定の時点にリストアできますか。

はい。ログバックアップが有効になっている場合、ログバックアップの保持期間内の任意の時点にリストアできます。ログバックアップが無効になっている場合、既存のデータバックアップが作成された時点にのみデータをリストアできます。

データバックアップがない場合、ポイントインタイムリストアを実行できますか。

いいえ。ポイントインタイムリストアは、まず指定された時点より前に作成された完全なデータバックアップをリストアし、次にバイナリログから増分データを適用してその時点まで復元します。このプロセスにはデータバックアップが必要です。

バックアップ保持期間が 7 日に設定されています。それより前の時点にデータをリストアできますか。

いいえ。バックアップは保持期間後に自動的に削除され、復旧できません。

バックアップ保持期間が 7 日です。Data Management (DMS) のデータ追跡機能を使用して、削除されたバックアップを取得できますか。

いいえ。データ追跡機能は、バイナリログを使用してデータを復元します。保持期間が 7 日間に設定されているため、それより古いバイナリログは利用できません。バックアップの保持期間は変更できます。詳細については、「自動バックアップ」をご参照ください。

データベースのリストアに料金が発生するのはなぜですか。

データをリストアすると新しいインスタンスが作成され、料金が発生します。

説明

新しいインスタンスにデータをリストアするにはどのくらい時間がかかりますか。

新しいインスタンスにデータをリストアする時間は、データ量とネットワーク状況によって異なり、通常は数分から数時間かかります。詳細は以下のとおりです。

推定例

テスト環境:2 CPU コア、4 GB メモリ、プレミアムローカル SSD を搭載した High-availability Edition インスタンス。

操作

推定時間

インスタンスの作成

5 分

インスタンスの設定

15 分

バックアップデータのダウンロード

200 GB/時間

インスタンスの起動

5 分

バイナリログのダウンロード

200 GB/時間

バイナリログの適用

バイナリログの内容によって異なります。

説明
  • 例えば、200 GB のデータをリストアするには約 3 時間かかります。これは、バックアップデータのダウンロードとバイナリログのダウンロードが直列操作であり、バイナリログの適用に 30 分かかることを前提としています。

  • 復元を高速化するために、サンドボックスインスタンスを有効にできます。システムは、迅速なリカバリができるように、サンドボックスストレージにデータを自動的に同期します。詳細については、「ApsaraDB RDS for MySQL インスタンスの緊急リカバリ」をご参照ください。

影響要因

リストア速度は複数の要因に影響を受け、成功が保証されるわけではありません。一部の SQL 例外は手動調査が必要になる場合があります。リストア速度に影響を与える主な要因は以下のとおりです。

  • データ量: データ量が多いほど、リストア速度は遅くなります。

  • 大規模トランザクション: バイナリログ内の大規模トランザクションは、リストアプロセスを遅らせます。

  • ホットスポット更新: バイナリログ内のホットスポット更新は、リストアプロセスを遅らせます。

  • 外部キー制約 (FOREIGN KEY): 外部キー制約は検証コストを増加させ、リストアプロセスを遅らせます。

  • バイナリログの数: ポイントインタイムリストア中、必要なバイナリログの数が多いほど、リストア速度は遅くなります。

  • ストレージタイプ: ストレージの種類はリストア速度に影響します。一般的に、I/O パフォーマンスが高いディスクほどリストアは高速になります。

  • インスタンスタイプ: 高スペックのインスタンスほど、データのリストアが高速になります。

  • インスタンスバージョン: インスタンスバージョンによって、並列レプリケーションポリシーが異なります。並列レプリケーションをサポートしないシナリオでは、シングルスレッドモードで実行されるため、リストア速度に影響します。

重要

上記の要因に加えて、以下の状況もリストア失敗の原因となる可能性があります。

  • 新しいインスタンスのデータベースエンジンバージョンがソースインスタンスより古い場合、バイナリログの解析エラーが発生する可能性があります。

  • 中国語や特殊文字を含むテーブル名または列名は、リストア失敗の原因となる可能性があります。

  • ソースインスタンスからバイナリログが削除された場合、リストアを完了できません。

  • ソースインスタンスで implicit_primary_key パラメータが無効になっている場合、プライマリキーのないテーブルのリストアは失敗します。

リストアプロセス中にプライマリ VSwitch を選択できないのはなぜですか。

前の「基本設定」ステップで選択したゾーンに vSwitch が存在しないため、現在の「ネットワークとリソースグループ」ステップではプライマリノード vSwitch が利用できない場合があります。VPC コンソールへ移動します。 をクリックして VPC コンソールに移動し、ゾーンに vSwitch を作成できます。その後、プライマリノード vSwitch を選択できるようになります。インスタンス作成の「ネットワークとリソースグループ」ステップで、ネットワークタイプとして「VPC」を選択し、プライマリノード vSwitch が利用できない場合は、プライマリノード vSwitch フィールドの下にある「コンソールで作成」リンクをクリックしてコンソールに移動し、新しい vSwitch を作成できます。