Backup e Point-in-Time Recovery do DynamoDB

O DynamoDB protege seus dados de duas formas. Os backups on-demand são snapshots completos que você faz e mantém indefinidamente. O point-in-time recovery (PITR) é um backup contínuo e automático que permite restaurar a tabela para qualquer segundo dentro de uma janela móvel. 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 deleção em massa acidental, precisa 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) faz backups automáticos e contínuos, permitindo restaurar para qualquer segundo dentro de uma janela configurável de 1 a 35 dias. Os backups on-demand são snapshots completos e manuais, mantidos indefinidamente. Ambos restauram para uma tabela nova, nunca por cima da original, então são ferramentas de recuperação, não 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 era fixa em 35).
• Backups on-demand = snapshots completos manuais mantidos pelo tempo que você quiser, independentes da janela do PITR.
• Restaurações criam uma tabela nova. Você restaura para um novo nome e então faz o corte — a original fica intacta.
• O PITR é cobrado pelo tamanho da tabela, não pelo número de pontos de restauração — estime isso com a Calculadora de Preços do DynamoDB.

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

O DynamoDB não tem um log de transações que você possa reverter nem um "desfazer" em uma escrita. Se um script de migração reescreve o campo action de todos os eventos, ou alguém roda uma deleçã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 terça-feira passada" é uma falha de conformidade, não apenas um incômodo.

Como o backup e o PITR funcionam

O point-in-time recovery, uma vez ativado, faz backups automáticos contínuos. Segundo a documentação da AWS, o PITR "fornece backups contínuos automáticos e totalmente gerenciados dos dados da tabela com até 35 dias de pontos de recuperação com granularidade de segundo". A janela é configurável de 1 a 35 dias via RecoveryPeriodInDays, e você pode restaurar para qualquer segundo dentro dela — inclusive para uma região diferente.

Um detalhe importante: diminuir o período de recuperação reduz imediatamente o ponto de restauração mais antigo, e desativar e reativar o PITR redefine o horário inicial recuperável — você perde o histórico contínuo anterior.

Os backups on-demand são separados: snapshots manuais e completos da tabela 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.

Ambos restauram para uma tabela nova, não por cima da existente:

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

Uma migração que deveria adicionar um atributo expiresAt em vez disso sobrescreveu action em todos os eventos 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 intacta enquanto você verifica a restauração — você compara os eventos restaurados com os ao vivo, confirma que os valores de action voltaram e então reaponta o app. Nada é destruído na recuperação em si.

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 apenas as linhas afetadas — veja copiar uma tabela do DynamoDB.

Faça no DynoTable

Uma restauração só vale o quanto você a verifica. Depois de restaurar para audit-log-restored, você precisa realmente olhar para os eventos recuperados e confirmar que eles correspondem ao que deveriam ser 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 corte — 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

• Ative 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 perder.
• Desativar o PITR redefine a janela. Desligá-lo e religá-lo apaga o histórico contínuo; o horário inicial recuperável começa de novo a partir da reativação.
• As restaurações não são instantâneas nem gratuitas. Uma restauração provisiona uma tabela totalmente nova e leva tempo proporcional ao tamanho; reserve orçamento para a duração e a tabela extra.
• 35 dias não é arquivamento. Para retenção além da janela do PITR, faça backups on-demand 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 de região e PITR para recuperação de dados. Revisite a visão geral de Operações e Custo para ver como elas se encaixam.

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