Por qué auditar los backups regularmente

Un backup que no se verifica periódicamente puede fallar por razones silenciosas: el proceso de backup terminó con error pero el script no verificó el exit code; el archivo se guardó en una ruta que casi no tiene espacio; la clave de cifrado cambió y ya no se puede descifrar; la retención borró los archivos antes del período esperado; o las extensiones o versiones entre el origen y el destino cambiaron.

Una auditoría de backups no busca una imagen del estado del sistema; busca evidencia de que el backup funcionará cuando se necesite.

Señales de que los backups tienen problemas

  • El último backup exitoso es de hace más de 24 horas para bases críticas
  • El script de backup no verifica el exit code y nunca ha generado una alerta
  • Los archivos de backup tienen tamaños anormalmente pequeños o uniformes (señal de backups vacíos)
  • No hay alertas configuradas para cuando un backup falla
  • Nadie en el equipo recuerda la última vez que se probó una restauración real
  • Los logs de transacciones (SQL Server, Oracle) no se incluyen en la estrategia de backup

Checklist de auditoría — PostgreSQL

  • 1. Verificar éxito del último backup y su tamaño
  • 2. Verificar integridad del archivo de backup
  • 3. Verificar estado del archivado de WAL (para PITR)
  • 4. Verificar que archive_mode está habilitado si se requiere PITR

Checklist de auditoría — SQL Server

  • 5. Verificar backups recientes por base de datos
  • 6. Verificar backups de log de transacciones (para RPO bajo)
  • 7. Verificar integridad del último backup
  • 8. Verificar si algún backup está marcado como dañado

Checklist de auditoría — Oracle

  • 9. Verificar backups RMAN recientes
  • 10. Listar y validar backups desde RMAN

Aspectos generales de la auditoría (todos los motores)

  • 11. Verificar ubicación y separación física del almacenamiento El backup no debe estar en el mismo servidor que la base de datos. Confirmar que hay al menos un destino remoto (nube, NFS externo, cinta).
  • 12. Verificar cifrado de backups Especialmente crítico si el almacenamiento de backup es compartido o en la nube con acceso amplio. Verificar que la clave de descifrado está disponible en un lugar separado del backup.
  • 13. Verificar retención: ni muy corta ni muy larga sin justificación Una retención de 1 día puede ser insuficiente para detectar corrupción de datos silenciosa. Una retención de 1 año sin política de archivo puede crecer hasta ocupar terabytes sin control.
  • 14. Confirmar que existe una alerta automática para backups fallidos Un backup fallido que nadie detecta puede dejar la empresa sin protección por días o semanas. La alerta debe enviarse por correo o canal de monitoreo con suficiente urgencia para generar acción inmediata.
  • 15. Realizar una restauración de prueba mensual en servidor aislado La única prueba real es restaurar y verificar que los datos son correctos y el tiempo de recuperación cumple el RTO. Documentar el resultado de cada prueba.

Señales de alerta que requieren acción inmediata

  • El último backup exitoso tiene más de 48 horas de antigüedad para una base de datos de producción
  • El proceso de backup lleva días fallando silenciosamente sin alertas generadas
  • Una prueba de restauración reciente falló y no hay backup alternativo válido
  • El espacio de almacenamiento de backups está por encima del 90% y la retención no se está aplicando correctamente
  • Los logs de transacciones (SQL Server) o los archivos WAL (PostgreSQL) no se están archivando, haciendo imposible PITR

Preguntas frecuentes

¿Qué diferencia hay entre verificar un backup y probarlo?

Verificar un backup significa comprobar que el archivo no está corrupto y puede leerse correctamente (pg_restore --list, RESTORE VERIFYONLY, RMAN VALIDATE). Probarlo significa hacer una restauración real completa en un servidor aislado y confirmar que la base de datos arranca, los datos son correctos y el tiempo total de recuperación cumple el RTO. Solo la prueba real garantiza que el backup es útil cuando se necesita. La verificación de integridad es el mínimo; la prueba de restauración es el estándar.

¿Cada cuánto debo verificar la integridad de los backups?

La verificación automática de integridad del archivo debe hacerse inmediatamente después de cada backup. La prueba de restauración completa en un servidor aislado debe hacerse al menos mensualmente para sistemas críticos. Si el tiempo y los recursos lo permiten, una restauración semanal en un entorno de staging es la mejor práctica para sistemas críticos para el negocio.

¿Los backups deben estar cifrados?

Sí, especialmente si contienen datos personales, financieros o sujetos a regulaciones como Habeas Data, GDPR, PCI-DSS o SOC 2. Un backup sin cifrar almacenado en un sistema de archivos compartido o en la nube expone los datos a cualquier persona con acceso al almacenamiento. El cifrado debe aplicarse antes de la transferencia al destino externo, y la clave de descifrado debe almacenarse en un lugar diferente al backup (gestor de secretos, HSM, o al menos un repositorio separado).

¿Cuántos días de retención son suficientes?

Depende del RPO, los requisitos regulatorios y la capacidad de detección de errores. Para la mayoría de los sistemas: 7 días de backups diarios permite recuperarse de un error detectado con hasta una semana de retraso; 4 semanas permite cubrir ciclos de reporte mensual. Algunos reguladores exigen retención de 1 a 7 años para datos financieros o médicos. La política debe definirse con el área legal y de cumplimiento, no solo con el equipo técnico.

Recursos relacionados