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 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.
Tópicos
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 ter mais informações, consulte Tornar bancos de dados não qualificados para PITR.
-
-
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 ter mais informações, consulte Número de bancos de dados elegíveis para PITR por tipo de classe de instância.
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 ter mais informações, consulte Adicionar uma política de acesso a AWSRDSCustomSQLServerInstanceRole. -
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.*.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 ter mais informações, consulte Eventos de versão de mecanismos personalizados.
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:
O RDS Custom para SQL Server escolherá os primeiros 150 bancos de dados, ordenados pelo ID de banco de dados, para backup da PITR.
Você modifica a instância para escalar até db.*.4xlarge.
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.
Agora, modifique a instância para reduzir a escala verticalmente para db.*.xlarge.
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_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/
do bucket do Amazon S3 DB_instance_resource_ID
/TransactionLogMetadatado-not-delete-rds-custom-
. Para obter mais informações sobre o arquivo $ACCOUNT_ID
-$REGION
-unique_identifier
RI.End
, consulte Logs de transações no Amazon S3.
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 ter mais informações, consulte Número de bancos de dados elegíveis para PITR por tipo de classe de instância.
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 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-
. O diretório $ACCOUNT_ID
-$REGION
-unique_identifier
RDSCustomForSQLServer/Instances/
no bucket do S3 contém dois subdiretórios:DB_instance_resource_ID
-
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
, por exemplo:yyyyMMddHHmm
.database_id
.timestamp
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 eRdsChunkCount
.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 arquivoRI.End
segue o padrão
, por exemplo:yyyyMMddHHmm
.RI.End.timestamp
202110202230.RI.End.1634769281
Restauração de PITR usando o AWS Management Console, 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 AWS Management Console, a AWS CLI ou a API do RDS.
Para restaurar uma instância de banco de dados do RDS Custom para um ponto anterior especificado
Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
No painel de navegação, escolha Automated backups (Backups automatizados).
-
Escolha a instância de banco de dados do RDS Custom que você deseja restaurar.
-
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.
-
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.
-
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.
-
Escolha outras opções conforme necessário, como a classe da instância de banco de dados.
-
Escolha Restore to point in time (Restaurar para point-in-time).
Você restaura uma instância de banco de dados em um horário especificado utilizando o comando restore-db-instance-to-point-in-time 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.
Para Linux, macOS ou Unix:
aws rds restore-db-instance-to-point-in-time \ --source-db-instance-identifier
my-custom-db-instance
\ --target-db-instance-identifiermy-restored-custom-db-instance
\ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance
\ --restore-time2022-10-14T23:45:00.000Z
Para Windows:
aws rds restore-db-instance-to-point-in-time ^ --source-db-instance-identifier
my-custom-db-instance
^ --target-db-instance-identifiermy-restored-custom-db-instance
^ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance
^ --restore-time2022-10-14T23:45:00.000Z