Backup e Point-in-Time Recovery no DynamoDB: o guia completo

O DynamoDB protege seus dados de duas maneiras. Backups sob demanda são snapshots completos que você tira e mantém indefinidamente. Point-in-time recovery (PITR) é backup contínuo e automático que permite restaurar a tabela para qualquer segundo dentro de uma janela deslizante. Ambos restauram para uma tabela nova — são ferramentas de recuperação, não um botão de desfazer.

Para o log de auditoria isso é inegociável. É um registro de conformidade imutável; uma migração ruim que reescreve eventos, ou uma exclusão em massa acidental, tem que ser recuperável até o momento anterior ao erro.

Como funcionam o backup e o point-in-time recovery do DynamoDB?

O DynamoDB oferece dois tipos de backup. O point-in-time recovery (PITR) tira backups automáticos contínuos, permitindo restaurar para qualquer segundo dentro de uma janela configurável de 1 a 35 dias. Backups sob demanda são snapshots completos manuais mantidos indefinidamente. Ambos restauram para uma tabela nova, nunca sobre a original, então são ferramentas de recuperação em vez de um desfazer no lugar.

• PITR = backup contínuo, restauração para qualquer segundo dentro de uma janela configurável de 1 a 35 dias (antes eram fixos 35).
• Backups sob demanda = snapshots completos manuais mantidos pelo tempo que você quiser, independentes da janela do PITR.
• Restaurações criam uma tabela nova. Você restaura para um nome novo, depois faz o cut over — a original fica intocada.
• O PITR é tarifado pelo tamanho da tabela, não pelo número de pontos de restauração — estime-o com a Calculadora de Preços do DynamoDB.

O problema: um erro que você não pode desfazer no lugar

O DynamoDB não tem log de transações que você possa reverter e não tem "desfazer" numa gravação. Se um script de migração reescreve o campo action de cada evento, ou alguém roda uma exclusão mais ampla do que o pretendido, a tabela simplesmente fica no estado errado. Sem backups, os dados se foram.

Para um log de auditoria — cujo valor inteiro é ser um registro confiável — "não conseguimos recuperar os eventos da última terça" é uma falha de conformidade, não apenas um inconveniente.

Como funcionam o backup e o PITR

O point-in-time recovery, uma vez habilitado, tira backups automáticos contínuos. Conforme as docs da AWS, o PITR te dá backups contínuos totalmente gerenciados dos dados da tabela com granularidade de restauração por segundo. A janela é configurável de 1 a 35 dias via RecoveryPeriodInDays, e você pode restaurar para qualquer segundo dentro dela — até cerca de cinco minutos atrás do tempo real (LatestRestorableDateTime) — inclusive para uma região diferente.

Uma nuance importante: diminuir o período de recuperação reduz imediatamente o ponto de restauração mais antigo, e desabilitar e depois reabilitar o PITR reseta o tempo de início recuperável — você perde o histórico contínuo anterior.

O PITR também condiciona a exportação gerenciada para o S3: a exportação lê dos mesmos backups contínuos, então com o PITR desligado, a ExportTableToPointInTime falha com PointInTimeRecoveryUnavailableException.

Os backups sob demanda são separados: snapshots manuais de tabela inteira que você cria explicitamente e retém indefinidamente, úteis para um checkpoint pré-migração ou um arquivo de conformidade de longo prazo além da janela de 35 dias do PITR. A requisição é processada instantaneamente e o backup fica restaurável em minutos, não consome nada do throughput da tabela e não há limite de quantos você mantém. Uma ressalva honesta da documentação: backups sob demanda não garantem consistência causal entre itens — a defasagem entre as atualizações é "usually much less than a second", mas um backup tirado no meio de uma rajada de escritas não é um único instante congelado.

O que uma restauração não traz de volta

