Amazon RDS Custom for SQL Server DB インスタンスのバックアップと復元 - Amazon Relational Database Service

Amazon RDS Custom for SQL Server DB インスタンスのバックアップと復元

Amazon RDS 同様、RDS Custom は、バックアップ保持が有効になっている場合に RDS Custom for SQL Server DB インスタンスの自動バックアップを作成して保存します。また、手動で DB インスタンスをバックアップすることもできます。自動バックアップは、スナップショットバックアップとトランザクションログバックアップで構成されます。スナップショットバックアップは、指定したバックアップウィンドウ中に DB インスタンスのストレージボリューム全体に対して実行されます。PITR の対象となるデータベースのトランザクションログのバックアップは、一定の間隔で実行されます。RDS Custom は、指定したバックアップ保持期間に従って DB インスタンスの自動バックアップを保存します。自動バックアップを使用して、バックアップの保持期間内の特定時点に DB インスタンスを復元できます。

スナップショットのバックアップを手動で作成することもできます。これらのスナップショットバックアップからいつでも新しい DB インスタンスを作成できます。DB スナップショットの手動作成について詳しくは、「RDS Custom for SQL Server スナップショットの作成」を参照してください。

スナップショットバックアップはフルバックアップとして機能しますが、課金はストレージの増分使用に対してのみ発生します。 RDS Custom DB インスタンスの初期のスナップショットには、フル DB インスタンスのデータが含まれています。同じ DB インスタンスの後続のスナップショットは増分です。つまり、直近のスナップショットの保存後に変更されたデータのみが含まれます。

RDS Custom for SQL Server スナップショットの作成

RDS Custom for SQL Server は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、DB インスタンス全体をバックアップします。スナップショットを作成するときに、バックアップする RDS Custom for SQL Server DB インスタンスを指定します。次に、スナップショットに名前を付けて、後でそこから復元できるようにします。

スナップショットを作成すると、RDS Custom for SQL Server は DB インスタンスにアタッチされたデータベースボリュームである、ボリューム (D:) の Amazon EBS スナップショットを作成します。特定の DB インスタンスと簡単に関連付けられるように、スナップショットには DBSnapshotIdentifierDbiResourceIdVolumeType のタグが付けられています。

DB スナップショットを作成すると、短時間の I/O が発生します。この一時停止は、DB インスタンスのサイズとクラスに応じて、数秒から数分続く場合があります。スナップショットの作成時間は、データベースの合計数とサイズによって異なります。ポイントインタイム復元 (PITR) オペレーションの対象となるデータベースの数の詳細については、「インスタンスクラスタイプごとに PITR の対象となるデータベースの数」を参照してください。

スナップショットにはストレージボリューム全体が含まれており、テンポラリファイルなどのファイルサイズも、スナップショットの作成時間に影響します。スナップショットの作成の詳細については、「シングル AZ DB インスタンスの DB スナップショットの作成」を参照してください。

コンソールまたはAWS CLIを使用して RDS Custom for SQL Server スナップショットを作成します。

RDS Custom スナップショットを作成するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで [データベース] を選択します。

  3. RDS Custom DB インスタンスのリストで、スナップショットを取得する DB インスタンスを選択します。

  4. アクション で、スナップショットの取得 を選択します。

    [Take DB snapshot] (DB スナップショットの取得) ウィンドウが表示されます。

  5. [スナップショット名] に、スナップショットの名前を入力します。

  6. スナップショットの取得 を選択します。

create-db-snapshot AWS CLIコマンドを使用して、RDS Custom DB インスタンスのスナップショットを作成します。

以下のオプションを指定します。

  • --db-instance-identifier - バックアップする RDS Custom DB インスタンスを指定します。

  • --db-snapshot-identifier - RDS Custom スナップショットに名前を付けて、後でそこから復元できるようにします。

この例では、my-custom-instance というRDS Custom DB インスタンスに、my-custom-snapshot という DB スナップショットを作成します。

Linux、macOS、Unix の場合:

aws rds create-db-snapshot \ --db-instance-identifier my-custom-instance \ --db-snapshot-identifier my-custom-snapshot

Windows の場合:

aws rds create-db-snapshot ^ --db-instance-identifier my-custom-instance ^ --db-snapshot-identifier my-custom-snapshot

RDS Custom for SQL Server DB スナップショットからの復元

