# Restaurar uma instância do RDS Custom for SQL Server para um ponto anterior no tempo
<a name="custom-backup.pitr-sqs"></a>

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

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

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.\*.large | 100 | 
| db.\*.xlarge to db.\*.2xlarge | 150 | 
| db.\*.4xlarge to db.\*.8xlarge | 300 | 
| db.\*.12xlarge to db.\*.16xlarge | 600 | 
| db.\*.24xlarge, db.\*32xlarge | 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.\*.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.\*.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
<a name="custom-backup.pitr.sqlserver.ineligible"></a>

É 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\_pitr\_blocked\_databases**
+ 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
<a name="custom-backup.pitr.sqlserver.tlogs"></a>

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.
<a name="custom-backup.pitr-sqs-concli"></a>

É 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
<a name="custom-backup-sqs.pitr2.CON"></a>

**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
<a name="custom-backup-sqs.pitr2.CLI"></a>

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