# Fazer backup e restauração de uma instância de banco de dados do Amazon RDS Custom
Como o Amazon RDS, o RDS Custom cria e salva backups automatizados da instância de banco de dados do RDS Custom para SQL Server quando a retenção do backup está habilitada. Também é possível fazer backup da instância de banco de dados manualmente. Os backups automatizados são compostos de backups de snapshots e backups de logs de transações. Os backups de snapshots são feitos para todo o volume de armazenamento da instância de banco de dados durante a janela de backup especificada. Os backups de logs de transações são feitos para os bancos de dados elegíveis para PITR em um intervalo regular. O RDS Custom salva os backups automatizados da instância de banco de dados de acordo com o período de retenção de backup especificado. É possível usar backups automatizados para recuperar a instância de banco de dados para um ponto no tempo dentro do período de retenção de backup.
Também é possível fazer backups de snapshots manualmente. É possível criar uma instância de banco de dados por meio desses backups de snapshots a qualquer momento. Para ter mais informações sobre como criar um snapshot de banco de dados manualmente, consulte [Criar um snapshot do RDS Custom for SQL Server](custom-backup-sqlserver.creating.md).
Embora os backups de snapshots sirvam operacionalmente como backups completos, você é cobrado somente pelo uso incremental do armazenamento. O primeiro snapshot de uma instância de banco de dados do RDS Custom os dados da instância de banco de dados completa. Os snapshots subsequentes do mesmo banco de dados são incrementais, o que significa que somente os dados que foram alterados depois do snapshot mais recente serão salvos.
**Topics**
+ [Criar um snapshot do RDS Custom for SQL Server](custom-backup-sqlserver.creating.md)
+ [Restaurar de um snapshot de banco de dados do RDS Custom for SQL Server](custom-backup-sqlserver.restoring.md)
+ [Restaurar uma instância do RDS Custom for SQL Server para um ponto anterior no tempo](custom-backup.pitr-sqs.md)
+ [Excluir um snapshot do RDS Custom for SQL Server](custom-backup-sqlserver.deleting.md)
+ [Excluir backups automatizados do RDS Custom for SQL Server](custom-backup-sqlserver.deleting-backups.md)
# Criar um snapshot do RDS Custom for SQL Server
O RDS Custom for SQL Server cria um snapshot do volume de armazenamento da instância de banco de dados, fazendo backup de toda a instância de banco de dados e não apenas dos bancos de dados individuais. Ao criar um snapshot, especifique de qual instância de banco de dados do RDS Custom for SQL Server é necessário fazer backup. Atribua um nome ao snapshot para que ele possa ser restaurado posteriormente.
Ao criar um snapshot, o RDS Custom para SQL Server cria um snapshot do Amazon EBS para o volume `(D:)`, que é o volume de banco de dados anexado à instância de banco de dados. Para facilitar a associação de snapshots a uma instância de banco de dados específica, eles são marcados com `DBSnapshotIdentifier`, `DbiResourceId` e `VolumeType`.
A criação de um snapshot de banco de dados resulta em uma breve suspensão de E/S. Essa suspensão pode durar desde alguns segundos até alguns minutos, dependendo do tamanho e da classe da sua instância de banco de dados. O tempo de criação do snapshot varia dependendo do número total e do tamanho dos bancos de dados. Para saber mais sobre o número de bancos de dados elegíveis para uma operação de recuperação para um ponto no tempo (PITR), consulte [Número de bancos de dados elegíveis para PITR por tipo de classe de instância](custom-backup.pitr-sqs.md#custom-backup.pitr.sqlserver.eligiblecountperinstance).
Como o snapshot inclui todo o volume de armazenamento, o tamanho de arquivos, como arquivos temporários, também afeta o tempo necessário para criar esse snapshot. Para saber mais sobre como criar snapshots, consulte [Criar um snapshot de banco de dados para uma instância de banco de dados single-AZ para o Amazon RDS](USER_CreateSnapshot.md).
Crie um snapshot do RDS Custom for SQL Server utilizando o console ou a AWS CLI.
## Console
**Para criar um snapshot do RDS Custom**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Bancos de dados**.
1. Na lista de instâncias de banco de dados do RDS Custom, escolha a instância da qual você deseja obter um snapshot.
1. Em **Actions (Ações)**, escolha **Take snapshot (Fazer snapshot)**.
A janela **Take snapshot de banco de dados** (Fazer snapshot de banco de dados) é exibida.
1. Para **Snapshot name** (Nome do snapshot), insira o nome do snapshot.
1. Selecione **Take Snapshot** (Fazer snapshot).
## AWS CLI
Você cria um snapshot de uma instância de banco de dados do RDS Custom utilizando o comando [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) da AWS CLI.
Especifique as seguintes opções:
+ `--db-instance-identifier` – Identifica de qual instância de banco de dados do RDS Custom você fará backup
+ `--db-snapshot-identifier` – Dê um nome para seu snapshot do RDS Custom para que ele possa ser restaurado mais tarde
Neste exemplo, você cria um snapshot de banco de dados chamado *`my-custom-snapshot`* para uma instância de banco de dados do RDS Custom chamada `my-custom-instance`.
**Example**
Para Linux, macOS ou Unix:
```
1. aws rds create-db-snapshot \
2. --db-instance-identifier my-custom-instance \
3. --db-snapshot-identifier my-custom-snapshot
```
Para Windows:
```
1. aws rds create-db-snapshot ^
2. --db-instance-identifier my-custom-instance ^
3. --db-snapshot-identifier my-custom-snapshot
```
# Restaurar de um snapshot de banco de dados do RDS Custom for SQL Server
Ao restaurar uma instância de banco de dados do RDS Custom for SQL Server, você fornece o nome do snapshot de banco de dados e um nome para a nova instância. Não é possível restaurar de um snapshot para uma instância de banco de dados do RDS Custom existente. Uma nova instância de banco de dados do RDS Custom for SQL Server é criada quando você realiza a restauração.
A restauração a partir de um snapshot restaurará o volume de armazenamento até o momento em que o snapshot foi criado. Isso incluirá todos os bancos de dados e quaisquer outros arquivos presentes no volume `(D:)`.
## Console
**Para restaurar uma instância de banco de dados do RDS Custom a partir de um snapshot de banco de dados**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Snapshots**.
1. Escolha o DB snapshot do qual você deseja restaurar.
1. Em **Actions (Ações)**, escolha **Restore snapshot (Restaurar snapshot)**.
1. Na página **Restore DB instance** (Restaurar instância de banco de dados), para **DB Instance Identifier** (Identificador da instância de banco de dados), insira o nome da instância de banco de dados do RDS Custom restaurada.
1. Escolha **Restore DB Instance**.
## AWS CLI
Você restaura um snapshot de banco de dados do RDS Custom utilizando o comando [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) da AWS CLI.
Se o snapshot do qual você está restaurando for para uma instância de banco de dados privada, certifique-se de especificar `db-subnet-group-name` e `no-publicly-accessible`, ambos corretos. Caso contrário, a instância de banco de dados assumirá como padrão o estado de acesso público. São necessárias as seguintes opções:
+ `db-snapshot-identifier` – Identifica o snapshot do qual restaurar
+ `db-instance-identifier` – Especifica o nome da instância de banco de dados do RDS Custom a ser criada a partir do snapshot de banco de dados
+ `custom-iam-instance-profile`: especifica o perfil da instância associado à instância subjacente do Amazon EC2 de uma instância de banco de dados do RDS Custom.
O código a seguir restaura o snapshot chamado `my-custom-snapshot` para `my-custom-instance`.
**Example**
Para 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
```
Para 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
```
# Restaurar uma instância do RDS Custom for SQL Server para um ponto anterior no tempo
É possível restaurar uma instância de banco de dados para um ponto anterior no tempo (PITR) criando uma nova instância de banco de dados. Para oferecer compatibilidade com a PITR, as instâncias de banco de dados devem ter a retenção de backup habilitada.
O tempo de restauração mais recente de uma instância de banco de dados do RDS Custom for SQL Server depende de vários fatores, mas em geral é de até cinco minutos do horário atual. Para visualizar o tempo restaurável mais recente para uma instância de banco de dado, use o comando AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) e confira o valor retornado no campo `LatestRestorableTime` para a instância de banco de dados. Para ver o tempo de restauração mais recente para cada instância de banco de dados no console Amazon RDS, selecione **Backups automatizados**.
É possível fazer a restauração para qualquer momento dentro do período de retenção de backup. Para ver o tempo de restauração mais antigo para cada instância de banco de dados, selecione **Backups automatizados** no console do Amazon RDS.
Para obter informações gerais sobre PITR, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md).
**Topics**
+ [Considerações sobre a PITR para o RDS Custom for SQL Server](#custom-backup.pitr.sqlserver)
+ [Número de bancos de dados elegíveis para PITR por tipo de classe de instância](#custom-backup.pitr.sqlserver.eligiblecountperinstance)
+ [Tornar bancos de dados não qualificados para PITR](#custom-backup.pitr.sqlserver.ineligible)
+ [Logs de transações no Amazon S3](#custom-backup.pitr.sqlserver.tlogs)
+ [Restauração de PITR usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.](#custom-backup.pitr-sqs-concli)
## Considerações sobre a PITR para o RDS Custom for SQL Server
No RDS Custom for SQL Server, a PITR difere das seguintes maneiras importantes da PITR no Amazon RDS:
+ A PITR apenas restaura os bancos de dados na instância de banco de dados. Ele não restaura o sistema operacional ou arquivos na unidade C:.
+ Para uma instância de banco de dados do RDS Custom for SQL Server, um banco de dados recebe backup automaticamente e está qualificado para PITR somente nestas condições:
+ O banco de dados está online.
+ Seu modelo de recuperação está definido como `FULL`.
+ É gravável.
+ Ele tem seus arquivos físicos na unidade D:.
+ Ele não está listado na tabela `rds_pitr_blocked_databases`. Para obter mais informações, consulte [Tornar bancos de dados não qualificados para PITR](#custom-backup.pitr.sqlserver.ineligible).
+ Os bancos de dados elegíveis para PITR são determinados por ordem de ID de banco de dados. O RDS Custom for SQL Server permite até 5.000 bancos de dados por instância de banco de dados. Contudo, o número máximo de bancos de dados restaurados por uma operação de PITR para uma instância de banco de dados do RDS Custom para SQL Server depende do tipo de classe de instância. Para obter mais informações, consulte [Número de bancos de dados elegíveis para PITR por tipo de classe de instância](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
Outros bancos de dados que não fazem parte da PITR podem ser restaurados por meio de snapshots de banco de dados, incluindo os backups de snapshots automatizados utilizados para a PITR.
+ Adicionar um novo banco de dados, renomear um banco de dados ou restaurar um banco de dados elegível para PITR inicia um snapshot da instância de banco de dados.
+ O número máximo de bancos de dados elegíveis para PITR muda quando a instância do banco de dados passa por uma operação de computação em escala, dependendo do tipo de classe da instância de destino. Se você aumentar a escala da instância verticalmente, permitindo que mais bancos de dados na instância sejam elegíveis para PITR, um novo snapshot será criado.
+ Os bancos de dados restaurados têm o mesmo nome que a instância de banco de dados de origem. Se desejar, especifique um nome diferente.
+ `AWSRDSCustomSQLServerIamRolePolicy` requer acesso a outros serviços da AWS. Para obter mais informações, consulte [Adicionar uma política de acesso a AWSRDSCustomSQLServerInstanceRole](custom-setup-sqlserver.md#custom-setup-sqlserver.iam.add-policy).
+ Alterações de fuso horário não têm suporte para o RDS Custom for SQL Server. Se você alterar o fuso horário do sistema operacional ou da instância de banco de dados, a PITR (e outras automações) não funcionará.
## Número de bancos de dados elegíveis para PITR por tipo de classe de instância
A tabela a seguir mostra o número máximo de bancos de dados elegíveis para PITR com base no tipo de classe de instância.
| Tipo de classe de instância | Número máximo de bancos de dados elegíveis para PITR |
| --- | --- |
| db.\$1.large | 100 |
| db.\$1.xlarge to db.\$1.2xlarge | 150 |
| db.\$1.4xlarge to db.\$1.8xlarge | 300 |
| db.\$1.12xlarge to db.\$1.16xlarge | 600 |
| db.\$1.24xlarge, db.\$132xlarge | 1000 |
`*` *Representa os diferentes tipos de classes da instância.*
O número máximo de bancos de dados elegíveis para PITR em uma instância de banco de dados depende do tipo de classe da instância. O número varia de cem no menor a mil nos maiores tipos de classe de instância compatíveis com o RDS Custom para SQL Server. Os bancos de dados de sistemas do SQL Server `(master, model, msdb, tempdb)` não estão incluídos nesse limite. Quando você aumenta ou reduz a escala de uma instância de banco de dados verticalmente, dependendo do tipo de classe de instância de destino, o RDS Custom atualizará automaticamente o número de bancos de dados elegíveis para PITR. O RDS Custom para SQL Server enviará `RDS-EVENT-0352` quando o número máximo de bancos de dados elegíveis para PITR for alterado em uma instância de banco de dados. Para obter mais informações, consulte [Eventos de versão de mecanismos personalizados](USER_Events.Messages.md#USER_Events.Messages.CEV).
**nota**
O suporte à PITR para mais de cem bancos de dados só está disponível em instâncias de banco de dados criadas após 26 de agosto de 2023. Para instâncias criadas antes de 26 de agosto de 2023, o número máximo de bancos de dados elegíveis para PITR é cem, independentemente da classe da instância. Para habilitar o suporte a PITR para mais de cem bancos de dados em instâncias de banco de dados criadas antes de 26 de agosto de 2023, é possível realizar a seguinte ação:
Atualizar a versão do mecanismo de banco de dados para 15.00.4322.2.v1 ou posterior
Durante uma operação de PITR, o RDS Custom vai restaurar todos os bancos de dados que faziam parte da PITR na instância de banco de dados de origem no momento da restauração. Depois que a instância de banco de dados de destino concluir as operações de restauração, se a retenção de backup estiver habilitada, a instância de banco de dados começará a fazer backup com base no número máximo de bancos de dados elegíveis para PITR na instância de banco de dados de destino.
Por exemplo, se a instância de banco de dados for executada em uma `db.*.xlarge` que tenha duzentos bancos de dados:
1. O RDS Custom para SQL Server escolherá os primeiros 150 bancos de dados, ordenados pelo ID de banco de dados, para backup da PITR.
1. Você modifica a instância para escalar até db.\$1.4xlarge.
1. Uma vez concluída a operação de computação em escala, o RDS Custom para SQL Server escolherá os primeiros trezentos bancos de dados, ordenados pelo ID de banco de dados, para backup da PITR. Cada um dos duzentos bancos de dados que atendem às condições exigidas pela PITR agora será elegível para PITR.
1. Agora, modifique a instância para reduzir a escala verticalmente para db.\$1.xlarge.
1. Uma vez concluída a operação de computação em escala, o RDS Custom para SQL Server selecionará novamente os primeiros 150 bancos de dados, ordenados pelo ID de banco de dados, para backup da PITR.
## Tornar bancos de dados não qualificados para PITR
É possível optar por excluir bancos de dados individuais da PITR. Para fazer isso, coloque seus valores de `database_id` em uma tabela `rds_pitr_blocked_databases`. Utilize o seguinte script SQL para criar a tabela.
**Para criar a tabela rds\$1pitr\$1blocked\$1databases**
+ Execute o seguinte script 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)
);
```
Para conhecer a lista de bancos de dados qualificados e não qualificados, consulte o arquivo `RI.End` no diretório `RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata` do bucket do Amazon S3 `do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier`. Para obter mais informações sobre o arquivo `RI.End`, consulte [Logs de transações no Amazon S3](#custom-backup.pitr.sqlserver.tlogs).
Também é possível determinar a lista de bancos de dados elegíveis para PITR usando o script SQL a seguir. Defina a variável `@limit` como o número máximo de bancos de dados elegíveis para PITR para a classe de instância. Para obter mais informações, consulte [Número de bancos de dados elegíveis para PITR por tipo de classe de instância](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
**Como determinar a lista de bancos de dados elegíveis para PITR em uma classe de instância de banco de dados**
+ Execute o seguinte script 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
```
**nota**
Os bancos de dados que são apenas links simbólicos também são excluídos dos bancos de dados elegíveis para operações de PITR. A consulta acima não é filtrada com base nesses critérios.
## Logs de transações no Amazon S3
O período de retenção de backup determina se os logs de transações para instâncias de banco de dados RDS Custom for SQL Server são automaticamente extraídos e carregados no Amazon S3. Um valor diferente de zero significa que backups automáticos são criados e que o agente do RDS Custom carrega os logs de transações no S3 a cada 5 minutos.
Os arquivos de log de transações no S3 são criptografados em repouso utilizando a AWS KMS key que você forneceu quando criou sua instância de banco de dados. Para obter mais informações, consulte [Como proteger dados usando criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) no *Guia do usuário do Amazon Simple Storage Service*.
Os logs de transações de cada banco de dados são carregados em um bucket do S3 denominado `do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier`. O diretório `RDSCustomForSQLServer/Instances/DB_instance_resource_ID` no bucket do S3 contém dois subdiretórios:
+ `TransactionLogs` – contém os logs de transações para cada banco de dados e seus respectivos metadados.
O nome do arquivo de log de transações segue o padrão `yyyyMMddHHmm.database_id.timestamp`, por exemplo:
```
202110202230.11.1634769287
```
O mesmo nome de arquivo com o sufixo `_metadata` contém informações sobre o log de transações, como números de sequência de log, nome do banco de dados e `RdsChunkCount`. `RdsChunkCount` determina quantos arquivos físicos representam um único arquivo de log de transações. Você pode ver arquivos com os sufixos `_0001`, `_0002` e assim por diante, o que significa os blocos físicos de um arquivo de log de transações. Se quiser utilizar um arquivo de log de transações em blocos, certifique-se de mesclar os blocos depois de baixá-los.
Considere um cenário com os seguintes arquivos:
+ `202110202230.11.1634769287`
+ ` 202110202230.11.1634769287_0001`
+ ` 202110202230.11.1634769287_0002 `
+ ` 202110202230.11.1634769287_metadata`
O `RdsChunkCount` é `3`. A ordem de mesclagem dos arquivos é a seguinte: `202110202230.11.1634769287`, ` 202110202230.11.1634769287_0001`, `202110202230.11.1634769287_0002`.
+ `TransactionLogMetadata` – contém informações de metadados sobre cada iteração da extração do log de transações.
O arquivo `RI.End` contém informações para todos os bancos de dados que tiveram seus logs de transações extraídos e para todos os bancos de dados existentes, mas que não tiveram seus logs de transações extraídos. O nome do arquivo `RI.End` segue o padrão `yyyyMMddHHmm.RI.End.timestamp`, por exemplo:
```
202110202230.RI.End.1634769281
```
## Restauração de PITR usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
É possível restaurar uma instância de banco de dados do RDS Custom for SQL Server em um ponto anterior no tempo utilizando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
### Console
**Para restaurar uma instância de banco de dados do RDS Custom para um ponto anterior especificado**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Automated backups (Backups automatizados)**.
1. Escolha a instância de banco de dados do RDS Custom que você deseja restaurar.
1. Em **Actions (Ações)**, escolha **Restore to point in time (Restaurar para point-in-time)**.
A janela **Restore to point in time (Restaurar para point-in-time)** é exibida.
1. Escolha **Latest restorable time (Hora da última restauração)** para restaurar no último horário possível ou escolha **Custom (Personalizar)** para escolher um horário.
Se você escolher **Custom** (Personalizado), insira a data e a hora para a qual deseja restaurar a instância.
Os horários são mostrados no fuso horário local, que é indicado por um deslocamento do Tempo Universal Coordenado (UTC). Por exemplo, UTC-5 é a Hora Padrão do Leste dos EUA/Horário de Verão Central.
1. Para **DB instance identifier** (Identificador de instância de banco de dados), insira o nome da instância de banco de dados do RDS Custom restaurada de destino. O nome deve ser exclusivo.
1. Escolha outras opções conforme necessário, como a classe da instância de banco de dados.
1. Escolha **Restore to point in time (Restaurar para point-in-time)**.
### AWS CLI
Você restaura uma instância de banco de dados em um horário especificado utilizando o comando [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) da AWS CLI para criar uma nova instância de banco de dados do RDS Custom.
Utilize uma das seguintes opções para especificar o backup a ser restaurado:
+ `--source-db-instance-identifier mysourcedbinstance`
+ `--source-dbi-resource-id dbinstanceresourceID`
+ `--source-db-instance-automated-backups-arn backupARN`
A opção `custom-iam-instance-profile` é obrigatória.
O exemplo a seguir restaura `my-custom-db-instance` para uma nova instância de banco de dados denominada `my-restored-custom-db-instance`, a partir do ponto anterior especificado.
**Example**
Para 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
```
Para 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
```
# Excluir um snapshot do RDS Custom for SQL Server
É possível excluir snapshots de banco de dados gerenciados pelo RDS Custom for SQL Server quando eles não são mais necessários. O procedimento de exclusão é o mesmo para instâncias de banco de dados Amazon RDS e RDS Custom.
Os snapshots do Amazon EBS para os volumes binário e raiz permanecem na sua conta por mais tempo, pois podem estar vinculados a algumas instâncias em execução na sua conta ou a outros snapshots do RDS Custom for SQL Server. Esses snapshots do EBS serão excluídos automaticamente quando não estiverem mais relacionados a nenhum recurso existente do RDS Custom for SQL Server (instâncias de banco de dados ou backups).
## Console
**Para excluir um snapshot de uma instância de banco de dados do RDS Custom**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Snapshots**.
1. Escolha o snapshot de banco de dados que você deseja excluir.
1. Em **Actions** (Ações), selecione **Delete Snapshot** (Excluir snapshot).
1. Escolha **Delete (Excluir)** na página de confirmação.
## AWS CLI
Para excluir um snapshot do RDS Custom, utilize o comando da AWS CLI [delete-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-snapshot.html).
A seguinte opção é necessária:
+ `--db-snapshot-identifier` ؎ – o snapshot a ser excluído
O exemplo a seguir exclui o snapshot de banco de dados `my-custom-snapshot`.
**Example**
Para Linux, macOS ou Unix:
```
1. aws rds delete-db-snapshot \
2. --db-snapshot-identifier my-custom-snapshot
```
Para Windows:
```
1. aws rds delete-db-snapshot ^
2. --db-snapshot-identifier my-custom-snapshot
```
# Excluir backups automatizados do RDS Custom for SQL Server
Você pode excluir backups automatizados retidos para o RDS Custom for SQL Server quando eles não são mais necessários. O procedimento é idêntico ao de exclusão de backups do Amazon RDS.
## Console
**Como excluir um backup automatizado retido**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Automated backups (Backups automatizados)**.
1. Escolha **Retained (Retido)**.
1. Escolha o backup automatizado retido que você deseja excluir.
1. Em **Actions**, selecione **Delete**.
1. Na página de confirmação, insira **delete me** e escolha **Delete (Excluir)**.
## AWS CLI
Você pode excluir um backup automatizado retido usando o comando da AWS CLI [delete-db-instance-automated-backup](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance-automated-backup.html).
A seguinte opção é usada para excluir um backup automatizado retido:
+ `--dbi-resource-id` – o identificador de recurso da instância de banco de dados do RDS Custom de origem.
Você pode encontrar o identificador de recurso da instância de banco de dados de origem de um backup automatizado retido usando o comando da AWS CLI [describe-db-instance-automated-backups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instance-automated-backups.html).
O exemplo a seguir exclui o backup automatizado retido com o identificador de recurso da instância de banco de dados de origem `custom-db-123ABCEXAMPLE`.
**Example**
Para Linux, macOS ou Unix:
```
1. aws rds delete-db-instance-automated-backup \
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```
Para Windows:
```
1. aws rds delete-db-instance-automated-backup ^
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```