Fazer backup e restauração de uma instância de banco de dados do Amazon RDS Custom - Amazon Relational Database Service

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.

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.

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.

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 de uma única zona de disponibilidade.

Crie um snapshot do RDS Custom for SQL Server utilizando o console ou a AWS CLI.

Para criar um snapshot do RDS Custom
  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Databases (Bancos de dados).

  3. Na lista de instâncias de banco de dados do RDS Custom, escolha a instância da qual você deseja obter um snapshot.

  4. Em Actions (Ações), escolha Take snapshot (Fazer snapshot).

    A janela Take snapshot de banco de dados (Fazer snapshot de banco de dados) é exibida.

  5. Para Snapshot name (Nome do snapshot), insira o nome do snapshot.

  6. Selecione Take Snapshot (Fazer snapshot).

Você cria um snapshot de uma instância de banco de dados do RDS Custom utilizando o comando create-db-snapshot 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.

Para Linux, macOS ou Unix:

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

Para Windows:

aws rds create-db-snapshot ^ --db-instance-identifier my-custom-instance ^ --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:).

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 AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Snapshots.

  3. Escolha o DB snapshot do qual você deseja restaurar.

  4. Em Actions (Ações), escolha Restore snapshot (Restaurar snapshot).

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

  6. Escolha Restore DB Instance.

Você restaura um snapshot de banco de dados do RDS Custom utilizando o comando restore-db-instance-from-db-snapshot 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.

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 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 Restauração de uma instância de banco de dados para um tempo especificado.

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.

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

    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.

  • 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 obter 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:

  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.

  2. Você modifica a instância para escalar até db.*.4xlarge.

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

  4. Agora, modifique a instância para reduzir a escala verticalmente para db.*.xlarge.

  5. 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/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.

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.

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-$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 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
  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Automated backups (Backups automatizados).

  3. Escolha a instância de banco de dados do RDS Custom que você deseja restaurar.

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

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

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

  7. Escolha outras opções conforme necessário, como a classe da instância de banco de dados.

  8. 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-identifier my-restored-custom-db-instance \ --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \ --restore-time 2022-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-identifier my-restored-custom-db-instance ^ --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^ --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).

Para excluir um snapshot de uma instância de banco de dados do RDS Custom
  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Snapshots.

  3. Escolha o snapshot de banco de dados que você deseja excluir.

  4. Em Actions (Ações), selecione Delete Snapshot (Excluir snapshot).

  5. Escolha Delete (Excluir) na página de confirmação.

Para excluir um snapshot do RDS Custom, utilize o comando da AWS CLI delete-db-snapshot.

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.

Para Linux, macOS ou Unix:

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

Para Windows:

aws rds delete-db-snapshot ^ --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.

Como excluir um backup automatizado retido
  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Automated backups (Backups automatizados).

  3. Escolha Retained (Retido).

  4. Escolha o backup automatizado retido que você deseja excluir.

  5. Em Actions, selecione Delete.

  6. Na página de confirmação, insira delete me e escolha Delete (Excluir).

Você pode excluir um backup automatizado retido usando o comando da AWS CLI delete-db-instance-automated-backup.

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.

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.

Para Linux, macOS ou Unix:

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

Para Windows:

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