RDS Custom for SQL Server DB インスタンスを復元するときは、DB スナップショットの名前と新しいインスタンスの名前を指定します。スナップショットから既存の RDS Custom DB インスタンスに復元することはできません。復元するときに新しい RDS Custom for SQL Server DB インスタンスが作成されます。

スナップショットから復元すると、スナップショットが作成された時点までストレージボリュームが復元されます。これには、すべてのデータベースと、(D:) ボリュームに存在していた他のファイルが含まれます。

DB スナップショットから RDS Custom DB インスタンスを復元するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Snapshots] を選択します。

  3. 復元の元にする DB スナップショットを選択します。

  4. [アクション] で、[スナップショットの復元] を選択します。

  5. DB インスタンスの復元 ページで、DB インスタンス識別子 に、復元した RDS Custom DB インスタンスの名前を入力します。

  6. DB インスタンスの復元 を選択します。

RDS Custom DB スナップショットを復元するには、DBスナップショットからDBインスタンスを復元する AWS CLI コマンドを使用します。

復元元のスナップショットがプライベート DB インスタンスの場合、db-subnet-group-nameno-publicly-accessible の両方を正しく指定してください。そうでなければ、DB インスタンスはデフォルトでパブリックアクセスに設定されます。以下のオプションは必須です。

  • db-snapshot-identifier - 復元元のスナップショットを識別します。

  • db-instance-identifier - DB スナップショットから作成する RDS Custom DB インスタンスの名前を指定します。

  • custom-iam-instance-profile — RDS Custom DB インスタンスの基盤となる Amazon EC2 インスタンスに関連付けられているインスタンスプロファイルを指定します。

次のコードは、my-custom-instancemy-custom-snapshot という名前のスナップショットを復元します。

Linux、macOS、Unix の場合:

aws rds restore-db-instance-from-db-snapshot \ --db-snapshot-identifier my-custom-snapshot \ --db-instance-identifier my-custom-instance \ --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \ --no-publicly-accessible

Windows の場合:

aws rds restore-db-instance-from-db-snapshot ^ --db-snapshot-identifier my-custom-snapshot ^ --db-instance-identifier my-custom-instance ^ --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^ --no-publicly-accessible

RDS Custom for SQL Server インスタンスをポイントインタイムに復元する

DB インスタンスを特定の時点に復元し (PITR)、新しい DB インスタンスを作成できます。PITR をサポートするには、DB インスタンスのバックアップ保持が有効になっている必要があります。

RDS Custom for SQL Server DB インスタンスの最新の復元可能時間はいくつかの要因によって異なりますが、通常は現在時間から 5 分以内です。DB インスタンスの復元可能な直近の時間を確認するには、AWS CLI の describe-db-instances コマンドを使用し、DB インスタンスの [LatestRestorableTime] フィールドに返される値を確認します。Amazon RDS コンソールで各 DB インスタンスの復元可能な直近の時間を表示するには、[自動バックアップ] をクリックします。

バックアップ保持期間の任意の時点に復元できます。各 DB インスタンスの復元可能な最も早い時間を表示するには、Amazon RDS コンソールで [自動バックアップ] をクリックします。

PITR の一般情報については、「特定の時点への DB インスタンスの復元」を参照してください。

RDS Custom for SQL Serverの PITR に関する考慮事項

