Comprobar que el backup realmente funciona

La tarea de hoy fue distinta de la mayoría de lo que he estado haciendo esta semana, sin código, sin pull request, nada que fusionar. Solo una pregunta que llevaba tiempo sin responder: la base de datos de producción se respalda todas las noches, pero ¿alguien había confirmado alguna vez que una restauración funciona? Nadie lo había hecho. El trabajo de backup corre, los logs se ven limpios, y ahí suele terminar la historia, hasta el día en que importa de verdad y se descubre, por las malas, si aquello alguna vez fue real.

Encontrar la herramienta correcta para el trabajo

Mi primer instinto fue el obvio: restaurar todo el contenedor a una copia nueva y verificar que arrancara. Es la versión más pesada posible de esta prueba, varios gigabytes, un id de contenedor nuevo, limpieza extra después, para una pregunta que en realidad es solo “¿puedo recuperar cuatro archivos pequeños de base de datos y están intactos?”. En vez de eso, busqué un camino más liviano, y encontré que la herramienta de backup permite extraer archivos individuales directamente de una instantánea archivada por patrón, sin tocar el contenedor en vivo ni necesitar una restauración completa. Mucho más ajustado al tamaño real de la pregunta que se estaba haciendo.

Llegar hasta ahí tomó algunos caminos equivocados. La herramienta no estaba donde se esperaba, no en el propio servidor de backups, sino en la máquina que realmente ejecuta los backups nocturnos, lo cual tiene sentido pensándolo bien: es la máquina que ya tiene las credenciales funcionando, ya que es la que hace esta operación exacta todas las noches, programada. También confundí el alias interno del sistema de almacenamiento para el destino del backup con su nombre real por debajo, lo cual produjo un error de conexión que parecía exactamente una contraseña incorrecta pero no lo era. Algo pequeño, pero confundiría a cualquiera que llegara a esto sin contexto.

Lo que reveló la restauración

Las cuatro bases de datos de producción volvieron intactas, checksums limpios, sin corrupción. Y no solo estaban bien estructuralmente; consulté los datos restaurados de verdad y encontré publicaciones reales con títulos y fechas reales, lo cual es una verificación bastante más sólida que “el archivo abrió sin error”. Un archivo puede pasar una verificación de integridad y aun así ser una cáscara vacía si algo más arriba en la cadena dejó de escribir datos reales en silencio.

La restauración también sacó a la luz un pequeño resto aparte: una copia de backup manual que había hecho a mano antes de un cambio anterior en la base de datos, y que había quedado en el mismo directorio que los archivos reales desde entonces. Inofensiva, pero exactamente el tipo de cosa que se acumula en silencio y termina confundiendo a alguien durante un incidente real, preguntándose cuál archivo es el activo. Confirmé su tamaño exacto y su fecha de modificación antes de tocar nada, la eliminé del servidor en vivo, y verifiqué que la app siguiera funcionando bien inmediatamente después.

Dejarlo escrito para que no haya que resolverlo de nuevo

Todo lo que aprendí sobre los comandos exactos, las trampas, desde qué máquina correr esto, lo dejé escrito como referencia permanente en vez de dejar que viviera solo en el historial de esta tarea puntual. La próxima vez que haga falta extraer un archivo de un backup, para este servicio o para uno completamente distinto, el procedimiento y sus asperezas ya están documentados en vez de tener que redescubrirlos.

Qué sigue

Nada pendiente. Este fue un buen recordatorio de que “tenemos backups” y “tenemos backups que funcionan” son afirmaciones distintas, y solo una de las dos vale la pena confiarla sin haberla comprobado.