Restauration d'une instance de RDS Custom for SQL Server à un point dans le temps - Amazon Relational Database Service

Restauration d'une instance de RDS Custom for SQL Server à un point dans le temps

Vous pouvez restaurer une instance de base de données à un point donné dans le temps (PITR), et créer ainsi une nouvelle instance de base de données. Pour prendre en charge le PITR, la rétention des sauvegardes de vos instances de base de données doit être activée.

La dernière date de restauration d'une instance de base de données RDS Custom for SQL Server dépend de plusieurs facteurs, mais se situe généralement dans les cinq minutes qui précèdent l'heure actuelle. Pour afficher l’heure de restauration la plus récente pour une instance de base de données, utilisez la commande describe-db-instances de la AWS CLI et examinez la valeur retournée dans le champ LatestRestorableTime de l’instance de base de données. Pour afficher l'heure de restauration la plus récente pour chaque instance de base de données dans la console Amazon RDS, choisissez Automated backups (Sauvegardes automatisées).

Vous pouvez procéder à une restauration à n'importe quel moment dans le passé au cours de la période de rétention des sauvegardes. Pour afficher l’heure de restauration la plus ancienne pour chaque instance de base de données, choisissez Automated backups (Sauvegardes automatisées) dans la console Amazon RDS.

Pour obtenir des informations générales sur le PITR, consultez Restauration d’une instance de base de données à un instant précis pour Amazon RDS.

Considérations PITR pour RDS Custom for SQL Server

Dans RDS Custom for SQL Server, le PITR diffère de la manière suivante du PITR dans Amazon RDS :

  • Le PITR restaure uniquement les bases de données de l'instance de base de données. Il ne restaure pas le système d'exploitation ou les fichiers du lecteur C:.

  • Pour une instance de base de données RDS Custom for SQL Server, une base de données est automatiquement sauvegardée et n'est éligible au PITR que dans les conditions suivantes :

    • La base de données est en ligne.

    • Son modèle de récupération est défini sur FULL.

    • Elle est inscriptible.

    • Ses fichiers physiques sont sur le lecteur D:.

    • Elle n'est pas répertoriée dans le tableau rds_pitr_blocked_databases. Pour plus d’informations, consultez Rendre les bases de données inéligibles au PITR.

  • Les bases de données éligibles au PITR sont déterminées par l’ordre de leur ID de base de données. RDS Custom for SQL Server autorise jusqu'à 5 000 bases de données par instance de base de données. Toutefois, le nombre maximal de bases de données restaurées par une opération de PITR pour une instance de base de données RDS Custom for SQL Server dépend du type de classe d’instance. Pour plus d’informations, consultez Nombre de bases de données éligibles au PITR par type de classe d’instance.

    Les autres bases de données qui ne font pas partie du PITR peuvent être restaurées à partir d’instantanés de base de données, y compris les sauvegardes d’instantanés automatiques utilisées pour le PITR.

  • L'ajout d'une nouvelle base de données, le changement de nom d'une base de données ou la restauration d'une base de données éligible au PITR déclenche un instantané de l'instance de base de données.

  • Le nombre maximum de bases de données éligibles au PITR change lorsque l’instance de base de données est soumise à une opération de calcul à l’échelle, en fonction du type de classe d’instance cible. Si l’instance augmente verticalement, permettant à un plus grand nombre de bases de données de l’instance d’être éligibles au PITR, un nouvel instantané est pris.

  • Les bases de données restaurées portent le même nom que dans l'instance de base de données source. Vous ne pouvez pas spécifier un autre nom.

  • AWSRDSCustomSQLServerIamRolePolicy nécessite l’accès à d’autres services AWS. Pour plus d’informations, consultez Ajout d'une stratégie d'accès à AWSRDSCustomSQLServerInstanceRole.

  • Les modifications de fuseau horaire ne sont pas prises en charge pour RDS Custom for SQL Server. Si vous modifiez le fuseau horaire du système d'exploitation ou de l'instance de base de données, le PITR (et toute autre automatisation) ne fonctionne pas.

Nombre de bases de données éligibles au PITR par type de classe d’instance

Le tableau suivant indique le nombre maximal de bases de données éligibles au PITR en fonction du type de classe d’instance.

Type de classe d’instance Nombre maximal de bases de données éligibles au 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

* Représente les différents types de classes d’instance.