RDS Custom for SQL Serverでは、PITR は Amazon RDS の PITR と以下の重要な点で異なります。

  • PITR は DB インスタンス内のデータベースのみを復元します。C: ドライブ上のオペレーティングシステムやファイルは復元されません。

  • RDS Custom for SQL Server DB インスタンスの場合、データベースは自動的にバックアップされ、次の条件下でのみ PITR の対象となります。

    • データベースはオンラインです。

    • その回復モデルはFULLに設定されています。

    • 書き込み可能です。

    • D: ドライブに物理ファイルがあります。

    • rds_pitr_blocked_databasesテーブルには記載されていません。詳細については、「データベースを PITR の対象外にする」を参照してください。

  • PITR の対象となるデータベースは、データベース ID の順序によって決まります。RDS Custom for SQL Server では、DB インスタンスごとに最大 5,000 のデータベースを扱えます。ただし、RDS Custom for SQL Server DB インスタンスの PITR オペレーションで復元されるデータベースの最大数は、インスタンスクラスタイプによって異なります。詳細については、「インスタンスクラスタイプごとに PITR の対象となるデータベースの数」を参照してください。

    PITR には含まれない他のデータベースは、PITR で使用される自動スナップショットバックアップを含め、DB スナップショットから復元できます。

  • 新しいデータベースの追加、データベースの名前変更、または PITR の対象となるデータベースの復元を行うと、DB インスタンスのスナップショットがスタートされます。

  • PITR の対象となるデータベースの最大数は、ターゲットのインスタンスクラスタイプに応じて、データベースインスタンスでスケールコンピューティングオペレーションが実行される場合に変化します。インスタンスがスケールアップされ、インスタンス上のより多くのデータベースが PITR の対象になると、新しいスナップショットが作成されます。

  • 復元されたデータベースの名前は、出典 DB インスタンスと同じです。必要に応じて、別の名前を指定できます。

  • AWSRDSCustomSQLServerIamRolePolicy は、他の AWS サービスへのアクセスを必要とします。詳細については、「AWSRDSCustomsqlServerInstanceRole にアクセスポリシーを追加します。」を参照してください。

  • タイムゾーンの変更は、 RDS Custom for SQL Server ではサポートされていません。OSまたは DB インスタンスのタイムゾーンを変更すると、PITR (およびその他のオートメーション) は機能しません。

インスタンスクラスタイプごとに PITR の対象となるデータベースの数

次の表は、インスタンスクラスタイプに基づいて PITR の対象となるデータベースの最大数を示しています。

インスタンスクラスのタイプ PITR 対象のデータベースの最大数
db.*.large 100
db.*.xlarge〜db.*.2xlarge 150
db.*.4xlarge〜db.*.8xlarge 300
db.*.12xlarge〜db.*.16xlarge 600
db.*.24xlarge、db.*32xlarge 1,000

* さまざまなインスタンスクラスタイプを表します。

1 つの DB インスタンスで PITR の対象となるデータベースの最大数は、インスタンスクラスタイプによって異なります。数値の範囲は、RDS Custom for SQL Server でサポートされる最小のインスタンスクラスタイプで 100、最大のインスタンスクラスタイプで 1000 に及びます。SQL Server システムデータベース (master, model, msdb, tempdb) は、この制限には含まれていません。ターゲットインスタンスクラスタイプに応じて DB インスタンスがスケールアップ/スケールダウンされると、RDS Custom は PITR の対象となるデータベースの数を自動的に更新します。RDS Custom for SQL Server は、DB インスタンスで PITR の対象となるデータベースの最大数が変更されると RDS-EVENT-0352 を送信します。詳細については、「カスタムエンジンバージョンイベント」を参照してください。

注記

100 を超えるデータベースの PITR サポートは、2023 年 8 月 26 日以降に作成された DB インスタンスでのみ使用できます。2023 年 8 月 26 日より前に作成されたインスタンスの場合、PITR の対象となるデータベースの最大数は、インスタンスクラスに関係なく 100 です。2023 年 8 月 26 日より前に作成された DB インスタンスで 100 を超えるデータベースの PITR サポートを有効にするには、次のアクションを実行できます。

  • DB エンジンバージョンを 15.00.4322.2.v1 以降にアップグレードする

PITR オペレーション中、RDS Custom は復元時にソース DB インスタンスの PITR に含まれていたすべてのデータベースを復元します。ターゲット DB インスタンスが復元オペレーションを完了すると、バックアップ保持が有効になっている場合は、ターゲット DB インスタンスで PITR の対象となるデータベースの最大数に基づいて DB インスタンスのバックアップが開始されます。

例えば、DB インスタンスが 200 個のデータベースを持つ db.*.xlarge で実行されている場合:

  1. RDS Custom for SQL Server は、PITR バックアップ用に、データベース ID 順に最初の 150 個のデータベースを選択します。

  2. インスタンスを変更して db.*.4xlarge にスケールアップします。

  3. スケールコンピューティングオペレーションが完了すると、RDS Custom for SQL Server は PITR バックアップ用に、データベース ID 順に最初の 300 個のデータベースを選択します。PITR の要件を満たす 200 個のデータベースのそれぞれが PITR の対象になります。

  4. 次に、インスタンスを変更して db.*.xlarge にスケールダウンします。

  5. スケールコンピューティングオペレーションが完了すると、RDS Custom for SQL Server は、PITR バックアップ用に、データベース ID 順に最初の 150 個のデータベースを再び選択します。

