AWS RDS Snapshots e Automated Backups

O Amazon RDS empacota em serviço gerenciado as duas camadas clássicas de proteção de banco de dados: backups automatizados com recuperação para um instante no tempo e snapshots manuais com retenção indefinida. O backup automatizado é o mecanismo de rotina, criado diariamente na janela configurada e capaz de restaurar o banco para qualquer segundo dentro da janela de retenção, que vai de 0 a 35 dias. O snapshot manual é a âncora de longo prazo, capturado sob demanda, retido até ser deletado explicitamente e sobrevivente à própria instância que o originou. Em produção, entender a diferença entre os dois, o que cada um retém, quando cada um é cobrado e como cada um restaura, evita tanto a fatura inesperada quanto a falsa expectativa de recuperação no dia do incidente. Este arquivo detalha o funcionamento interno dos dois mecanismos, o PITR nativo do serviço, a cópia entre regiões e os critérios de dimensionamento de retenção e custo.

Conceito e os dois mecanismos do serviço

O automated backup do RDS não é um dump diário. Ele é um sistema composto por um snapshot diário completo mais o arquivamento contínuo de logs de transação (binlog do MySQL/MariaDB, WAL do PostgreSQL), que juntos habilitam o PITR nativo para qualquer segundo dentro da janela de retenção. Desativar o automated backup, retenção zero, desliga também o arquivamento de logs e elimina a capacidade de recuperação pontual.

O manual snapshot é um instantâneo de storage capturado por chamada de API, de forma síncrona e sob demanda. Ele não depende da janela de backup, não expira automaticamente e continua existindo mesmo após a instância ser deletada, o que o torna o mecanismo correto para âncoras de longo prazo, ambientes de staging e snapshots pré-deploy.

A captura de ambos usa o mesmo mecanismo físico: pausa breve de I/O para flush consistente (ou uso do volume de storage subjacente do Aurora, que copia blocos do cluster), registro do estado pontual e cópia incremental em storage gerenciado. O custo de captura no volume de produção é reduzido a uma janela curta, e o processo não exige quiesce manual.

A escolha entre os dois segue papéis complementares: automatizado para o RPO de minutos do dia a dia, manual para a imutabilidade de eventos e para o histórico que excede 35 dias. Estratégias maduras usam os dois ao mesmo tempo, com etiquetas de governança sobre os manuais.

No Aurora, o mecanismo é mais integrado: o cluster mantém backups automatizados sem impacto de I/O perceptível, pois a arquitetura de storage de 6 vias já isola a escrita, e o restore cria um novo cluster inteiro, não uma instância. Os princípios de retenção, PITR e cópia cross-region são os mesmos, com limites de retenção que podem ser estendidos além de 35 dias via backup lock (imutabilidade com retenção longa) quando a exigência de compliance pede.

A interação com Multi-AZ merece nota explícita: réplicas de alta disponibilidade protegem contra falha de instância, não contra erro lógico. Um DELETE destrutivo replica para o standby em minutos, e nenhuma configuração de Multi-AZ desfaz isso; a única defesa contra erro de aplicação é a camada de backup com PITR. Backup e HA respondem a perguntas diferentes e nenhuma substitui a outra.

Automated backups: janela, retenção e PITR nativo

Três configurações definem o comportamento dos automated backups: a janela de backup (backup window), o momento diário preferido para o snapshot completo; a janela de manutenção, separada, para upgrades e patches; e o período de retenção (backup retention period), de 0 a 35 dias, que define por quanto tempo o sistema mantém snapshots e logs de transação.

Com retenção de 1 a 35 dias, o RDS mantém o arquivamento contínuo de logs e o restore to point-in-time fica disponível: é possível restaurar a instância para qualquer segundo dentro do período retido, incluindo a opção latest restorable time, o último instante recuperável calculado pelo serviço. O RPO efetivo dessa configuração é de minutos, limitado pelo intervalo de arquivamento dos logs.

