MongoDB
Explica estrategias de backup y restauración en MongoDB, snapshots consistentes, point-in-time recovery, pruebas de restore y objetivos RPO y RTO.
Un backup es una copia recuperable en un punto distinto del sistema primario. Su valor no se demuestra al crearlo, sino al restaurarlo dentro del tiempo y pérdida aceptables.
backup programado
→ almacenamiento independiente
→ verificación
→ restore test
→ recuperación realReplica sets reducen downtime, pero replican deletes, corrupción lógica y credenciales comprometidas. No sustituyen backups.
Cuánto dato puedes perder. Un RPO de 15 minutos exige una estrategia capaz de recuperar cerca del incidente.
Cuánto tiempo puede tardar el servicio en volver. Incluye descargar, restaurar, reconstruir índices, ejecutar migraciones, validar y redirigir tráfico.
No declares valores sin medirlos mediante ejercicios.
mongodump genera BSON y metadata para restaurar con mongorestore.
Ventajas:
Costes:
Copia consistente de volúmenes o snapshots coordinados. Es rápida para datasets grandes, pero debe respetar la topología y consistencia del storage engine.
No copies archivos de datos en caliente con herramientas genéricas sin un procedimiento soportado.
Conserva snapshots más historia de cambios para recuperar a un instante anterior. Es adecuado ante borrados o corrupción detectados después.
PITR necesita retención, oplog suficiente o servicio administrado compatible y un proceso para elegir el punto correcto.
Un backup de un sistema con múltiples colecciones debe conservar una vista coherente para el caso de uso. Si una orden se copia pero su movimiento de inventario no, el restore puede violar invariantes.
Las herramientas y plataformas ofrecen mecanismos distintos. Verifica:
Además de documentos:
Un backup de ciphertext sin key vault/KMS recuperable es inútil.
Diseña niveles:
horarios → 48 horas
diarios → 30 días
semanales → 3 meses
mensuales → 1 añoLa política depende de regulación, coste y tiempo de detección. Backups antiguos también contienen PII eliminada; incluye expiración y borrado seguro.
Guarda copias fuera del mismo cluster, cuenta o región de fallo. Cuando sea posible utiliza:
Si un atacante con credenciales de producción puede borrar todos los backups, no existe una frontera real.
Runbook mínimo:
No restaures directamente sobre producción sin preservar evidencia y un plan de retorno.
Recupera cluster o database completa. Es más coherente, pero tarda más y puede sobrescribir datos válidos.
Recupera una colección o documentos. Necesita comprender referencias, eventos, índices y efectos posteriores. Restaurar una orden borrada sin sus pagos o movimientos puede ser incorrecto.
Elegir un timestamp exige saber cuándo empezó la corrupción, no cuándo se detectó. Usa logs, audit trail y eventos para identificar el último punto sano.
Después del restore pueden existir writes legítimos posteriores que deban re-aplicarse. Define reconciliación o replay.
Un backup debe coordinar:
Usa mecanismos soportados. Copias independientes sin coordinación pueden producir ownership inconsistente.
Ejecuta periódicamente un restore aislado y mide:
Un checksum de archivo no prueba que la aplicación funcione.
Comprueba:
El restore necesita espacio adicional para:
No esperes al incidente para descubrir que no existe un cluster destino suficientemente grande.
Backups protegen contra pérdida y corrupción lógica solo cuando son independientes, retenidos y restaurables. RPO define pérdida aceptable; RTO define tiempo de recuperación. La prueba definitiva incluye datos, índices, claves, aplicación y reconciliación, no únicamente un archivo creado sin error.
Importación y exportación.