Backup y Point-in-Time Recovery en DynamoDB: la guía completa

DynamoDB protege tus datos de dos formas. Las copias de seguridad bajo demanda son instantáneas completas que tomas y conservas indefinidamente. La recuperación a un punto en el tiempo (PITR) es una copia de seguridad continua y automática que te permite restaurar la tabla a cualquier segundo dentro de una ventana móvil. Ambas restauran a una tabla nueva — son herramientas de recuperación, no un botón de deshacer.

Para el registro de auditoría esto no es negociable. Es un registro de cumplimiento inmutable; una migración defectuosa que reescriba eventos, o una eliminación masiva accidental, tiene que ser recuperable hasta el momento anterior al error.

¿Cómo funcionan las copias de seguridad y la recuperación a un punto en el tiempo de DynamoDB?

DynamoDB ofrece dos tipos de copia de seguridad. La recuperación a un punto en el tiempo (PITR) toma copias de seguridad automáticas y continuas, lo que te permite restaurar a cualquier segundo dentro de una ventana configurable de 1 a 35 días. Las copias de seguridad bajo demanda son instantáneas completas manuales conservadas indefinidamente. Ambas restauran a una tabla nueva, nunca sobre la original, así que son herramientas de recuperación en lugar de un deshacer in situ.

• PITR = copia de seguridad continua, restaura a cualquier segundo dentro de una ventana configurable de 1 a 35 días (antes era un valor fijo de 35).
• Copias de seguridad bajo demanda = instantáneas completas manuales conservadas todo el tiempo que quieras, independientes de la ventana de PITR.
• Las restauraciones crean una tabla nueva. Restauras a un nombre nuevo y luego conmutas — la original queda intacta.
• PITR se cobra según el tamaño de la tabla, no según el número de puntos de restauración — estímalo con la calculadora de precios de DynamoDB.

El problema: un error que no puedes deshacer in situ

DynamoDB no tiene ningún registro de transacciones que puedas revertir ni "deshacer" en una escritura. Si un script de migración reescribe el campo action de cada evento, o alguien ejecuta una eliminación más amplia de lo previsto, la tabla queda simplemente en el estado equivocado. Sin copias de seguridad, los datos desaparecen.

Para un registro de auditoría — cuyo valor entero es ser un registro fiable — "no podemos recuperar los eventos del martes pasado" es un fallo de cumplimiento, no solo una molestia.

Cómo funcionan las copias de seguridad y PITR

La recuperación a un punto en el tiempo, una vez habilitada, toma copias de seguridad automáticas y continuas. Según la documentación de AWS, PITR te da copias de seguridad continuas totalmente gestionadas de los datos de la tabla con granularidad de restauración por segundo. La ventana es configurable de 1 a 35 días vía RecoveryPeriodInDays, y puedes restaurar a cualquier segundo dentro de ella — hasta unos cinco minutos por detrás del tiempo real (LatestRestorableDateTime) — incluso a una región distinta.

Un caso límite importante: reducir el periodo de recuperación reduce de inmediato el punto de restauración más temprano, y deshabilitar y luego volver a habilitar PITR reinicia el tiempo de inicio recuperable — pierdes el historial continuo anterior.

PITR también condiciona la exportación gestionada a S3: la exportación lee de las mismas copias de seguridad continuas, así que con PITR desactivado, ExportTableToPointInTime falla con PointInTimeRecoveryUnavailableException.

Las copias de seguridad bajo demanda son aparte: instantáneas manuales de la tabla completa que creas explícitamente y retienes indefinidamente, útiles para un punto de control previo a una migración o un archivo de cumplimiento a largo plazo más allá de la ventana de 35 días de PITR. La petición se procesa al instante y la copia queda restaurable en cuestión de minutos, no consume nada del rendimiento de la tabla y no hay límite en cuántas conservas. Un matiz honesto que sale de la documentación: las copias bajo demanda no garantizan consistencia causal entre Items — el desfase entre actualizaciones es "usually much less than a second", pero una copia tomada en mitad de una ráfaga de escrituras no es un único instante congelado.

Lo que una restauración no recupera