データベースを PITR の対象外にする

個々のデータベースを PITR から除外することもできます。これには、database_id値をrds_pitr_blocked_databasesテーブルに入力します。以下のSQLスクリプトを使用してテーブルを作成します。

rds_pitr_blocked_databases テーブルを作成するには
  • 次のSQLスクリプトを実行します。

    create table msdb..rds_pitr_blocked_databases ( database_id INT NOT NULL, database_name SYSNAME NOT NULL, db_entry_updated_date datetime NOT NULL DEFAULT GETDATE(), db_entry_updated_by SYSNAME NOT NULL DEFAULT CURRENT_USER, PRIMARY KEY (database_id) );

対象となるデータベースと対象とならないデータベースの一覧は、Amazon S3 バケットdo-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier内のRDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadataディレクトリにあるRI.Endファイルを参照してください。RI.End ファイルの詳細については、「Amazon S3 のトランザクションログ」を参照してください。

次の SQL スクリプトを使用して、PITR の対象となるデータベースのリストを確認することもできます。@limit 変数を、インスタンスクラスで PITR の対象となるデータベースの最大数に設定します。詳細については、「インスタンスクラスタイプごとに PITR の対象となるデータベースの数」を参照してください。

DB インスタンスクラスで PITR の対象となるデータベースのリストを確認するには
  • 次のSQLスクリプトを実行します。

    DECLARE @Limit INT; SET @Limit = (insert-database-instance-limit-here); USE msdb; IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'rds_pitr_blocked_databases')) WITH TABLE0 AS ( SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable FROM sys.dm_hadr_database_replica_states hdrs INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY') ), TABLE1 as ( SELECT dbs.database_id as DatabaseId, sysdbs.name as DatabaseName, 'OPTOUT' as Reason, CASE WHEN dbs.database_name = sysdbs.name THEN NULL ELSE dbs.database_name END AS DatabaseNameOnPitrTable FROM msdb.dbo.rds_pitr_blocked_databases dbs INNER JOIN sys.databases sysdbs ON dbs.database_id = sysdbs.database_id WHERE sysdbs.database_id > 4 ), TABLE2 as ( SELECT db.name AS DatabaseName, db.create_date AS CreateDate, db.state_desc AS DatabaseState, db.database_id AS DatabaseId, rs.database_guid AS DatabaseGuid, rs.last_log_backup_lsn AS LastLogBackupLSN, rs.recovery_fork_guid RecoveryForkGuid, rs.first_recovery_fork_guid AS FirstRecoveryForkGuid, db.recovery_model_desc AS RecoveryModel, db.is_auto_close_on AS IsAutoClose, db.is_read_only as IsReadOnly, NEWID() as FileName, CASE WHEN(db.state_desc = 'ONLINE' AND db.recovery_model_desc != 'SIMPLE' AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) AND db.is_read_only != 1 AND db.user_access = 0 AND db.source_database_id IS NULL AND db.is_in_standby != 1 THEN 1 ELSE 0 END AS IsPartOfSnapshot, CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot FROM sys.databases db INNER JOIN sys.database_recovery_status rs ON db.database_id = rs.database_id WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE1) AND db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0) ), TABLE3 as( Select @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE2 where TABLE2.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb') ) SELECT TOP(SELECT TotalNumberOfDatabases from TABLE3) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE2 where TABLE2.IsPartOfSnapshot=1 ORDER BY TABLE2.DatabaseID ASC ELSE WITH TABLE0 AS ( SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable FROM sys.dm_hadr_database_replica_states hdrs INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY') ), TABLE1 as ( SELECT db.name AS DatabaseName, db.create_date AS CreateDate, db.state_desc AS DatabaseState, db.database_id AS DatabaseId, rs.database_guid AS DatabaseGuid, rs.last_log_backup_lsn AS LastLogBackupLSN, rs.recovery_fork_guid RecoveryForkGuid, rs.first_recovery_fork_guid AS FirstRecoveryForkGuid, db.recovery_model_desc AS RecoveryModel, db.is_auto_close_on AS IsAutoClose, db.is_read_only as IsReadOnly, NEWID() as FileName, CASE WHEN(db.state_desc = 'ONLINE' AND db.recovery_model_desc != 'SIMPLE' AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) AND db.is_read_only != 1 AND db.user_access = 0 AND db.source_database_id IS NULL AND db.is_in_standby != 1 THEN 1 ELSE 0 END AS IsPartOfSnapshot, CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot FROM sys.databases db INNER JOIN sys.database_recovery_status rs ON db.database_id = rs.database_id WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0) ), TABLE2 as( SELECT @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE1 where TABLE1.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb') ) select top(select TotalNumberOfDatabases from TABLE2) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE1 where TABLE1.IsPartOfSnapshot=1 ORDER BY TABLE1.DatabaseID ASC
