Copias de seguridad y recuperación a un punto en el tiempo en DynamoDB
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 reescribe eventos, o un borrado masivo accidental, tiene que poder recuperarse al momento anterior al error.
¿Cómo funcionan las copias de seguridad y la recuperación a un punto en el tiempo en DynamoDB?
DynamoDB ofrece dos tipos de copia de seguridad. La recuperación a un punto en el tiempo (PITR) toma copias de seguridad continuas y automáticas, 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 que se conservan indefinidamente. Ambas restauran a una tabla nueva, nunca sobre la original, así que son herramientas de recuperación más que un botón de deshacer en su sitio.
- PITR = copia de seguridad continua, restauración 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 durante el tiempo que quieras, independientes de la ventana de PITR.
- Las restauraciones crean una tabla nueva. Restauras a un nombre nuevo y luego haces la conmutación — la original queda intacta.
- PITR se cobra según el tamaño de la tabla, no por 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 en su sitio
DynamoDB no tiene un registro de transacciones que puedas revertir ni un «deshacer» en
una escritura. Si un script de migración reescribe el campo action de cada evento, o
alguien ejecuta un borrado más amplio de lo previsto, la tabla simplemente queda en un
estado incorrecto. Sin copias de seguridad, los datos se han perdido.
Para un registro de auditoría —cuyo valor entero es ser un registro de confianza— «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 activada, toma copias de seguridad
continuas y automáticas. Según la
documentación de AWS,
PITR «ofrece copias de seguridad continuas, automáticas y totalmente gestionadas de los
datos de la tabla con hasta 35 días de puntos de recuperación con granularidad por
segundo». La ventana es configurable de 1 a 35 días mediante
RecoveryPeriodInDays, y puedes restaurar a cualquier segundo dentro de ella —
incluido a una región distinta.
Un detalle importante: reducir el periodo de recuperación reduce de inmediato el punto de restauración más antiguo, y desactivar y luego volver a activar PITR reinicia el momento recuperable inicial — pierdes el historial continuo anterior.
Las copias de seguridad bajo demanda son aparte: instantáneas manuales de la tabla completa que creas explícitamente y conservas indefinidamente, útiles para un punto de control previo a una migración o para un archivo de cumplimiento a largo plazo más allá de la ventana de 35 días de PITR.
Ambas restauran a una tabla nueva, no sobre la existente:
Un ejemplo práctico: recuperarse de una migración defectuosa
Una migración pensada para añadir un atributo expiresAt sobrescribió en su lugar
action en cada evento con una cadena vacía. PITR está activada con una ventana de 35
días, así que restauras al segundo anterior a que se ejecutara la migración:
| step | result |
|---|---|
| restore PITR to 09:59:00 | new table audit-log-restored with correct actions |
| diff against live | confirm only the migration's rows differ |
| cut app over to restored | original left intact for forensics |
La tabla corrupta queda intacta mientras verificas la restauración — comparas los
eventos restaurados con los activos, confirmas que los valores de action han vuelto y
luego rediriges la app. Nada se destruye en la propia recuperación.
Si la pérdida fuera de un puñado de Items en lugar de una corrupción de toda la tabla, podrías en cambio 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 lo que 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 compararlos con la tabla en vivo antes de hacer la conmutación —
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.
Errores comunes y próximos pasos
- Activa PITR antes de necesitarla. Solo protege desde el momento en que está activa — no hay recuperación retroactiva. Actívala para cualquier tabla cuyos datos no te puedas permitir perder.
- Desactivar PITR reinicia la ventana. Apagarla y volver a encenderla borra el historial continuo; el momento recuperable inicial empieza de nuevo desde la reactivación.
- Las restauraciones no son instantáneas ni gratuitas. Una restauración aprovisiona una tabla completamente nueva 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 regional y PITR para la recuperación de datos. Vuelve a la introducción a Operaciones y coste para ver cómo encajan todos.
Descarga DynoTable para conectarte a una tabla restaurada y verificar tu recuperación antes de confiar en ella.