Uma restauração recria os dados da tabela e seus índices — não a sua fiação operacional. Segundo a documentação da AWS, você precisa reconfigurar manualmente na tabela restaurada: políticas de auto scaling, políticas de IAM, métricas e alarmes do CloudWatch, tags, configurações de stream, TTL, proteção contra exclusão e o próprio PITR. Restaurar de um backup e esquecer de reabilitar o PITR é como o próximo incidente se torna irrecuperável.

No momento da restauração você pode mudar deliberadamente algumas configurações — modo de cobrança, capacidade provisionada, chaves de criptografia — e pode excluir alguns ou todos os índices secundários, o que deixa a restauração mais rápida e barata se você puder reconstruí-los depois. As restaurações também podem ter como destino uma Região diferente, e uma restauração nunca sobrescreve uma tabela existente.

Backups agendados com o AWS Backup

Os backups sob demanda do próprio DynamoDB não têm agendador. Para backups recorrentes com retenção, o DynamoDB se integra nativamente ao AWS Backup (documentação da AWS): os planos de backup dão a você backups agendados com regras de ciclo de vida (incluindo a camada de armazenamento frio), cópias automáticas entre contas e entre Regiões para DR, uma chave KMS independente através do cofre de backup e o Vault Lock para uma postura de conformidade WORM que ninguém consegue apagar discretamente. Duas pegadinhas operacionais: o AWS Backup exige opt-in explícito por conta e por Região, e os backups que ele cria (tipo AWS_BACKUP) não podem ser excluídos pelo console do DynamoDB — gerencie-os no AWS Backup.

Ambos restauram para uma tabela nova, não sobre a existente:

Um exemplo prático: recuperando de uma migração ruim

Uma migração que pretendia adicionar um atributo expiresAt em vez disso sobrescreveu action em cada evento com uma string vazia. O PITR está ligado com uma janela de 35 dias, então você restaura para o segundo anterior à execução da migração:

A tabela corrompida fica intocada enquanto você verifica a restauração — você compara os eventos restaurados com os ao vivo, confirma que os valores de action voltaram, depois reaponta o app. Nada é destruído na própria recuperação.

Se a perda fosse um punhado de itens em vez de uma corrupção de tabela inteira, você poderia em vez disso inspecionar os dados ao vivo e a cópia restaurada e copiar só as linhas afetadas — veja copiar uma tabela do DynamoDB.

Faça isso no DynoTable

Uma restauração só vale tanto quanto a sua verificação dela. Depois de restaurar para audit-log-restored, você precisa de fato olhar os eventos recuperados e confirmar que eles combinam com o que deveriam ter sido antes do erro.

O DynoTable se conecta à tabela restaurada como a qualquer outra, então você pode consultar os eventos do tenant afetado, confirmar que os valores de action estão corretos e comparar com a tabela ao vivo antes de fazer o cut over — transformando uma restauração de um salto de fé em uma recuperação verificada.

Você também pode exportar os eventos recuperados para um registro de conformidade offline — veja exportar DynamoDB para CSV.

Armadilhas e próximos passos

• Habilite o PITR antes de precisar dele. Ele só protege a partir do momento em que está ligado — não há recuperação retroativa. Ligue-o para qualquer tabela cujos dados você não pode se dar ao luxo de perder.
• Desabilitar o PITR reseta a janela. Desligá-lo e religá-lo apaga o histórico contínuo; o tempo de início recuperável recomeça a partir da reativação.
• Restaurações não são instantâneas nem gratuitas. Uma restauração provisiona uma tabela inteiramente nova e leva tempo proporcional ao tamanho; orce a duração e a tabela extra.
• 35 dias não é arquivamento. Para retenção além da janela do PITR, tire backups sob demanda ou exporte para o S3 — o PITR é uma janela de recuperação, não armazenamento de longo prazo.

Isso fecha o ciclo de operações do log de auditoria: transações para consistência, Streams para reação, TTL para expiração, o modo de capacidade certo para custo, global tables para resiliência regional e PITR para recuperação de dados. Revisite a visão geral de Operações e Custo para ver como eles se encaixam.

Baixe o DynoTable para se conectar a uma tabela restaurada e verificar sua recuperação antes de confiar nela.