Sauvegarde et restauration d'une instance de base de données Amazon RDS Custom for SQL Server - Amazon Relational Database Service
Création d'un instantané de RDS Custom for SQL ServerRestauration à partir d'un instantané de base de données RDS Custom for SQL Serveroint-in-time Récupération du pHSuppression d'un instantané de RDS Custom for SQL ServerSuppression des sauvegardes automatisées RDS Custom for SQL Server

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sauvegarde et restauration d'une instance de base de données Amazon RDS Custom for SQL Server

Comme Amazon RDS, RDS Custom crée et enregistre des sauvegardes automatisées de votre instance de base de données RDS Custom pour SQL Server lorsque la conservation des sauvegardes est activée. Vous pouvez également sauvegarder votre instance de base de données manuellement. Les sauvegardes automatisées comprennent des sauvegardes instantanées et des sauvegardes du journal des transactions. Des sauvegardes instantanées sont effectuées pour l'ensemble du volume de stockage de l'instance de base de données pendant la fenêtre de sauvegarde spécifiée. Des sauvegardes du journal des transactions sont effectuées pour les bases de données éligibles au PITR à intervalles réguliers. RDS Custom enregistre les sauvegardes automatisées de votre instance de base de données conformément à la période de conservation des sauvegardes que vous avez spécifiée. Vous pouvez utiliser des sauvegardes automatisées pour restaurer votre instance de base de données à un moment donné pendant la période de conservation des sauvegardes.

Vous pouvez également effectuer des sauvegardes instantanées manuellement. Vous pouvez créer une nouvelle instance de base de données à partir de ces sauvegardes instantanées à tout moment. Pour plus d'informations sur la création manuelle d'un instantané de base de données, consultez Création d'un instantané de RDS Custom for SQL Server.

Bien que les sauvegardes instantanées soient opérationnelles comme des sauvegardes complètes, vous n'êtes facturée que pour l'utilisation incrémentielle du stockage. Le premier instantané d'une instance de base de données RDS Custom contient les données de l'instance de base de données complète. Les instantanés suivants de la même base de données sont incrémentiels, ce qui signifie que seules les données qui ont changé depuis l'instantané le plus récent sont enregistrées.

Création d'un instantané de RDS Custom for SQL Server

RDS Custom for SQL crée un instantané du volume de stockage de votre instance de base de données, en sauvegardant l'intégralité de cette dernière et non pas seulement des bases de données individuelles. Lorsque vous créez un instantané, spécifiez l'instance de base de données RDS Custom for SQL Server à sauvegarder. Nommez votre instantané afin que vous puissiez restaurer ultérieurement à partir de ce dernier.

Lorsque vous créez un instantané, RDS Custom for SQL Server crée un instantané Amazon EBS pour le volume(D:), qui est le volume de base de données attaché à l'instance de base de données. Pour que les instantanés soient faciles à associer à une instance de base de données spécifique, ils sont labelisés DBSnapshotIdentifier, DbiResourceId et VolumeType.

La création d'un instantané de base de données entraîne une brève suspension des I/O. Cette suspension peut durer de quelques secondes à quelques minutes, en fonction de la taille et de la classe de votre instance de base de données. Le temps de création des instantanés varie en fonction du nombre total et de la taille de vos bases de données. Pour en savoir plus sur le nombre de bases de données éligibles à une opération de restauration instantanée (PITR), consultezNombre de bases de données éligibles au PITR par type de classe d'instance.

Étant donné que l'instantané inclut l'intégralité du volume de stockage, la taille de fichiers comme les fichiers temporaires a également une incidence sur le temps nécessaire à la création de l'instantané. Pour en savoir plus sur la création des instantanés, consultez Création d'un instantané de base de données pour une instance de base de données mono-AZ.

Créez un instantané de RDS Custom for SQL Server en utilisant la console ou AWS CLI.

