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

Data Management:データディザスタリカバリ (旧称 DBS) よくある質問

最終更新日:Mar 29, 2026

このページでは、データディザスタリカバリに関するよくある質問に回答します。課金、サービスの有効化、バックアップ構成、権限、トラブルシューティングについて説明します。

課金に関するよくある質問

バックアップスケジュールの課金項目は何ですか?

バックアップスケジュールには、最大 4 つの課金項目があります。

  • タイプ:サブスクリプションを購入する際に、バックアップスケジュールの仕様に対して料金が発生します。バックアップデータの無料クォータ、単位価格、バックアップおよび復元パフォーマンスは、スケジュールタイプによって異なります。詳細については、「バックアップ料金」をご参照ください。

  • ストレージ(オプション):サブスクリプションバックアップスケジュールのストレージタイプを DBS ストレージ に設定した場合、使用したストレージ容量と保存期間に対して料金が発生します。詳細については、「ストレージ料金」をご参照ください。

  • バックアップ(オプション):バックアップされたデータ量がスケジュールタイプの無料クォータを超えた場合、超過分に対して料金が発生します。詳細については、「バックアップ料金」をご参照ください。

  • サンドボックス(オプション):データディザスタリカバリでは、自己管理 MySQL データベースのディザスタリカバリ用にサンドボックスインスタンスを作成できます。有効化後、データ量に基づいてサンドボックスストレージ料金が、仕様および使用時間に基づいてサンドボックスインスタンス料金が発生します。詳細については、「料金」をご参照ください。

従量課金のバックアップスケジュールは作成できません。

ストレージプランおよびネットワークプランで相殺できる料金はどれですか?

ストレージプラン

データディザスタリカバリでは、2 種類のストレージプランを提供しています。サイズは 100 GB、500 GB、1 TB、500 TB、サブスクリプション期間は 1 ヶ月、6 ヶ月、1 年から選択できます。プランのクォータを超えるストレージ使用量については、従量課金で請求されます。

プランタイプオフセット対象
CDM サンドボックスインスタンスのストレージプランご利用のアカウントのサンドボックスストレージ料金。料金詳細については、「サンドボックス料金」をご参照ください。
バックアップスケジュールインスタンスのストレージプラン同じ Alibaba Cloud アカウント内のバックアップスケジュールインスタンスのストレージ使用量。詳細については、「組み込みストレージと OSS」をご参照ください。

ネットワークプラン

データディザスタリカバリのネットワークプランは、世界中のすべてのリージョンで利用できます。

相殺対象説明
クロスリージョンバックアップのネットワークトラフィックApsaraDB RDS for MySQL、ApsaraDB RDS for PostgreSQL、ApsaraDB RDS for SQL Server、PolarDB for MySQL、PolarDB for PostgreSQL、ApsaraDB for MongoDB データベースのクロスリージョンバックアップで消費されるネットワークトラフィックを相殺します。相殺はリージョン固有のオフセット係数を使用して計算されます。
バックアップセットダウンロードのネットワークトラフィックApsaraDB RDS for MySQL、ApsaraDB RDS for PostgreSQL、ApsaraDB RDS for SQL Server データベースのバックアップセットダウンロードで消費されるネットワークトラフィックを相殺します。相殺はリージョン固有のオフセット係数を使用して計算されます。

相殺ルール、オフセット係数、例、および購入方法については、「ストレージプランの使用」および「ネットワークプランの使用」をご参照ください。

未使用のバックアップスケジュールにも料金は発生しますか?

はい。新しいバックアップセットが生成されていなくても、既存のバックアップセットはストレージを占有しているため、ストレージ料金が発生します。

不要なコストを回避するには:

  • 従量課金:関連データを保存し、履歴バックアップセットをダウンロードした後、バックアップスケジュールをリリースしてください。リリース後は、バックアップ料金およびストレージ料金は発生しません。「バックアップスケジュールのリリースまたは登録解除」をご参照ください。

  • サブスクリプション (前払い):長期間サブスクリプションバックアップスケジュールの使用を停止する予定だが、履歴バックアップセットを保持したい場合は、「バックアップスケジュールの一時停止または再開」できます。スケジュールを一時停止すると、新しいバックアップ料金は発生しませんが、DBS ストレージ を使用しているサブスクリプションバックアップスケジュールについては、引き続きストレージ料金が発生します。

  • サブスクリプション:履歴バックアップセットを保持しつつバックアップの実行を停止したい場合は、バックアップスケジュールを一時停止してください。一時停止中はバックアップ料金は発生しませんが、ストレージタイプが DBS ストレージ の場合は、引き続きストレージ料金が発生します。「バックアップスケジュールの一時停止または開始」をご参照ください。

サブスクリプションバックアップスケジュールを一時停止しても、サブスクリプション期間は変更されません。
ストレージ料金は、ストレージタイプが DBS ストレージ の場合にのみ発生します。

バックアップスケジュールのリリース方法やバックアップファイルサイズの削減方法については、「バックアップデータのサイズの確認と削減」、「バックアップファイルの削除またはサイズの縮小」、および「削除済みインスタンスのバックアップ機能の使用」をご参照ください。

サブスクリプションと従量課金の課金方法を切り替えることはできますか?

いいえ。バックアップスケジュールの課金方法を従量課金からサブスクリプションに、またはサブスクリプションから従量課金に変更することはできません。

従量課金のバックアップスケジュールをリリースできますか?

はい。「バックアップスケジュールのリリースまたは登録解除」をご参照ください。

サブスクリプションバックアップスケジュールの登録を解除できますか?

いいえ。サブスクリプションバックアップスケジュールのリリースまたは登録解除はできません。「課金対象機能の登録解除」をご参照ください。バックアップスケジュールの登録を解除できません

ストレージプランまたはネットワークプランの有効期限が切れるとどうなりますか?