Le nombre maximum de bases de données éligibles au PITR sur une instance de base de données dépend du type de classe d’instance. Ce nombre est compris entre 100 pour les plus petits et 1 000 pour les types de classes d’instance les plus importants pris en charge par RDS Custom for SQL Server. Les bases de données système SQL Server (master, model, msdb, tempdb) ne sont pas incluses dans cette limite. Lorsqu’une instance de base de données est augmentée ou réduite verticalement, selon le type de classe d’instance cible, RDS Custom met automatiquement à jour le nombre de bases de données éligibles au PITR. RDS Custom for SQL Server envoie RDS-EVENT-0352 lorsque le nombre maximal de bases de données éligibles au PITR change sur une instance de base de données. Pour plus d’informations, consultez Événements de version du moteur personnalisés.

Note

La prise en charge du PITR pour plus de 100 bases de données n’est disponible que sur les instances de base de données créées après le 26 août 2023. Pour les instances créées avant le 26 août 2023, le nombre maximum de bases de données éligibles au PITR est de 100, quelle que soit la classe d’instance. Pour activer la prise en charge du PITR pour plus de 100 bases de données sur des instances de base de données créées avant le 26 août 2023, vous pouvez effectuer l’action suivante :

  • Mettre à niveau la version du moteur de base de données vers la version 15.00.4322.2.v1 ou supérieure

Au cours d’une opération de PITR, RDS Custom restaure toutes les bases de données qui faisaient partie du PITR sur l’instance de base de données source au moment de la restauration. Une fois que l’instance de base de données cible a terminé les opérations de restauration, si la rétention des sauvegardes est activée, l’instance de base de données commence à sauvegarder en fonction du nombre maximum de bases de données éligibles au PITR sur l’instance de base de données cible.

Par exemple, si votre instance de base de données s’exécute sur une db.*.xlarge contenant 200 bases de données :

  1. RDS Custom for SQL Server choisira les 150 premières bases de données, classées par ID de base de données, pour la sauvegarde PITR.

  2. Vous modifiez l’instance pour l’augmenter verticalement jusqu’à db.*.4xlarge.

  3. Une fois l’opération de calcul de l’échelle terminée, RDS Custom for SQL Server choisira les 300 premières bases de données, classées par ID de base de données, pour la sauvegarde du PITR. Chacune des 200 bases de données répondant aux exigences du PITR sera désormais éligible au PITR.

  4. Vous modifiez maintenant l’instance pour la réduire verticalement jusqu’à db.*.xlarge.

  5. Une fois l’opération de calcul de l’échelle terminée, RDS Custom for SQL Server sélectionnera à nouveau les 150 premières bases de données, classées par ID de base de données, pour la sauvegarde du PITR.

Rendre les bases de données inéligibles au PITR

Vous pouvez choisir d’exclure des bases de données individuelles du PITR. Pour ce faire, mettez leurs valeurs database_id dans un tableau rds_pitr_blocked_databases. Utilisez le script SQL suivant pour créer la table.

Pour créer la table rds_pitr_blocked_databases
  • Exécutez le script SQL suivant.

    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) );

Pour obtenir la liste des bases de données éligibles et non éligibles, consultez le fichier RI.Enddans le répertoire RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata du compartiment Amazon S3 do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. Pour plus d'informations sur le fichier RI.End, consultez Journaux de transactions dans Amazon S3.

Vous pouvez également déterminer la liste des bases de données éligibles au PITR à l’aide du script SQL suivant. Définissez la variable @limit sur le nombre maximum de bases de données éligibles au PITR pour la classe d’instance. Pour plus d’informations, consultez Nombre de bases de données éligibles au PITR par type de classe d’instance.

Définition de la liste des bases de données éligibles au PITR sur une classe d’instance de base de données
  • Exécutez le script SQL suivant.

    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
Note

Les bases de données qui ne sont que des liens symboliques sont également exclues des bases de données éligibles aux opérations du PITR. La requête ci-dessus ne filtre pas en fonction de ces critères.

Journaux de transactions dans Amazon S3

La période de rétention des sauvegardes détermine si les journaux de transactions pour les instances de base de données RDS Custom for SQL Server sont automatiquement extraits et chargés dans Amazon S3. Une valeur non nulle signifie que des sauvegardes automatiques sont créées et que l'agent RDS Custom charge les journaux de transactions dans S3 toutes les 5 minutes.