Pour créer un instantané RDS Custom

  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 Databases (Bases de données).

  3. Dans la liste d'instances de base de données RDS Custom, choisissez l'instance pour laquelle vous souhaitez prendre un instantané.

  4. Sous Actions, choisissez Take snapshot (Prendre un instantané).

    La fenêtre Capture d'un instantané DB apparaît.

  5. Dans Snapshot name (Nom de l'instantané), saisissez le nom de l'instantané.

  6. Choisissez Prendre un instantané.

Vous créez un instantané d'une instance de base de données personnalisée RDS à l'aide de la create-db-snapshotAWS CLIcommande.

Spécifiez les options suivantes :

  • --db-instance-identifier – Identifie l'instance de base de données RDS Custom que vous allez sauvegarder

  • --db-snapshot-identifier – Nomme votre instantané RDS Custom afin que vous puissiez restaurer ultérieurement à partir de ce dernier

Dans cet exemple, vous créez un instantané de base de données appelé my-custom-snapshot pour une instance de base de données RDS Custom appelée my-custom-instance.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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

Restauration à partir d'un instantané de base de données RDS Custom for SQL Server

Lorsque vous restaurez une instance de base de données RDS Custom for SQL Server, vous indiquez le nom de l'instantané de base de données et un nom pour la nouvelle instance. Vous ne pouvez pas restaurer à partir d'un instantané vers une instance de base de données RDS Custom existante. Une nouvelle instance de base de données RDS Custom for SQL Server est créée lors de la restauration.

La restauration à partir d'un instantané rétablit le volume de stockage au moment où le cliché a été pris. Cela inclura toutes les bases de données et tous les autres fichiers présents sur le (D:) volume.

Pour restaurer une instance de base de données RDS Custom à partir d'un instantané de base de données

  1. Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Snapshots.

  3. Choisissez l'instantané de base de données à partir duquel vous voulez restaurer.

  4. Pour Actions, choisissez Restaurer l'instantané.

  5. Sur la page Restore DB Instance (Restituer l'instance de base de données), pour DB instance identifier (Identifiant d'instance de base de données), saisissez le nom de votre instance de base de données RDS Custom restaurée.

  6. Choisissez Restore DB Instance (Restaurer une instance de base de données).

Vous restaurez un instantané de base de données personnalisé RDS à l'aide de la commande restore-db-instance-fromAWS CLI-db-snapshot.

Si l'instantané à partir duquel vous restaurez est destiné à une instance de base de données privée, assurez-vous de spécifier le db-subnet-group-name correct et no-publicly-accessible. Sinon, l'instance de base de données est accessible par défaut au public. Les options suivantes sont requises :

  • db-snapshot-identifier – Identifie l'instantané à partir duquel restaurer

  • db-instance-identifier – Spécifie le nom de l'instance de base de données RDS Custom à créer à partir de l'instantané de base de données

  • custom-iam-instance-profile : spécifie le profil d'instance associé à l'instance Amazon EC2 sous-jacente d'une instance de base de données RDS Custom.

Le code suivant restaure l'instantané nommé my-custom-snapshot pour my-custom-instance.

Pour LinuxmacOS, ou 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

Dans 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

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 doit être activée sur vos instances de base de données.

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 connaître l'heure de restauration la plus récente pour une instance de base de données, utilisez la AWS CLI describe-db-instancescommande et examinez la valeur renvoyée dans le LatestRestorableTime champ correspondant à 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 à une date spécifiée.

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 identifiant 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 maximum de bases de données restaurées par une opération 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 de snapshots de base de données, y compris les sauvegardes automatiques de snapshots 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 est agrandie, 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.

  • AWSRDSCustomSQLServerIamRolePolicynécessite l'accès à d'autres AWS services. Pour plus d'informations, consultez Ajoutez une politique 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 maximum de bases de données éligibles au PITR en fonction du type de classe d'instance.

Type de classe d'instance Nombre maximum de bases de données éligibles au PITR
db.*.large 100
db.*.xlarge vers db.*.2xlarge 150
db.*.4xlarge vers db.*.8xlarge 300
db.*.12xlarge vers db.*.16xlarge 600
db.*.24xlarge, db.*32xlarge 1 000

*Représente 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 plus grands types de classes d'instance pris en charge par RDS Custom for SQL Server. Les bases de données (master, model, msdb, tempdb) système SQL Server ne sont pas incluses dans cette limite. Lorsqu'une instance de base de données est redimensionnée à la hausse ou à la baisse, 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 un message RDS-EVENT-0352 lorsque le nombre maximum 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

Le support 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 le support 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 :

  • Mettez à 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 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 conservation 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 instance 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 la mettre à l'échelle 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 leur ID de base de données, pour la sauvegarde 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 à 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 leur ID de base de données, pour la sauvegarde 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 @limit variable 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.

Pour déterminer 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 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 la section 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 l'AWS Management ConsoleAPIAWS CLI, de 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 à une heure spécifiée en utilisant la point-in-time AWS CLI commande restore-db-instance-to- pour créer une nouvelle instance de base de données personnalisée RDS.

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 LinuxmacOS, 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

Dans 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

Suppression d'un instantané de RDS Custom for SQL Server

Vous pouvez supprimer les instantanés de base de données gérés par RDS Custom for SQL Server lorsque vous n'en avez plus besoin. La procédure de suppression est la même pour les instances de base de données Amazon RDS et RDS Custom.

Les instantanés Amazon EBS des volumes binaires et racine restent dans votre compte plus longtemps, car ils peuvent être liés à certaines instances exécutées dans votre compte ou à d'autres instantanés RDS Custom for SQL Server. Ces instantanés EBS sont automatiquement supprimés dès qu'ils ne sont plus liés à des ressources RDS Custom for SQL Server existantes (instances ou sauvegardes de base de données).

Pour supprimer un instantané d'une instance de base de données RDS Custom

  1. Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Snapshots.

  3. Choisissez l'instantané de base de données à supprimer.

  4. Pour Actions, choisissez Delete snapshot (Supprimer la pile).

  5. Dans la page de confirmation, sélectionnez Supprimer.

Pour supprimer un instantané personnalisé RDS, utilisez la AWS CLI commande delete-db-snapshot.

L'option suivante est requise :

  • --db-snapshot-identifier – L'instantané à supprimer

L'exemple suivant supprime l'instantané de base de données my-custom-snapshot.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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

Suppression des sauvegardes automatisées RDS Custom for SQL Server

Vous pouvez supprimer les sauvegardes automatisées conservées de RDS Custom for SQL Server quand elles ne sont plus nécessaires. La procédure est la même que la procédure de suppression des sauvegardes Amazon RDS.

Pour supprimer une sauvegarde automatisée conservée

  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 Retained (Conservées).

  4. Choisissez la sauvegarde automatisée conservée que vous souhaitez supprimer.

  5. Pour Actions, choisissez Supprimer.

  6. Dans la page de confirmation, entrez delete me et choisissez Delete (Supprimer).

Vous pouvez supprimer une sauvegarde automatique conservée à l'aide de la AWS CLI commande delete-db-instance-automated-backup.

L'option suivante est utilisée pour supprimer une sauvegarde automatisée conservée.

  • --dbi-resource-id – L'identifiant de la ressource de l'instance de base de données RDS Custom source.

    Vous pouvez trouver l'identifiant de ressource pour l'instance de base de données source d'une sauvegarde automatique conservée à l'aide de la AWS CLI commande describe-db-instance-automated-backups.

L'exemple suivant supprime la sauvegarde automatisée conservée avec l'identifiant de ressource d'instance de base de données custom-db-123ABCEXAMPLE.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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