ストレージプラン および ネットワークプラン は有効期限切れ後に無効になり、ストレージ料金またはネットワークトラフィック料金の相殺ができなくなります。バックアップスケジュールおよび既存のバックアップデータには影響しません。

バックアップスケジュールの有効期限が切れた場合や支払いが遅延した場合はどうなりますか?

サービスの有効期限切れと支払い遅延」をご参照ください。

サブスクリプションバックアップスケジュールのコストを削減するにはどうすればよいですか?

同一 Alibaba Cloud アカウント内のバックアップスケジュールの内蔵ストレージ料金を相殺するために、ストレージプラン を購入してください。「内蔵ストレージと OSS」をご参照ください。

コンソールでバックアップを使用していない場合の課金項目は何ですか?

データディザスタリカバリは、ApsaraDB RDS、PolarDB、ApsaraDB for MongoDB、Redis、Tair、AnalyticDB for PostgreSQL のバックアップおよび復元も提供しています。これらのサービスを通じて使用されているバックアップおよび復元機能に対して料金が発生していないか確認してください。「料金」をご参照ください。

異常なバックアップスケジュールのエラー修正

概要

バックアップスケジュールページで、バックアップスケジュールが異常な状態を示しています。

image..png

原因

バックアップスケジュールが異常であるということは、スケジュール内の少なくとも 1 つのタスクが失敗していることを意味します。最も一般的なのは、完全バックアップまたは増分バックアップタスクです。

タスクが失敗した場合、ビジネスへの予期しない影響を防ぐために、データディザスタリカバリは自動的にタスクを再開しません。
できるだけ早くエラーをトラブルシューティングしてください。以下の手順を実行しても問題が解決しない場合は、DingTalk グループ (ID: 35585947) のテクニカルサポートにお問い合わせください。

ソリューション

根本原因を特定できたかどうかに基づいて、以下のいずれかの解決策を選択してください。

シナリオ解決策注記
根本原因を特定して修正済み(例:ソースインスタンスがシャットダウンされていたが、現在は再起動済み)。異常なタスクを再開します。完全バックアップタスクの場合、ソースデータベースへの影響を評価し、ピーク時以外の時間帯に再開してください。エラーが修正されている場合、タスクの状態は 完了 に変化します。バックアップスケジュールがまだ異常な場合は、他の失敗したタスクがないか確認してください。エラーが継続する場合は、タスクは再度 エラー に戻り、さらに調査が必要です。
根本原因を特定して修正済みで、次のスケジュールバックアップで復旧可能。エラーを無視します。次のバックアップウィンドウでバックアップが実行されます。エラーが修正されている場合、タスクの状態は 完了 に変化します。バックアップスケジュールがまだ異常な場合は、他の失敗したタスクがないか確認してください。
根本原因を特定できない。[ステータス] 列の感嘆符 (!) アイコンにカーソルを合わせてエラーの詳細を表示し、「データディザスタリカバリの一般的なエラーとトラブルシューティング」で解決策を検索します。そのトピックにエラーが記載されていない場合や問題が継続する場合は、DingTalk グループ (ID: 35585947) のテクニカルサポートにお問い合わせください。

操作手順

  1. 左側のナビゲーションウィンドウで、バックアップスケジュール をクリックします。異常なバックアップスケジュールを見つけ、ステータス 列の 修正 をクリックします。失敗したタスクタイプのタスクリストページに移動します。完全バックアップタスクの場合は 完全データ ページ、増分バックアップタスクの場合は 増分データ ページです。

    image..png

  2. 状況に応じて以下のいずれかの解決策を選択します。

    • 再開:失敗したタスクを見つけ、ステータス 列の バックアップを再開 をクリックします。> 注記: 完全バックアップタスクの場合、再開前にソースデータベースへの影響を評価してください。ピーク時以外の時間帯に再開してください。image..png

    • エラーを無視:失敗したタスクを見つけ、ステータス 列の エラーを無視 をクリックします。image..png

    • エラーの検索:完全バックアップタスクの場合、ステータス 列の感嘆符 (!) アイコンにカーソルを合わせ、例外修正提案の表示 をクリックします。増分バックアップタスクの場合、増分データ ページの上部にある 増分例外修正提案の表示 をクリックします。どちらのオプションも「データディザスタリカバリの一般的なエラーとトラブルシューティング」に移動します。> 注記: そのトピックにエラーが記載されていない場合は、別のタイプのタスク失敗が原因である可能性があります。DingTalk グループ (ID: 35585947) のテクニカルサポートにお問い合わせください。image.png

データディザスタリカバリの有効化

初めてご利用になる場合は、次の 2 つのステップを完了する必要があります。AliyunServiceRoleForDBS ロールをデータディザスタリカバリに割り当てること、および Object Storage Service (OSS) を有効化することです。これらの権限付与により、データディザスタリカバリはバックアップスケジュールのパフォーマンスに影響を与えることなく、ご利用のデータベースにアクセス・管理し、OSS にバックアップデータを保存できます。

ステップ 1:AliyunServiceRoleForDBS ロールの割り当て

AliyunServiceRoleForDBS は、Resource Access Management (RAM) のサービスリンクロールであり、データディザスタリカバリが Alibaba Cloud データベースサービス(ApsaraDB RDS、ApsaraDB for MongoDB、Redis、PolarDB クラスター、Elastic Compute Service (ECS) インスタンス上でホストされている自己管理データベースを含む)にアクセスすることを許可します。サービスリンクロールの詳細については、「サービスリンクロール」をご参照ください。

  1. DMS コンソール V5.0 にログインします。

  2. 上部のナビゲーションバーで、セキュリティと仕様 (DBS) > データディザスタリカバリ (DBS) > ディザスタリカバリデータソース を選択します。

    シンプルモードの場合、左上隅の 2023-01-28_15-57-17.png アイコンにカーソルを合わせ、すべての機能 > セキュリティと仕様 (DBS) > データディザスタリカバリ (DBS) > ディザスタリカバリデータソース を選択します。
  3. 表示されたダイアログボックスで、DBS SLR の承認 をクリックします。

    ログイン後にダイアログボックスが表示されない場合は、このステップをスキップして、直接バックアップスケジュールを作成してください。「ディザスタリカバリデータソースを使用したバックアップの管理」または「バックアップスケジュールリストを使用したバックアップの作成」をご参照ください。
  4. OK をクリックします。