Una restauración recrea los datos de la tabla y sus índices, no su cableado operativo. Según la documentación de AWS, tienes que reconfigurar manualmente en la tabla restaurada: las políticas de auto-escalado, las políticas de IAM, las métricas y alarmas de CloudWatch, las etiquetas, la configuración de streams, TTL, la protección contra eliminación y el propio PITR. Restaurar desde una copia y olvidarte de volver a activar PITR es justo lo que convierte el siguiente incidente en irrecuperable.

En el momento de restaurar puedes cambiar algunos ajustes a propósito — el modo de facturación, la capacidad aprovisionada, las claves de cifrado — y puedes excluir algunos índices secundarios o todos, lo que hace la restauración más rápida y barata si puedes reconstruirlos después. Las restauraciones también pueden apuntar a una región distinta, y una restauración nunca sobrescribe una tabla existente.

Copias de seguridad programadas con AWS Backup

Las copias bajo demanda propias de DynamoDB no tienen programador. Para copias recurrentes con retención, DynamoDB se integra de forma nativa con AWS Backup (documentación de AWS): los planes de copia te dan copias programadas con reglas de ciclo de vida (incluido el paso a almacenamiento en frío), copias automáticas entre cuentas y entre regiones para recuperación ante desastres, una clave de KMS independiente a través del almacén de copias, y Vault Lock para una postura de cumplimiento WORM que nadie pueda borrar en silencio. Dos detalles operativos: AWS Backup exige una activación explícita por cuenta y por región, y las copias que crea (de tipo AWS_BACKUP) no se pueden eliminar desde la consola de DynamoDB — gestiónalas en AWS Backup.

Ambas restauran a una tabla nueva, no sobre la existente:

Un ejemplo trabajado: recuperarse de una migración defectuosa

Una migración destinada a añadir un atributo expiresAt en su lugar sobrescribió action en cada evento con una cadena vacía. PITR está activado con una ventana de 35 días, así que restauras al segundo anterior a la ejecución de la migración:

La tabla corrupta permanece intacta mientras verificas la restauración — comparas los eventos restaurados con los en vivo, confirmas que los valores de action han vuelto y luego reapuntas la aplicación. Nada se destruye en la recuperación en sí.

Si la pérdida fuera un puñado de Items en lugar de una corrupción de toda la tabla, podrías en su lugar inspeccionar los datos en vivo y la copia restaurada y copiar solo las filas afectadas — consulta copiar una tabla de DynamoDB.

Hazlo en DynoTable

Una restauración solo vale tanto como tu verificación de ella. Después de restaurar a audit-log-restored, necesitas mirar de verdad los eventos recuperados y confirmar que coinciden con lo que deberían haber sido antes del error.

DynoTable se conecta a la tabla restaurada como a cualquier otra, así que puedes consultar los eventos del tenant afectado, confirmar que los valores de action son correctos y comparar contra la tabla en vivo antes de conmutar — convirtiendo una restauración de un acto de fe en una recuperación verificada.

También puedes exportar los eventos recuperados para un registro de cumplimiento sin conexión — consulta exportar DynamoDB a CSV.

Escollos y próximos pasos

• Habilita PITR antes de necesitarlo. Solo protege desde el momento en que está activado — no hay recuperación retroactiva. Actívalo para cualquier tabla cuyos datos no puedas permitirte perder.
• Deshabilitar PITR reinicia la ventana. Apagarlo y volverlo a encender borra el historial continuo; el tiempo de inicio recuperable comienza de nuevo desde la reactivación.
• Las restauraciones no son instantáneas ni gratis. Una restauración aprovisiona una tabla nueva entera y tarda un tiempo proporcional al tamaño; presupuesta la duración y la tabla extra.
• 35 días no es archivado. Para retención más allá de la ventana de PITR, toma copias de seguridad bajo demanda o exporta a S3 — PITR es una ventana de recuperación, no almacenamiento a largo plazo.

Eso cierra el bucle de operaciones del registro de auditoría: transacciones para la consistencia, Streams para la reacción, TTL para la expiración, el modo de capacidad adecuado para el coste, global tables para la resiliencia por región y PITR para la recuperación de datos. Revisa la visión general de Operaciones y coste para ver cómo encajan todos juntos.

Descarga DynoTable para conectarte a una tabla restaurada y verificar tu recuperación antes de confiar en ella.