A retenção zero desativa o mecanismo inteiro e é uma configuração proibida em qualquer banco de produção sério, pois não há snapshot diário nem PITR. A retenção máxima de 35 dias é um limite do serviço, e históricos mais longos exigem cópias de snapshots manuais ou exportações para S3.

O restaurado é sempre uma nova instância: o RDS provisiona um endpoint novo e os dados voltam em uma instância com o mesmo identificador de engine, grupo de parâmetros e grupos de segurança configurados na chamada. A instância original permanece intacta, e o redirecionamento do tráfego é decisão operacional, não automática.

O impacto da captura na produção é geralmente subestimado no planejamento de capacidade. A janela de backup concorre com picos noturnos de jobs de ETL e de vacuum, e a prática saudável posiciona o snapshot fora do pico de escrita, monitora a duração real da captura via CloudWatch (métrica SnapshotUsage ou eventos de backup completo) e mantém headroom de IOPS para o flush de buffers que antecede o instante consistente.

# 1. Configura o backup automatizado com retencao de 14 dias
aws rds modify-db-instance \
  --db-instance-identifier producao-app \
  --backup-retention-period 14 \
  --preferred-backup-window "03:10-03:40" \
  --apply-immediately

# 2. Verifica o ultimo instante recuperavel (RPO real observado)
aws rds describe-db-instances \
  --db-instance-identifier producao-app \
  --query 'DBInstances[0].LatestRestorableTime'

# 3. Restaura para um instante especifico, segunda antes do incidente
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier producao-app \
  --db-instance-identifier producao-app-restaurado \
  --restore-time "2024-05-10T14:06:30Z" \
  --db-subnet-group-name subnet-producao \
  --multi-az

# 4. Snapshot manual como ancora pre-deploy
aws rds create-db-snapshot \
  --db-instance-identifier producao-app \
  --db-snapshot-identifier pre-deploy-2024-05-10

Snapshots manuais: âncora de longo prazo

O snapshot manual existe até ser deletado por decisão explícita, e essa propriedade define seus usos principais: preservar o estado pré-migração, criar cópias para ambientes de teste, cumprir requisitos de auditoria que excedem 35 dias e proteger pontos de recuperação estáveis.

A cópia cross-region e cross-account transforma o snapshot no elo de proteção contra falhas regionais e administrativas. A cópia para outra região é incremental entre cópias sucessivas do mesmo snapshot, e a cópia para outra conta isola os dados de quem tem acesso de deleção na conta de origem, padrão de defesa contra ransomware e erro humano.

A exclusão de uma instância com DeleteAutomatedBackups configurado remove os automatizados junto, mas nunca os manuais. Esse comportamento assimétrico é o motivo pelo qual snapshots pré-deploy e âncoras mensais devem sempre ser manuais, com nomes e etiquetas que a governança consiga auditar.

Snapshots também alimentam ambientes de desenvolvimento: restaurar produção em staging com dados reais é uso comum, e o caminho correto é copiar o snapshot, restaurar em instância de teste e aplicar anonimização de dados sensíveis, pois o snapshot carrega o conteúdo integral, incluindo senhas de aplicação e PII.

Backup em região distinta e custo de storage

A cópia cross-region de snapshots e de backups automatizados (recurso de cross-region automated backup configurado por região de destino) atende à estratégia de DR geográfica. A cópia é assíncrona, e o RPO entre regiões é o intervalo de cópia, tipicamente de minutos a horas dependendo do tamanho e da frequência.

O custo tem duas regras principais. Primeira: storage de backup automatizado é gratuito até o tamanho de armazenamento alocado da instância, e cobrado pelo excedente. Segunda: toda cópia cross-region e todo snapshot retido além disso é cobrado por GB-mês, com taxa adicional de transferência de dados entre regiões na cópia.

Em prática, a conta de backup cresce com três multiplicadores: tamanho do banco, número de cópias regionais e duração da retenção excedente. Bancos que mudam muito entre snapshots pagam mais, pois cada cópia incremental retém blocos antigos vivos enquanto a cadeia existir, e a auditoria de custo por região deve entrar na rotina de FinOps.