AliyunServiceRoleForDBS ロールが作成されました。後でこのロールを削除するには、「RAM ロールの削除」をご参照ください。

ステップ 2:OSS の有効化

OSS の有効化は無料です。有効化後、データディザスタリカバリは OSS にバックアップデータを保存できます。

  1. DMS コンソール V5.0 にログインします。

  2. 上部のナビゲーションバーで、セキュリティと仕様 (DBS) > データディザスタリカバリ (DBS) > バックアッププラン を選択します。

    シンプルモードの場合、左上隅の 2023-01-28_15-57-17.png アイコンにカーソルを合わせ、すべての機能 > セキュリティと仕様 (DBS) > データディザスタリカバリ (DBS) > バックアッププラン を選択します。
  3. 表示されたダイアログボックスで、今すぐ OSS を有効化 をクリックします。

  4. 次のダイアログボックスで、今すぐ有効化 をクリックします。

  5. OSS ページで、サービス契約書を読み、チェックボックスをオンにして同意し、今すぐ有効化 をクリックします。

これでデータディザスタリカバリが有効化されました。

AliyunServiceRoleForDBS

ロール名:AliyunServiceRoleForDBS

ロールにアタッチされたポリシー:AliyunServiceRolePolicyForDBS

権限:

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "rds:DescribeDBInstanceNetInfo",
        "rds:DescribeDBInstanceNetInfoForChannel",
        "rds:DescribeTasks",
        "rds:DescribeDBInstances",
        "rds:DescribeFilesForSQLServer",
        "rds:DescribeImportsForSQLServer",
        "rds:DescribeSlowLogRecords",
        "rds:DescribeBinlogFiles",
        "rds:DescribeSQLLogRecords",
        "rds:DescribeParameters",
        "rds:DescribeParameterTemplates",
        "rds:DescribeDBInstanceAttribute",
        "rds:DescribeDatabases",
        "rds:DescribeAccounts",
        "rds:DescribeSecurityIPList",
        "rds:DescribeSecurityIps",
        "rds:DescribeDBInstanceIPArray",
        "rds:DescribeDBInstanceIPArrayList",
        "rds:DescribeDBInstanceSSL",
        "rds:DescribeDBInstanceTDE",
        "rds:CreateDBInstance",
        "rds:CreateAccount",
        "rds:CreateDatabase",
        "rds:ModifySecurityIps",
        "rds:GrantAccountPrivilege",
        "rds:CreateMigrateTask",
        "rds:CreateOnlineDatabaseTask",
        "rds:DescribeMigrateTasks",
        "rds:DescribeOssDownloads",
        "rds:CreateBackup",
        "rds:DescribeBackups",
        "rds:DescribeBackupPolicy",
        "rds:ModifyBackupPolicy",
        "rds:DescribeBackupTasks",
        "rds:DescribeBinlogFiles"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "ecs:DescribeInstance",
        "ecs:DescribeInstances",
        "ecs:DescribeVpcs",
        "ecs:DescribeSecurityGroups",
        "ecs:DescribeSecurityGroupAttribute",
        "ecs:AuthorizeSecurityGroup",
        "ecs:JoinSecurityGroup",
        "ecs:RevokerSecurityGroup"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "kms:ListKeys"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "cms:PutEventRule",
        "cms:PutEventTargets",
        "cms:ListEventRules",
        "cms:ListEventTargetsByRule",
        "cms:DeleteEventRule",
        "cms:DeleteEventTargets"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "polardb:DescribeDBClusterIPArrayList",
        "polardb:DescribeDBClusterNetInfo",
        "polardb:DescribeDBClusters",
        "polardb:ModifySecurityIps",
        "polardb:DescribeDBClusterEndpoints",
        "polardb:DescribeDBClusterAccessWhitelist",
        "polardb:ModifyDBClusterAccessWhitelist"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "dds:DescribeDBInstanceAttribute",
        "dds:DescribeReplicaSetRole",
        "dds:DescribeSecurityIps",
        "dds:DescribeDBInstances",
        "dds:ModifySecurityIps"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "kvstore:DescribeSecurityIps",
        "kvstore:DescribeInstances",
        "kvstore:DescribeAccounts",
        "kvstore:DescribeDBInstanceNetInfo",
        "kvstore:CreateAccount",
        "kvstore:ModifySecurityIps",
        "kvstore:DescribeInstanceAttribute",
        "kvstore:AllocateInstancePrivateConnection",
        "kvstore:DescribeLogicInstanceTopology"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "drds:DescribeDrdsDB",
        "drds:DescribeDrdsDBs",
        "drds:DescribeDrdsDbInstance",
        "drds:DescribeDrdsDbInstances",
        "drds:DescribeDrdsDBIpWhiteList",
        "drds:DescribeDrdsInstances",
        "drds:ModifyDrdsIpWhiteList",
        "drds:CreateDrdsDB",
        "drds:DescribeTable",
        "drds:DescribeTables",
        "drds:ModifyRdsReadWeight",
        "drds:ChangeAccountPassword",
        "drds:CreateDrdsInstance",
        "drds:CreateInstanceAccount",
        "drds:CreateInstanceInternetAddress",
        "drds:DescribeInstanceAccounts"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVpcs"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "bssapi:QueryResourcePackageInstances"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": "hdm:AddHDMInstance",
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": "ram:DeleteServiceLinkedRole",
      "Resource": "*",
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "ram:ServiceName": "dbs.aliyuncs.com"
        }
      }
    }
  ]
}