注記

シンボリックリンクのみのデータベースも、PITR オペレーションの対象となるデータベースから除外されます。上記のクエリでは、この基準に基づいてフィルタリングされません。

Amazon S3 のトランザクションログ

バックアップ保持期間は、RDS Custom for SQL Server DB インスタンスのトランザクションログが自動的に抽出され、Amazon S3 にアップロードされるかどうかを決定します。ゼロ以外の値は、自動バックアップが作成され、RDS Custom エージェントが 5 分ごとにトランザクションログを S3 にアップロードすることを意味します。

S3 上のトランザクションログファイルは、AWS KMS keyDB インスタンス作成時に提供したものを使って、静止時に暗号化されます。詳細については、「Amazon Simple Storage Service ユーザーガイド」の「サーバー側の暗号化を使用したデータの保護」を参照してください。

各データベースのトランザクションログは、do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifierという名前の S3 バケットにアップロードされます。S3 バケットのRDSCustomForSQLServer/Instances/DB_instance_resource_IDディレクトリには、2 つのサブディレクトリが含まれます。

  • TransactionLogs - 各データベースのトランザクションログとそれぞれのメタデータが含まれます。

    トランザクションログファイル名は、例えばyyyyMMddHHmm.database_id.timestampというパターンに従っています。

    202110202230.11.1634769287

    同じファイル名でサフィックスが_metadataのものには、ログシーケンス番号、データベース名、RdsChunkCountなどのトランザクションログに関する情報が含まれます。RdsChunkCountは、1つのトランザクションログファイルを表す物理ファイルの数を決定します。_0001_0002などのサフィックスを持つファイルがありますが、これはトランザクションログファイルの物理的チャンクを意味します。チャンクされたトランザクションログファイルを使用する場合は、ダウンロード後にチャンクの結合を必ず行ってください。

    以下のファイルがある場合を考えてみましょう。

    • 202110202230.11.1634769287

    • 202110202230.11.1634769287_0001

    • 202110202230.11.1634769287_0002

    • 202110202230.11.1634769287_metadata

    RdsChunkCount は、3 です。ファイルをマージする順序は202110202230.11.1634769287 202110202230.11.1634769287_0001202110202230.11.1634769287_0002です。

  • TransactionLogMetadata - トランザクションログ抽出の各反復処理についてのメタデータ情報が含まれます。

    RI.Endファイルには、トランザクションログが抽出されたすべてのデータベース、存在するがトランザクションログが抽出されていないすべてのデータベースについての情報が含まれます。RI.Endファイル名はパターンyyyyMMddHHmm.RI.End.timestampに従います。例えば、

    202110202230.RI.End.1634769281

AWS Management Console、AWS CLI、または RDS API を使用した PITR 復元

AWS Management Console、AWS CLI、またはRDS API を使用して、 RDS Custom for SQL Server DB インスタンスをあるポイントに復元することができます。

特定の時点に RDS Custom DB インスタンスを復元するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、「自動バックアップ」を選択します。

  3. 復元する RDS Custom DB インスタンスを選択します。

  4. アクション」 で、「特定時点への復元」 を選択します。

    [特定時点への復元] ウィンドウが表示されます。

  5. Latest restorable time」 を選択してできるだけ最新の時点に復元するか、「カスタム」 を選択して時刻を選択します。

    カスタム」 を選択した場合、インスタンスクラスターを復元する日時を入力します。

    時刻は、協定世界時 (UTC) からのオフセットとしてローカルタイムゾーンで表示されます。例えば、UTC-5 は東部スタンダード時/中部夏時間です。

  6. DB インスタンス識別子」 に、ターゲットが復元された RDS Custom DB インスタンスの名前を入力します。名前は一意である必要があります。

  7. 必要に応じて、DB インスタンスクラスなどの他のオプションを選択します。

  8. [Restore to point in time] (特定時点への復元) を選択します。

