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 の一般情報については、「Amazon RDS の 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 | 1000 |
*
さまざまなインスタンスクラスタイプを表します。
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
で実行されている場合:
RDS Custom for SQL Server は、PITR バックアップ用に、データベース ID 順に最初の 150 個のデータベースを選択します。
インスタンスを変更して db.*.4xlarge にスケールアップします。
スケールコンピューティングオペレーションが完了すると、RDS Custom for SQL Server は PITR バックアップ用に、データベース ID 順に最初の 300 個のデータベースを選択します。PITR の要件を満たす 200 個のデータベースのそれぞれが PITR の対象になります。
次に、インスタンスを変更して db.*.xlarge にスケールダウンします。
スケールコンピューティングオペレーションが完了すると、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
/TransactionLogMetadataRI.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-
という名前の S3 バケットにアップロードされます。S3 バケットの$ACCOUNT_ID
-$REGION
-unique_identifier
RDSCustomForSQLServer/Instances/
ディレクトリには、2 つのサブディレクトリが含まれます。DB_instance_resource_ID
-
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_0001
、202110202230.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 インスタンスを復元するには
AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/
を開きます。 -
ナビゲーションペインで、「自動バックアップ」を選択します。
-
復元する RDS Custom DB インスタンスを選択します。
-
「アクション」 で、「特定時点への復元」 を選択します。
[特定時点への復元] ウィンドウが表示されます。
-
「Latest restorable time」 を選択してできるだけ最新の時点に復元するか、「カスタム」 を選択して時刻を選択します。
「カスタム」 を選択した場合、インスタンスクラスターを復元する日時を入力します。
時刻は、協定世界時 (UTC) からのオフセットとしてローカルタイムゾーンで表示されます。例えば、UTC-5 は東部スタンダード時/中部夏時間です。
-
「DB インスタンス識別子」 に、ターゲットが復元された RDS Custom DB インスタンスの名前を入力します。名前は一意である必要があります。
-
必要に応じて、DB インスタンスクラスなどの他のオプションを選択します。
-
[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-instance
を my-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-identifiermy-restored-custom-db-instance
\ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance
\ --restore-time2022-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-identifiermy-restored-custom-db-instance
^ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance
^ --restore-time2022-10-14T23:45:00.000Z