データベースアカウントに必要な権限

MySQL データベース

機能必要な権限
バックアップ物理バックアップ:LOCK_TABLESREPLICATION_CLIENTPROCESSSUPERCREATE、および RELOAD。MySQL 8.0 の場合、アカウントには BACKUP_ADMIN 権限と、performance_schema.log_status テーブルおよび keyring_component_status テーブルに対する SELECT 権限も必要です。論理バックアップ:SELECTSHOW VIEWREPLICATION SLAVE、および REPLICATION CLIENT(宛先および information_schema データベース)。
復元SELECTINSERTUPDATEDELETECREATEDROPINDEXALTERCREATE VIEWSHOW VIEWCREATE ROUTINEALTER ROUTINEEVENT、および TRIGGER
増分バックアップを実行する際、データディザスタリカバリは show binary logs 文を実行します。MySQL 5.5.24 以前では SUPER 権限が必要ですが、MySQL 5.5.25 以降では REPLICATION CLIENT 権限のみで十分です。
RDS データベースの場合、バックアップには読み取り専用権限で十分ですが、バックアップおよび復元には読み取り/書き込み権限が必要です。

SQL Server データベース

機能必要な権限
バックアップSELECT および VIEW DEFINITION
復元SELECTINSERTALTER DatabaseREFERENCES、および VIEW DEFINITION

PostgreSQL データベース

機能必要な権限
バックアップSELECT および SUPER
復元CREATEINSERTUSAGEREFERENCES、および TRIGGER

データディザスタリカバリは、復元されたデータの一貫性をどのように保証しますか?

  • 論理バックアップを使用した完全バックアップの場合、データディザスタリカバリはテーブルをロックせずに、ソースデータベースから並列でデータをプルし、OSS に書き込みます。これにより、パフォーマンスへの影響を最小限に抑えます。

  • データディザスタリカバリは、まず完全バックアップデータを復元し、その後増分ログバックアップデータを復元します。増分ログバックアップのべき等性により、一貫性が保証されます。

増分バックアップ復元データの一貫性
有効サポート
無効未サポート

バックアップセットのライフサイクルルールの管理

ライフサイクルルール

バックアップセットのライフサイクルは、7 日から 3,650 日(10 年)の範囲で設定できます。データディザスタリカバリは、バックアップスケジュールに3 つ以上の完全バックアップセットが含まれている場合にのみ、有効期限切れのバックアップセットを自動的に削除します。完全バックアップセットの数が 3 つ以下の場合、有効期限切れのバックアップセットは削除されません。

クリーンアップポリシーをトリガーするには、手動バックアップを実行するか、次のスケジュールバックアップまで待って、完全バックアップセットの数を 3 つ以上にしてください。「バックアップタスクの手動開始」をご参照ください。
完全バックアップセットを手動で削除して数が 3 つ以下になると、クリーンアップポリシーは停止します。増分バックアップセットは蓄積され続け、ストレージを占有します。増分バックアップを停止するには、手動で無効化してください。「増分ログバックアップの有効化または無効化」をご参照ください。
ライフサイクルルールの変更は、新規および既存のバックアップセットの両方に適用されます。

ライフサイクルルールの変更

バックアップスケジュールのバックアップポリシーの変更」または「バックアップスケジュールのライフサイクルの変更」をご参照ください。

その他の操作

バックアップサイズの確認またはバックアップ頻度の削減については、「バックアップセットの削除またはバックアップ頻度の削減」をご参照ください。

よくある質問

ライフサイクルの有効期限が切れてもバックアップセットが削除されないのはなぜですか?

クリーンアップポリシーは、バックアップスケジュールに 3 つ以上の完全バックアップセットがある場合にのみ実行されます。数が 3 つ以下の場合、ライフサイクル設定に関係なく、有効期限切れのバックアップセットは保持されます。

有効期限切れの増分バックアップが引き続きストレージを占有するのはなぜですか?

完全バックアップセットを手動で削除したため、数が 3 つ以下になっている可能性があります。クリーンアップポリシーが非アクティブなため、増分バックアップセットは無期限に蓄積されます。上記の「ライフサイクルルール」セクションをご参照ください。

バックアップデータサイズとは何ですか?

バックアップデータサイズとは、データディザスタリカバリサーバーを通過する実際のデータ量です。

基本概念

概念説明
データベースのディスク領域データベースが実行されているサーバー上のデータファイル、ログ、OS ファイル、および利用可能な OS 領域によって消費される合計領域。ApsaraDB RDS の場合、購入時に選択したストレージ容量です。ECS インスタンス上のデータベースの場合、システムディスクとデータディスクの合計ストレージです。
データファイルサイズデータベースデータファイルが占有するディスク領域。確認方法:ApsaraDB RDS の場合、インスタンス > 管理 > モニタリングとアラート > リソース監視 > ディスク領域 に移動し、チャートにカーソルを合わせて データ使用量 を表示します。Linux 上でホストされているデータベースの場合、データベースファイルディレクトリで du -sh を実行します。Windows 上でホストされているデータベースの場合、データベースファイルフォルダを開き、空白領域を右クリックして プロパティ を選択します。
バックアップデータサイズデータディザスタリカバリによってバックアップされるデータ量。データベースタイプ、バックアップモード、バックアップ粒度によって異なります。
ストレージデータサイズストレージシステムに保存されるデータ量。バックアップデータサイズ、ストレージフォーマット、圧縮アルゴリズムに依存します。