特定のポイントに DB インスタンスを復元するには、restore-db-instance-to-point-in-time AWS CLIコマンドを使用して、RDS Custom DB インスタンスを作成します。

次のいずれかのオプションを使用して、復元元のバックアップを指定します。

  • --source-db-instance-identifier mysourcedbinstance

  • --source-dbi-resource-id dbinstanceresourceID

  • --source-db-instance-automated-backups-arn backupARN

custom-iam-instance-profile オプションは必須です。

次の例は、指定された時刻に my-custom-db-instancemy-restored-custom-db-instance という新しい DB インスタンスに復元します。

Linux、macOS、Unix の場合:

aws rds restore-db-instance-to-point-in-time \ --source-db-instance-identifier my-custom-db-instance\ --target-db-instance-identifier my-restored-custom-db-instance \ --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \ --restore-time 2022-10-14T23:45:00.000Z

Windows の場合:

aws rds restore-db-instance-to-point-in-time ^ --source-db-instance-identifier my-custom-db-instance ^ --target-db-instance-identifier my-restored-custom-db-instance ^ --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^ --restore-time 2022-10-14T23:45:00.000Z

RDS Custom for SQL Server スナップショットの削除

RDS Custom for SQL Server で管理しているDBスナップショットは、不要になったら削除することができます。削除手順は、Amazon RDS および RDS Custom DB インスタンスのどちらでも同じです。

バイナリボリュームとルートボリュームの Amazon EBS スナップショットは、アカウントで実行されているいくつかのインスタンスや、他の RDS Custom for SQL Server スナップショットにリンクされている可能性があるため、長期間アカウントに残ります。これらの EBS スナップショットは、既存の RDS Custom for SQL Server リソース (DB インスタンスまたはバックアップ) に関連しなくなった後に自動的に削除されます。

RDS Custom DB インスタンスのスナップショットを削除するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、「Snapshots」 を選択します。

  3. 削除する DB スナップショットを選択します。

  4. アクション」 で、「スナップショットの削除」 を選択します。

  5. 確認ページで、「削除」 を選択します。

RDS Custom スナップショットを削除するには、AWS CLIコマンドdelete-db-snapshotを使用します。

以下のような必須オプションがあります。

  • --db-snapshot-identifier - 削除するスナップショット

以下の例では、DB スナップショット my-custom-snapshot を削除します。

Linux、macOS、Unix の場合:

aws rds delete-db-snapshot \ --db-snapshot-identifier my-custom-snapshot

Windows の場合:

aws rds delete-db-snapshot ^ --db-snapshot-identifier my-custom-snapshot

RDS Custom for SQL Server 自動バックアップの削除

RDS Custom for SQL Server の保持された自動バックアップは、不要になったら削除できます。手順は、Amazon RDS バックアップの削除と同じです。

保持されている自動バックアップを削除するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Automated backups] (自動バックアップ) を選択します。

  3. [Retained] (保持) を選択します。

  4. 削除する保持された自動バックアップを選択します。

  5. アクション」 で、「削除」 を選択します。

  6. 確認ページで、delete me を入力し、[Delete] (削除) を選択します。

AWS CLI コマンド delete-db-instance-automated-backup を使用して、保持されている自動バックアップを削除できます。

保持されている自動バックアップを削除するには、以下のオプションを使用します。

  • --dbi-resource-id - 出典 RDS Custom DB インスタンスのリソース識別子です。

    AWS CLI コマンド describe-db-instance-automated-backups を使用すると、保持された自動バックアップの出典 DB インスタンスのリソース識別子を見つけることができます。

次の例では、ソース DB インスタンスのリソース識別子 custom-db-123ABCEXAMPLE を持つ保持された自動バックアップを削除します。

Linux、macOS、Unix の場合:

aws rds delete-db-instance-automated-backup \ --dbi-resource-id custom-db-123ABCEXAMPLE

Windows の場合:

aws rds delete-db-instance-automated-backup ^ --dbi-resource-id custom-db-123ABCEXAMPLE