Eran las 3 de la mañana cuando me llamaron de FONTUR. El portal de turismo estaba caído. Llevaba dos años con esa responsabilidad y creía tener todo bajo control: backups automáticos, alertas configuradas, documentación al día. Pero cuando intenté restaurar, descubrí que ninguno de esos backups realmente funcionaba.
No había probado una restauración en producción en ese tiempo. De una, me di cuenta de que los archivos estaban comprimidos pero corruptos. La base de datos tenía inconsistencias. Los permisos del servidor no coincidían. ¿Qué había estado haciendo todos esos meses?
Esa noche aprendí algo que debería ser obvio pero nadie enseña: un backup que no has restaurado es un backup que no existe. Punto. Y aunque suene duro, es la verdad que necesita escuchar cualquiera que administre un portal público.
Lo que hice mal (y cómo lo arreglé)
Mi estrategia anterior era típica: ejecutar mysqldump cada 24 horas, guardar archivos de Drupal en otro disco, rezar para que funcionara. Cuando llegó el desastre, descubrí los vacíos. Los backups no incluían la configuración del servidor. No tenía registro de las versiones de PHP o extensiones que usaba. Los permisos de carpetas no se restauraban automáticamente.
La restauración manual tomaba horas. Y eso en el mejor escenario.
Ahora trabajo distinto. Primero: tengo un script que valida la integridad del backup inmediatamente después de crearlo. Segundo: cada mes hago una restauración de prueba en un servidor espejo —aunque sea un servidor pequeño—. Tercero: documento todo. Los pasos exactos. Las versiones. Los módulos críticos. Las configuraciones personalizadas que no están en el código.
Y aunque haya mejorado, todavía no entiendo por qué tantas instituciones del Estado siguen con backups sin probar. ¿Es falta de tiempo? ¿De presupuesto? ¿De que alguien les haya dicho que es importante hacerlo de verdad?
El detalle que marca diferencia
Trabajé en la Secretaría Jurídica Distrital con un portal que manejaba documentos públicos sensibles. El sistema debía cumplir requisitos de auditoría que eran bastante exigentes. Aprendí a separar los backups en capas: base de datos, archivos públicos, archivos privados, configuración del servidor, logs de auditoría. Cada capa con su propio schedule y su propio método de validación.
Sonará engorroso. Es engorroso. Pero cuando necesitas restaurar solo la base de datos sin tocar los archivos subidos recientemente, esa separación te salva horas de trabajo y posibles pérdidas de datos.
Y algo bacano que implementé después: un dashboard simple que muestra el estado real de cada backup. No que "se ejecutó". Sino que se validó, se almacenó, y se puede restaurar en menos de X tiempo. Eso sí tranquiliza.
Lo que sigue abierto
Todavía cometo errores. Hace poco, un backup de Drupal 10 falló silenciosamente porque cambió la estructura de directorios y mi script viejo no lo detectó. Lo descubrí por accidente.
Me equivoqué cuando asumí que un backup automático es un backup seguro. La automatización es solo el comienzo. Lo importante es lo que haces después: validar, probar, documentar, revisar, mejorar. Ojo con eso.