これらのサイズは、次の順序で大きいものから小さいものへと並びます:データベースのディスク領域 > データファイルサイズ > バックアップデータサイズ > ストレージデータサイズ。

バックアップデータサイズを削減するには、バックアップ粒度やバックアップサイクルなどの設定項目を調整してください。ストレージデータサイズを削減するには、コンパクトなストレージフォーマット、圧縮、および自動ダンプとクリーンアップポリシーを使用してください。

バックアップデータ量の確認

  1. バックアップスケジュールの 操作 列で、管理 をクリックします。

  2. スケジュール詳細ページの 課金情報 セクションで、バックアップデータ量を確認します。

image
フィールド説明
インスタンスタイプバックアップスケジュールタイプには、サーバーレス、マイクロ、スモール、ミディアム、ラージ、xlarge があります。「バックアップスケジュールタイプの選択」をご参照ください。
課金方法従量課金またはサブスクリプション。「料金」をご参照ください。
データ量の無料クォータ無料バックアップデータクォータ、単位価格、バックアップおよび復元パフォーマンスは、スケジュールタイプによって異なります。無料クォータを増やすには、バックアップスケジュールをスペックアップしてください。「バックアップスケジュールのスペックアップ」および「バックアップスケジュールタイプの選択」をご参照ください。
今月の課金対象データ量無料クォータを超えたデータ量。上位のスケジュールタイプほど、バックアップおよび復元パフォーマンスが高く、単位価格が低くなります。
今月の完全データバックアップ量当月の完全バックアップタスクのバックアップデータ量。
今月の増分データバックアップ量当月の増分バックアップタスクのバックアップデータ量。
集計期間バックアップデータ量は暦月ごとに計算されます。
作成日時バックアップスケジュールが作成された時刻。

バックアップソースデータベースの変更

使用タイミング

  • 元のバックアップソースデータベースが移行または廃止され、別のデータベースに切り替えたい場合。

  • テストが完了し、テストデータベースから本番データベースに切り替えたい場合。

  • データベースアカウントまたはパスワードが正しくない、またはアカウントに十分な権限がない場合。

  • バックアップソースのテーブルが変更され、バックアップオブジェクトを更新したい場合。

データベースアカウント、パスワード、またはバックアップオブジェクトの変更

前提条件

  • バックアップスケジュールは 論理バックアップ を使用していること。

  • データベースアカウントにバックアップおよび復元の権限があること。「データベースアカウントに必要な権限」セクションをご参照ください。

操作手順

  1. バックアップスケジュールを見つけ、操作 列の 管理 をクリックします。タスクの構成 ページが表示されます。

  2. 基本情報 セクションで、バックアップソースの編集 をクリックします。データベース固有の構成の詳細については、「バックアップスケジュールの構成とデータの復元」をご参照ください。

    image

  3. 新しいバックアップソース情報を入力します。接続テストに合格したら、次へ をクリックします。

    image

  4. バックアップするデータベースオブジェクトを構成し、保存 をクリックします。

    • データベースを追加するには、利用可能 セクションで選択し、image アイコンをクリックします。

    • データベースを削除するには、選択済み セクションで選択し、image アイコンをクリックします。

    image

  5. 事前チェックに合格したら、タスクの開始 をクリックします。新しいバックアップソースが有効になります。

    - 増分バックアップタスクが実行中の場合、タスクの開始 をクリックすると停止します。新しい認証情報を使って、新しい増分バックアップタスクが自動的に開始されます。 - 完全バックアップタスクが実行されていない場合、すぐに完全バックアップが開始されます。ソースデータベースへの影響を最小限に抑えるため、ピーク時以外の時間帯にこの操作を実行してください。 - 完全バックアップタスクがすでに実行中の場合、前の構成に基づいて完了します。更新された構成は、次のスケジュールまたは手動で開始された完全バックアップから有効になります。

バックアップオブジェクトのみの変更

  1. バックアップスケジュールを見つけ、操作 列の 管理 をクリックします。タスクの構成 ページが表示されます。

  2. 基本情報 セクションで、バックアップオブジェクトの編集 をクリックします。

    image

  3. バックアップオブジェクトを更新し、保存 をクリックします。

    • データベースを追加するには、利用可能 セクションで選択し、image アイコンをクリックします。

    • データベースを削除するには、選択済み セクションで選択し、image アイコンをクリックします。

    image

  4. 完全データバックアップの開始 ダイアログボックスで、OK または 閉じる をクリックします。

    • OK:更新されたバックアップオブジェクトの完全バックアップが約 1 分以内に開始されます。ソースデータベースへの影響を最小限に抑えるため、ピーク時以外の時間帯に実行してください。

    • 閉じる:更新された構成は保存されますが、即時のバックアップは実行されません。次のスケジュール完全バックアップで新しい構成が使用されます。

RDS インスタンスのクロスリージョンバックアップスケジュール

ApsaraDB RDS コンソールで ApsaraDB RDS for MySQL、ApsaraDB RDS for SQL Server、または ApsaraDB RDS for PostgreSQL インスタンスのクロスリージョンバックアップ機能を有効化すると、データディザスタリカバリは Express Connect を使用してインスタンスデータをリージョン間で転送およびバックアップします。データディザスタリカバリコンソールにバックアップスケジュールが自動的に作成されます。バックアップスケジュールの詳細ページで、ソースデータベースの詳細を確認できます。

クロスリージョンバックアップおよび課金の詳細については、以下をご参照ください。

よくある質問

クロスリージョンバックアップによって生成されたバックアップスケジュールを停止するにはどうすればよいですか?

ApsaraDB RDS コンソールでクロスリージョンバックアップ機能を無効化してください。データディザスタリカバリは、対応するバックアップスケジュールを自動的に停止します。

クロスリージョンバックアップを無効化した後も料金が発生するのはなぜですか?