Les journaux des transactions sur S3 sont chiffrés au repos à l'aide de la AWS KMS key que vous avez fournie lors de la création de votre instance de base de données. Pour plus d’informations, consultez Protection des données à l’aide du chiffrement côté serveur dans le Guide de l’utilisateur Amazon Simple Storage Service.

Les journaux de transactions de chaque base de données sont chargés dans un compartiment S3 nommé do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. Le répertoire RDSCustomForSQLServer/Instances/DB_instance_resource_ID dans le compartiment S3 contient deux sous-répertoires :

  • TransactionLogs – Contient les journaux de transactions de chaque base de données et leurs métadonnées respectives.

    Le nom du fichier journal des transactions suit le modèle yyyyMMddHHmm.database_id.timestamp, par exemple :

    202110202230.11.1634769287

    Le même nom de fichier avec le suffixe _metadata contient des informations sur le journal des transactions telles que les numéros de séquence de journaux, le nom de la base de données et RdsChunkCount. RdsChunkCount détermine le nombre de fichiers physiques qui représentent un fichier journal de transactions unique. Vous pouvez voir des fichiers contenant des suffixes _0001,_0002, et ainsi de suite, ce qui correspond aux morceaux physiques d'un fichier journal de transactions. Si vous souhaitez utiliser un fichier journal de transactions en morceaux, veillez à fusionner les morceaux après les avoir téléchargés.

    Imaginons un scénario dans lequel vous disposez des fichiers suivants :

    • 202110202230.11.1634769287

    • 202110202230.11.1634769287_0001

    • 202110202230.11.1634769287_0002

    • 202110202230.11.1634769287_metadata

    Le RdsChunkCount est 3. L'ordre de fusion des fichiers est le suivant : 202110202230.11.1634769287, 202110202230.11.1634769287_0001, 202110202230.11.1634769287_0002.

  • TransactionLogMetadata – Contient des informations de métadonnées sur chaque itération de l'extraction du journal de transactions.

    Le fichier RI.End contient des informations sur toutes les bases de données dont les journaux de transactions ont été extraits, et toutes les bases de données existantes mais dont les journaux de transactions n'ont pas été extraits. Le nom de fichier RI.End suit le modèle yyyyMMddHHmm.RI.End.timestamp, par exemple :

    202110202230.RI.End.1634769281

Restauration PITR à l’aide de la AWS Management Console, de l’AWS CLI ou de l’API RDS.

Vous pouvez restaurer une instance de base de données RDS Custom for SQL Server à un instant dans le passé à l'aide de la AWS Management Console, de AWS CLI, ou de l'API RDS.

Pour restaurer une instance de base de données RDS personnalisée à un moment spécifié
  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Automated backups (Sauvegardes automatisées).

  3. Choisissez l'instance de base de données RDS Custom que vous souhaitez restaurer.

  4. Sous Actions, sélectionnez Restaurer à un moment donné.

    La fenêtre Restaurer à un instant dans le passé s'affiche.

  5. Choisissez Dernière heure de restauration possible pour restaurer à la dernière heure possible, ou choisissez Personnalisé pour choisir une heure.

    Si vous choisissez Custom (Personnalisé), saisissez la date et l'heure auxquelles vous souhaitez restaurer l'instance.

    Les heures sont exprimées dans votre fuseau horaire local, qui est indiqué par son décalage par rapport à l’heure UTC. Par exemple, UTC-5 est l’heure normale de l’Est/heure avancée du Centre.

  6. Pour DB instance identifier (Identifiant d'instance de base de données), saisissez le nom de l'instance de base de données RDS Custom restaurée. Le nom doit être unique.

  7. Choisissez d'autres options selon vos besoins, comme la classe d'instance de base de données.

  8. Choisissez Restaurer à un instant dans le passé.

Vous restaurez une instance de base de données à un moment spécifié à l'aide de la commande AWS CLI restore-db-instance-to-point-in-time pour créer une instance de base de données RDS Custom.

Utilisez l'une des options suivantes pour spécifier la sauvegarde à partir de laquelle effectuer la restauration :

  • --source-db-instance-identifier mysourcedbinstance

  • --source-dbi-resource-id dbinstanceresourceID

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

L’option custom-iam-instance-profile est obligatoire.

L'exemple suivant restaure my-custom-db-instance vers une nouvelle instance de base de données nommée my-restored-custom-db-instance au moment spécifié.

Pour Linux, macOS ou 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

Pour 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