

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
<a name="custom-backup-sqlserver"></a>

Comme Amazon RDS, RDS Custom crée et enregistre des sauvegardes automatiques de votre instance de base de données RDS Custom for SQL Server lorsque la rétention des sauvegardes est activée. Vous pouvez également sauvegarder votre instance de base de données manuellement. Les sauvegardes automatiques comprennent des sauvegardes d’instantanés et des sauvegardes des journaux de transactions. Des sauvegardes d’instantanés 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 des journaux de transactions sont effectuées pour les bases de données éligibles au PITR à intervalles réguliers. RDS Custom enregistre les sauvegardes automatiques de votre instance de base de données selon la période de rétention des sauvegardes que vous spécifiez. Vous pouvez utiliser les sauvegardes automatiques pour récupérer votre instance de base de données pendant la période de conservation des sauvegardes.

Vous pouvez également effectuer des sauvegardes d’instantanés manuelles. Vous pouvez créer une instance de base de données à partir de ces sauvegardes d’instantanés à n’importe quel 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](custom-backup-sqlserver.creating.md).

Bien que les sauvegardes d’instantanés 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. 

**Topics**
+ [Création d'un instantané de RDS Custom for SQL Server](custom-backup-sqlserver.creating.md)
+ [Restauration à partir d'un instantané de base de données RDS Custom for SQL Server](custom-backup-sqlserver.restoring.md)
+ [Restauration d'une instance de RDS Custom for SQL Server à un point dans le temps](custom-backup.pitr-sqs.md)
+ [Suppression d'un instantané de RDS Custom for SQL Server](custom-backup-sqlserver.deleting.md)
+ [Suppression des sauvegardes automatisées RDS Custom for SQL Server](custom-backup-sqlserver.deleting-backups.md)

# Création d'un instantané de RDS Custom for SQL Server
<a name="custom-backup-sqlserver.creating"></a>

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 d’instantanés varie en fonction du nombre total et de la taille de vos bases de données. Pour plus d’informations sur le nombre de bases de données éligibles à une opération de restauration ponctuelle (PITR), consultez [Nombre de bases de données éligibles au PITR par type de classe d’instance](custom-backup.pitr-sqs.md#custom-backup.pitr.sqlserver.eligiblecountperinstance).

É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 pour Amazon RDS](USER_CreateSnapshot.md).

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

## Console
<a name="USER_CreateSnapshot-sqlserver.CON"></a>

**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/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

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

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

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

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

1. Choisissez **Prendre un instantané**.

## AWS CLI
<a name="USER_CreateSnapshot-sqlserver.CLI"></a>

Vous créez un instantané d'une instance de base de données RDS Custom à l'aide de la commande de AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html).

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`.

**Example**  
Pour Linux, macOS ou Unix :  

```
1. aws rds create-db-snapshot \
2.     --db-instance-identifier my-custom-instance \
3.     --db-snapshot-identifier my-custom-snapshot
```
Pour Windows :  

```
1. aws rds create-db-snapshot ^
2.     --db-instance-identifier my-custom-instance ^
3.     --db-snapshot-identifier my-custom-snapshot
```

# Restauration à partir d'un instantané de base de données RDS Custom for SQL Server
<a name="custom-backup-sqlserver.restoring"></a>

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ù l’instantané a été pris. Cela inclut toutes les bases de données et tous les autres fichiers présents sur le volume `(D:)`.

## Console
<a name="custom-backup-sqlserver.restoring.console"></a>

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

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

1. Dans le panneau de navigation, choisissez **Snapshots**.

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

1. Pour **Actions**, choisissez **Restaurer l’instantané**.

1. 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.

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

## AWS CLI
<a name="custom-backup-sqlserver.restoring.CLI"></a>

Vous restaurez un instantané de base de données RDS Custom à l'aide de la commande de AWS CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).

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`.

**Example**  
Pour Linux, macOS 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
```
Pour 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
<a name="custom-backup.pitr-sqs"></a>

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 connaître l'heure de restauration la plus récente pour une instance de base de données, utilisez la AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande 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 à un instant précis pour Amazon RDS](USER_PIT.md).

**Topics**
+ [Considérations PITR pour RDS Custom for SQL Server](#custom-backup.pitr.sqlserver)
+ [Nombre de bases de données éligibles au PITR par type de classe d’instance](#custom-backup.pitr.sqlserver.eligiblecountperinstance)
+ [Rendre les bases de données inéligibles au PITR](#custom-backup.pitr.sqlserver.ineligible)
+ [Journaux de transactions dans Amazon S3](#custom-backup.pitr.sqlserver.tlogs)
+ [Restauration PITR à l'aide de l'AWS Management ConsoleAPIAWS CLI, de ou de l'API RDS.](#custom-backup.pitr-sqs-concli)

## Considérations PITR pour RDS Custom for SQL Server
<a name="custom-backup.pitr.sqlserver"></a>

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](#custom-backup.pitr.sqlserver.ineligible).
+ 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](#custom-backup.pitr.sqlserver.eligiblecountperinstance).

  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 AWS services. Pour de plus amples informations, veuillez consulter [Ajoutez une politique d'accès à AWSRDSCustom SQLServer InstanceRole](custom-setup-sqlserver.md#custom-setup-sqlserver.iam.add-policy).
+ 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
<a name="custom-backup.pitr.sqlserver.eligiblecountperinstance"></a>

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.\$1.large | 100 | 
| db.\$1.xlarge à db.\$1.2xlarge | 150 | 
| db.\$1.4xlarge à db.\$1.8xlarge | 300 | 
| db.\$1.12xlarge à db.\$1.16xlarge | 600 | 
| db.\$1.24xlarge, db.\$132xlarge | 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](USER_Events.Messages.md#USER_Events.Messages.CEV).

**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.

1. Vous modifiez l’instance pour l’augmenter verticalement jusqu’à db.\$1.4xlarge.

1. 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.

1. Vous modifiez maintenant l’instance pour la réduire verticalement jusqu’à db.\$1.xlarge.

1. 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
<a name="custom-backup.pitr.sqlserver.ineligible"></a>

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\$1pitr\$1blocked\$1databases**
+ 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.End`dans 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](#custom-backup.pitr.sqlserver.tlogs).

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](#custom-backup.pitr.sqlserver.eligiblecountperinstance).

**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
<a name="custom-backup.pitr.sqlserver.tlogs"></a>

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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) 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.
<a name="custom-backup.pitr-sqs-concli"></a>

Vous pouvez restaurer une instance de base de données RDS Custom pour SQL Server à un moment donné à l'aide de l'API AWS Management Console RDS ou de l'API RDS. AWS CLI

### Console
<a name="custom-backup-sqs.pitr2.CON"></a>

**Pour restaurer une instance de base de données RDS personnalisée à un moment spécifié**

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

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

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

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

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

1. 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 correspond à l' Time/Central heure avancée normale de l'Est.

1. 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.

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

1. Choisissez **Restaurer à un instant dans le passé**.

### AWS CLI
<a name="custom-backup-sqs.pitr2.CLI"></a>

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-](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) 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é.

**Example**  
Pour Linux, macOS ou Unix :  

```
1. aws rds restore-db-instance-to-point-in-time \
2.     --source-db-instance-identifier my-custom-db-instance\
3.     --target-db-instance-identifier my-restored-custom-db-instance \
4.     --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
5.     --restore-time 2022-10-14T23:45:00.000Z
```
Pour Windows :  

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

# Suppression d'un instantané de RDS Custom for SQL Server
<a name="custom-backup-sqlserver.deleting"></a>

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

## Console
<a name="USER_DeleteSnapshot-sqlserver.CON"></a>

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

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

1. Dans le panneau de navigation, choisissez **Snapshots**.

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

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

1. Dans la page de confirmation, sélectionnez **Supprimer**.

## AWS CLI
<a name="USER_DeleteSnapshot-sqlserver.CLI"></a>

Pour supprimer un instantané RDS Custom, utilisez la commande AWS CLI [delete-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-snapshot.html).

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`.

**Example**  
Pour Linux, macOS ou Unix :  

```
1. aws rds delete-db-snapshot \  
2.   --db-snapshot-identifier my-custom-snapshot
```
Pour Windows :  

```
1. aws rds delete-db-snapshot ^
2.   --db-snapshot-identifier my-custom-snapshot
```

# Suppression des sauvegardes automatisées RDS Custom for SQL Server
<a name="custom-backup-sqlserver.deleting-backups"></a>

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.

## Console
<a name="USER_WorkingWithAutomatedBackups-sqlserver-Deleting.CON"></a>

**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/](https://console.aws.amazon.com/rds/).

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

1. Choisissez **Retained (Conservées)**.

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

1. Pour **Actions**, choisissez **Supprimer**.

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

## AWS CLI
<a name="USER_WorkingWithAutomatedBackups-sqlserver-Deleting.CLI"></a>

Vous pouvez supprimer une sauvegarde automatisée conservée à l'aide de la commande de l'AWS CLI [delete-db-instance-automated-backup](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance-automated-backup.html).

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 rechercher l'identifiant ressource de l'instance de base de données source d'une sauvegarde automatisée conservée en utilisant la commande de AWS CLI [describe-db-instance-automated-backups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instance-automated-backups.html).

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`.

**Example**  
Pour Linux, macOS ou Unix :  

```
1. aws rds delete-db-instance-automated-backup \
2.     --dbi-resource-id custom-db-123ABCEXAMPLE
```
Pour Windows :  

```
1. aws rds delete-db-instance-automated-backup ^
2.     --dbi-resource-id custom-db-123ABCEXAMPLE
```