クロスリージョンバックアップを無効化すると、新しいバックアップおよびリージョン間転送は停止します。ただし、既存のバックアップファイルは少なくとも 7 日間保持され、この期間中はストレージ料金が発生します。コストを最小限に抑えるには、保持期間を 7 日に設定してください。これにより、ファイルは自動的に削除されます。「クロスリージョンバックアップ機能の使用」をご参照ください。

このバックアップスケジュールの課金方法をサブスクリプションに切り替えることはできますか?

いいえ。クロスリージョンバックアップによって生成されたバックアップスケジュールは、デフォルトで従量課金を使用しており、サブスクリプションに切り替えることはできません。

クロスリージョンバックアップを無効化した後も、データディザスタリカバリコンソールにバックアップスケジュールが表示されるのはなぜですか?

バックアップスケジュールは参照用にコンソールに保持されますが、クロスリージョンバックアップを無効化した後は料金は発生しません。

バックアップによるデータベースパフォーマンスへの影響

データディザスタリカバリがバックアップタスクを実行すると、データベースパフォーマンスに影響します。バックアップタスクはピーク時以外の時間帯に実行してください。

物理バックアップ
項目論理バックアップ
完全バックアップデータディザスタリカバリは、すべてのテーブルにわたってデータを分割し、複数の並行スレッドで SQL 文を実行してデータを読み取ります。データベースサーバーにインストールされたバックアップゲートウェイがバックアップを実行します。
増分バックアップデータディザスタリカバリは、データベースのメモリから増分ログをリアルタイムでバックアップし、一度に大量のデータをバックアップすることで発生する急激な I/O の低下を防ぎます。
データベースへの影響データベースインスタンスからデータを読み取るため、パフォーマンスに影響します。テーブルはロックされません。データベースディスクからデータを読み取るため、I/O パフォーマンスに影響します。テーブルはロックされません。

MySQL バックアップの binlog_format の構成

データディザスタリカバリでは、増分バックアップを有効化し、信頼性の高いデータ復元を実現するために、binlog_format 変数を ROW に設定する必要があります。

適用タイミング

バックアップスケジュールの設定時の事前チェックステップで、binlog_formatROWに設定されていないというメッセージが表示されて事前チェックが失敗します。「サードパーティプロバイダーのオンプレミスデータベースまたはクラウドデータベースをバックアップする」をご参照ください。

注意事項

  • binlog_formatROW に設定してください。ROW モードでは、DML 操作によって影響を受ける行の変更前と変更後のイメージがログに記録されるため、正確なデータ復元が可能になります。

  • STATEMENT モードまたは MIXED モードは避けてください。ROW モードの方が安定性と信頼性に優れています。

  • binlog_formatROW に変更しても、バイナリログにのみ影響し、クエリパフォーマンスには影響しません。すべての接続に対して変更を有効にするには、既存のデータベース接続を終了させてください。

操作手順

  1. ソースデータベースの特権アカウントを使用して、次のコマンドを実行します。

    SET GLOBAL binlog_format = 'ROW';

    現在の値を確認するには:

    SHOW GLOBAL VARIABLES LIKE 'binlog_format';
  2. すべての既存のデータベース接続を終了させます。この手順を実行しないと、接続中のプロセスが非 ROW モードで書き込みを継続し、増分データが不整合になる可能性があります。

読み取り専用 ApsaraDB RDS for MySQL インスタンスのバックアップ

データディザスタリカバリは、読み取り専用 ApsaraDB RDS for MySQL インスタンスをパブリックエンドポイントまたは内部エンドポイントのいずれか経由でバックアップすることをサポートしています。

前提条件

  • バックアップスケジュールを購入済みであること。データソースタイプMySQL に、バックアップ方法論理バックアップ に設定して購入してください。「バックアップスケジュールの作成」をご参照ください。

  • 読み取り専用 ApsaraDB RDS for MySQL インスタンスが存在すること。「読み取り専用 ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。

  • 接続方法に応じて:

    • パブリックエンドポイント (方法 1):読み取り専用インスタンスのパブリックエンドポイントを取得済みであること。「インスタンスエンドポイントおよびポートの表示と管理」をご参照ください。データディザスタリカバリサーバーの CIDR ブロックをインスタンスのホワイトリストに追加済みであること。バックアップスケジュールの構成時に、データベースの場所パブリック IP アドレスを持つユーザー作成データベース \<IP アドレス:ポート番号\> に設定し、ホワイトリストの設定 をクリックして CIDR ブロックを取得してください。image

    • 内部エンドポイント (方法 2):ローカルデバイスで内部エンドポイントに対して ping を実行し、リアルタイムの内部 IP アドレスを取得済みであること。データディザスタリカバリサーバーの CIDR ブロックをインスタンスのホワイトリストに追加済みであること。バックアップスケジュールの構成時に、データベースの場所RDS インスタンス に設定し、ホワイトリストの設定 をクリックしてください。获取内网IP > 重要: この方法で取得した内部 IP アドレスはリアルタイム IP です。インスタンスをクローンしたり、別のゾーンに移行したり、VPC または vSwitch を変更したりすると、内部 IP が変更され、バックアップが失敗する可能性があります。image

注意事項

  • パブリックエンドポイントでのバックアップ:バイナリログに遅延が発生する可能性があります。読み取り専用インスタンスの バックアップと復元 ページで、保持期間 パラメーターをより大きな値に設定してください。デフォルトは 18 時間です。

    image

  • 内部エンドポイントでのバックアップ:読み取り専用インスタンスをクローンしたり、別のゾーンに移行したり、VPC または vSwitch を変更したりすると、リアルタイム内部 IP が変更される可能性があります。この場合、バックアップは失敗します。新しいリアルタイム IP を取得し、バックアップソースを再構成してください。「前提条件」セクションおよび「バックアップソースデータベースの変更」をご参照ください。