A escolha de região de destino considera compliance (residência de dados), latência da DR e custo da região alvo. Uma configuração comum é retenção de 7 dias cross-region para bancos menores e cópia diária do snapshot manual para regiões de menor custo em bancos grandes.

Em IaC, as mesmas configurações vivem como código, o que torna a auditoria de retenção parte do pipeline e impede desvios manuais entre ambientes.

# Terraform: backup automatizado, cópia cross-region e snapshot manual em código
resource "aws_db_instance" "producao" {
  identifier              = "producao-app"
  engine                  = "postgres"
  instance_class          = "db.r6g.xlarge"
  allocated_storage       = 500
  backup_retention_period = 14        # janela de PITR de 14 dias
  backup_window           = "03:10-03:40"
  copy_tags_to_snapshot   = true      # propaga etiquetas de governança
  deletion_protection     = true      # bloqueia deleção acidental da instância
  multi_az                = true      # HA de instância, não protege erro lógico
  storage_encrypted       = true
}

resource "aws_db_instance_automated_backups_replication" "dr" {
  source_db_instance_arn = aws_db_instance.producao.arn
  kms_key_id             = var.kms_key_destino  # chave precisa existir na região DR
  pre_signed_url         = var.pre_signed_url
}

Restore: o que acontece e o que revisar

Todo restore no RDS, por snapshot ou por PITR, cria uma instância nova. Nada substitui a instância original, e o fluxo de recuperação real envolve provisionamento, validação de dados e redirecionamento de aplicação. Os pontos que costumam faltar no plano de restore são os detalhes de configuração, não os dados.

• Grupos de parâmetros e de opções não restaurados por padrão: a instância nova nasce com o grupo default se não for especificado na chamada, e parâmetros críticos de performance podem sumir silenciosamente.
• Grupos de segurança e subnets: a rede da instância restaurada precisa ser explicitada, e o endpoint novo exige atualização de DNS, connection string ou descoberta de serviço.
• Versão de engine: restaurar em versão mais nova é possível via upgrade pós-restore, e testar esse caminho evita surpresas de incompatibilidade no dia do incidente.
• Credenciais e segredos: o usuário master é mantido, mas segredos de aplicação em Secrets Manager, chaves de criptografia e certificados precisam estar acessíveis na conta e região do restore.
• Criptografia: snapshot restaurado só pode ser criptografado se a cópia ou o snapshot de origem estiver criptografado, e o KMS key deve existir na região de destino da cópia.

Erros comuns e boas práticas

• Deixar retenção zero em produção por economia de I/O de backup; sem automatizado, o RPO é a frequência dos snapshots manuais, e quase sempre ninguém captura manualmente com disciplina.
• Assumir que 35 dias de retenção cobrem qualquer exigência de auditoria; políticas de compliance frequentemente pedem 12 meses ou mais, o que exige cópias manuais ou exportações para S3 com lifecycle.
• Ignorar o custo de snapshots manuais órfãos, criados por pipelines e nunca deletados; etiquetar com origem e data, e automatizar a expiração via políticas de tag.
• Configurar cópia cross-region sem testar o restore na região de destino; um snapshot inacessível por falta de KMS key ou subnet group na região alvo não é uma DR.
• Restaurar sem especificar parameter group e security group e descobrir o erro como degradação de performance em produção; padronizar a chamada de restore em IaC versionada.
• Confiar na janela preferencial como garantia dura; em janelas de alta demanda a captura pode atrasar, e o alvo de recuperação deve tolerar essa variação.
• Nunca medir o latest restorable time; o atraso entre o instante atual e o último instante recuperável é o RPO real, e monitorá-lo como métrica transforma o backup em SLO observável.
• Tratar o RDS como proteção completa por padrão; o serviço cobre infraestrutura e erro lógico dentro de 35 dias, mas retenção configurada, isolamento de conta e testes de restore continuam sendo responsabilidade do time de plataforma.