方法 1:パブリックエンドポイントを使用したバックアップ

  1. バックアップスケジュール ページで、バックアップスケジュールを見つけ、操作 列の バックアップスケジュールの構成 をクリックします。

    image.png

  2. バックアップソースと送信先の構成 ステップで、バックアップソースと送信先を構成し、次へ をクリックします。

    - データベースの場所パブリック IP アドレスを持つユーザー作成データベース \<IP アドレス:ポート番号\> に設定します。 - アドレス を読み取り専用インスタンスのパブリックエンドポイントに設定します。「インスタンスエンドポイントおよびポートの表示と管理」をご参照ください。 - その他のパラメーターについては、「バックアップスケジュールの管理」をご参照ください。
  3. バックアップオブジェクトの編集 ステップで、バックアップするデータベースまたはテーブルを 選択済み セクションに追加し、次へ をクリックします。

    - 論理バックアップでは、完全バックアップの対象として単一テーブル、単一データベース、複数データベース、またはインスタンス全体を指定できます。増分バックアップは、サポートされているデータベースタイプのすべての増分データを常にカバーします。データベース全体をバックアップするには、すべて選択 をクリックします。サポートされているタイプと粒度については、「サポートされているデータベースタイプと機能」をご参照ください。 - バックアップスケジュールの構成後に作成されたデータベースは、デフォルトではバックアップされません。バックアップオブジェクトの編集 ページで追加してください。「バックアップオブジェクトの変更」をご参照ください。 - 物理バックアップでは、データベースインスタンス全体をバックアップする必要があります。
  4. バックアップ時間の構成 ステップで、以下のパラメーターを構成し、次へ をクリックします。

    パラメーター説明
    完全バックアップ頻度定期バックアップ または 単一バックアップ。増分データを復元する必要があるシナリオでは、定期バックアップ を選択し、少なくとも週に 1 回は完全バックアップを実行してください。完全バックアップの回数が少ないと、復元時に再生する必要のあるバイナリログが多くなり、エラーのリスクが高まり、目標復旧時間 (RTO) が長くなります。
    完全データバックアップの繰り返し頻度完全バックアップ頻度定期バックアップ の場合に必須です。バックアップを実行する曜日を選択します。少なくとも 1 日を選択してください。
    開始時刻完全バックアップ頻度定期バックアップ の場合に必須です。ピーク時以外の時間帯(例:01:00)に設定してください。開始時刻に前の完全バックアップが完了していない場合、データディザスタリカバリは次の実行をスキップします。
    増分バックアップバイナリログを継続的にバックアップするには有効化してください。ソースデータベースでバイナリロギングが有効になっていることを確認してください。完全バックアップ頻度定期バックアップ の場合にのみ表示されます。ApsaraDB RDS for MySQL では、デフォルトでバイナリロギングが有効になっています。自己管理データベースでは、手動で構成する必要があります。
    完全データバックアップの最大並行スレッド数完全バックアップの最大並行スレッド数。データベースへの影響を最小限に抑えるには、この値を小さくしてください。
    バックアップネットワーク速度制限MB/s 単位のネットワーク帯域幅制限。デフォルト値 0 は制限なしを意味します。MySQL データベースでのみ表示されます。
  5. ライフサイクルの編集 ステップで、完全バックアップデータのライフサイクルを構成します。増分バックアップが有効になっている場合は、増分バックアップデータのライフサイクルも構成します。

  6. 右下隅の 事前チェック をクリックします。

  7. 事前チェック合格 と表示されたら、タスクの開始 をクリックします。

    - バックアップスケジュールの状態が 実行中 に変わると、スケジュールがアクティブになります。 - エラーが発生した場合は、すぐにトラブルシューティングを行ってください。「異常なバックアップスケジュールのエラー修正」をご参照ください。問題が解決しない場合は、DingTalk グループ (ID: 35585947) のテクニカルサポートにお問い合わせください。

方法 2:内部エンドポイントを使用したバックアップ

  1. バックアップスケジュール ページで、バックアップスケジュールを見つけ、操作 列の バックアップスケジュールの構成 をクリックします。

    image.png

  2. バックアップソースと送信先の構成 ステップで、バックアップソースと送信先を構成し、次へ をクリックします。

    - データベースの場所Express Connect DB/VPN Gateway/Intelligent Gateway に設定します。 - ピア VPC を読み取り専用インスタンスがデプロイされている VPC に設定します。 - アドレス をリアルタイム内部 IP アドレスに設定します。「前提条件」セクションをご参照ください。 - ポート番号 を読み取り専用インスタンスのポートに設定します。 - その他のパラメーターについては、「バックアップスケジュールの管理」をご参照ください。

    image

  3. バックアップオブジェクトの編集 ステップで、バックアップするデータベースまたはテーブルを 選択済み セクションに追加し、次へ をクリックします。

    - 論理バックアップでは、完全バックアップの対象として単一テーブル、単一データベース、複数データベース、またはインスタンス全体を指定できます。増分バックアップは、サポートされているデータベースタイプのすべての増分データを常にカバーします。データベース全体をバックアップするには、すべて選択 をクリックします。サポートされているタイプと粒度については、「サポートされているデータベースタイプと機能」をご参照ください。 - バックアップスケジュールの構成後に作成されたデータベースは、デフォルトではバックアップされません。バックアップオブジェクトの編集 ページで追加してください。「バックアップオブジェクトの変更」をご参照ください。 - 物理バックアップでは、データベースインスタンス全体をバックアップする必要があります。
  4. バックアップ時間の構成 ステップで、以下のパラメーターを構成し、次へ をクリックします。

    パラメーター説明
    完全バックアップ頻度定期バックアップ または 単一バックアップ。増分データを復元する必要があるシナリオでは、定期バックアップ を選択し、少なくとも週に 1 回は完全バックアップを実行してください。
    完全データバックアップの繰り返し頻度完全バックアップ頻度定期バックアップ の場合に必須です。バックアップを実行する曜日を選択します。少なくとも 1 日を選択してください。
    開始時刻完全バックアップ頻度定期バックアップ の場合に必須です。ピーク時以外の時間帯に設定してください。開始時刻に前の完全バックアップが完了していない場合、データディザスタリカバリは次の実行をスキップします。
    増分バックアップバイナリログを継続的にバックアップするには有効化してください。ソースデータベースでバイナリロギングが有効になっていることを確認してください。完全バックアップ頻度定期バックアップ の場合にのみ表示されます。
    完全データバックアップの最大並行スレッド数完全バックアップの最大並行スレッド数。データベースへの影響を最小限に抑えるには、この値を小さくしてください。
    バックアップネットワーク速度制限MB/s 単位のネットワーク帯域幅制限。デフォルト値 0 は制限なしを意味します。MySQL データベースでのみ表示されます。
  5. ライフサイクルの編集 ステップで、完全バックアップデータのライフサイクルを構成します。増分バックアップが有効になっている場合は、増分バックアップデータのライフサイクルも構成します。

  6. 右下隅の 事前チェック をクリックします。

  7. 事前チェック合格 と表示されたら、タスクの開始 をクリックします。

    - バックアップスケジュールの状態が 実行中 に変わると、スケジュールがアクティブになります。 - エラーが発生した場合は、すぐにトラブルシューティングを行ってください。「異常なバックアップスケジュールのエラー修正」をご参照ください。問題が解決しない場合は、DingTalk グループ (ID: 35585947) のテクニカルサポートにお問い合わせください。

内部エンドポイントおよびパブリックエンドポイントの取得

  1. インスタンス ページに移動します。RDS インスタンスが配置されているリージョンを選択し、インスタンス ID をクリックします。

  2. 基本情報 ページで、ネットワークタイプ パラメーターの横にある 詳細の表示 をクリックして、内部エンドポイントおよびパブリックエンドポイントを確認します。

    パブリックエンドポイントが存在しない場合は、パブリックエンドポイントの申請 > OK をクリックして申請してください。

    image

    image

よくある質問

内部エンドポイントを使用する際にソースインスタンスへの接続が失敗するのはなぜですか?

ping を実行して取得した内部 IP はリアルタイム IP です。読み取り専用インスタンスをクローンしたり、別のゾーンに移行したり、VPC または vSwitch を変更したりすると、この IP が変更され、バックアップ接続が切断される可能性があります。

これを修正するには、内部エンドポイントに対して再度 ping を実行して更新された IP を取得し、バックアップソースを再構成してください。「バックアップソースデータベースの変更」をご参照ください。

image

データディザスタリカバリは、読み取り専用インスタンスの完全データと増分データの両方をバックアップできますか?

はい。

データディザスタリカバリと RDS バックアップの違い

データディザスタリカバリRDS バックアップ
バックアップタイプダンプバックアップおよび論理バックアップ物理バックアップ
主なユースケースクロスリージョンバックアップおよび柔軟なバックアップ要件ローカルバックアップおよび高速復元

ダンプバックアップの価値

クロスリージョンバックアップ

  • データはセキュリティと安定性のために VPC 経由で転送されます。

  • RDS インスタンスの物理バックアップデータおよびログが、追加のバックアップを開始することなくダンプされます。

  • バックアップセットはワンクリックで RDS に復元できます。

  • バックアップセットは、RDS インスタンスがリリースされた後でも最大 5 年間保持できます。

  • ストレージは自動的にスケーリングされます。

柔軟なバックアップ

  • データディザスタリカバリは、コアテーブルをリアルタイムでバックアップし、目標復旧時点 (RPO) を秒単位で正確に実現します。データは任意の時点に復元できます。

  • 完全バックアップセットから個々のテーブルを復元できます。復元時間は実際のデータ量にのみ依存し、通常は数分以内です。

  • スキーママッピング機能により、追加のインスタンスを購入することなく、元のデータベースインスタンスにデータを復元できます。データベースおよびテーブルの名前を変更でき、オブジェクト名が競合する場合は、データディザスタリカバリが自動的に重複をリネームし、元のデータをそのまま保持します。

  • データディザスタリカバリは DMS と統合されています。DMS コンソールで セキュリティと仕様 (DBS) > データディザスタリカバリ (DBS) を選択してアクセスできます。

OSS に保存されたバックアップファイルの確認

ご利用の OSS バケットにデータをバックアップする場合、データディザスタリカバリはバケット内に自動的にバックアップフォルダを作成します。バックアップファイルは次の命名形式に従います:<バックアップスケジュール ID>/<バックアップタイプ>/<完全または増分バックアップタスク ID>/<特定のデータ>

  1. バックアップスケジュール ページで、バックアップスケジュールを見つけ、操作 列の 管理 をクリックします。

  2. タスクの構成 ページで、送信先 OSS バケット を見つけ、バケット名をクリックします。

    image

OSS コンソールのバケット詳細ページに移動します。バケットには、完全バックアップファイル用の full フォルダと、増分バックアップファイル用の continuous フォルダが含まれています。

image

OSS の詳細については、「OSS のクイックスタート」をご参照ください。

データディザスタリカバリコンソールと ApsaraDB RDS コンソールでバックアップ SQL ステートメントの時間が異なるのはなぜですか?

データディザスタリカバリは、論理バックアップ中にバックアップ SQL ステートメントを実行する際に UTC + 00:00 を使用します。一方、ApsaraDB RDS は同じ SQL ステートメントを SQL 監査ログに UTC + 08:00 で記録します。このため、2 つのコンソール間で 8 時間の差が生じます。データディザスタリカバリコンソールに表示される時間は、実際の実行時間を反映しています。