Operación
Un respaldo que nunca se restauró no es un respaldo
El archivo .bak existe, pesa lo que corresponde y nadie lo ha abierto en dos años. Cómo montar una prueba de restauración periódica sin tocar la base productiva.
· 6 min de lectura · Equipo ERPBackup
El archivo está ahí. Pesa 8,4 GB, se generó anoche y el correo dice que terminó bien. La pregunta que casi nadie responde con certeza es otra: ¿alguien lo abrió alguna vez?
Un respaldo que nunca se restauró es una promesa, no un respaldo. Y las promesas se descubren falsas justo el día en que no se puede esperar.
Qué falla en un archivo que "existía"
Los casos que se repiten:
- El respaldo corría, pero de una base que dejó de usarse hace dos años. La base productiva actual tiene otro nombre y nunca entró a la programación.
- La copia estaba incompleta porque el destino se quedó sin espacio y nadie leía los correos de error.
- El archivo estaba bien, pero faltaban las carpetas del Terminal Server, así que la base restauró y el sistema quedó sin formatos de impresión.
- Nadie en la empresa sabía el procedimiento, y el único que lo había hecho antes ya no trabajaba ahí.
Ninguno de esos problemas se ve mirando el tamaño del archivo. Todos aparecen a los diez minutos de intentar una restauración de verdad.
Cómo montar la prueba sin tocar producción
La prueba se hace en un equipo aparte. Puede ser una máquina virtual, un servidor de desarrollo o incluso un equipo prestado por una tarde. Lo importante es que no sea el servidor productivo.
El recorrido es el mismo que se seguiría en una emergencia:
- Tomar la copia más reciente desde el destino real, descargándola como lo haría alguien el día del incidente. Si bajarla toma cuatro horas, es un dato valioso: ese tiempo es parte de tu recuperación.
- Restaurar la base con las herramientas nativas de Softland, sin atajos ni scripts especiales.
- Entrar al sistema con un usuario real y revisar tres cosas concretas: que el último documento emitido esté, que los saldos cuadren con lo que se esperaba y que los informes personalizados abran.
- Anotar cuánto demoró todo, de principio a fin.
Ese número final es el RTO, el tiempo de recuperación. Sirve para responder la pregunta que hará la gerencia: cuántas horas estaríamos detenidos.
Cada cuánto conviene hacerlo
Dos veces al año es un mínimo razonable para una instalación estable. Y siempre después de un cambio relevante: una actualización de Softland, un cambio de servidor, una migración de SQL Server o la incorporación de una base nueva.
Vale la pena dejar registro en algo tan simple como una planilla: fecha, quién lo hizo, qué copia se usó, cuánto demoró y qué falló. Ese registro es lo que convierte la prueba en un proceso y no en una anécdota.
Detectar la falla la misma noche
Probar la restauración cada seis meses no reemplaza el control diario. Si un respaldo falla un martes y nadie se entera hasta la prueba semestral, hay meses de copias inexistentes.
Por eso ERPBackup manda un correo por cada ejecución, y el Plan Gestionado agrega un panel donde se ve el estado de cada copia sin tener que revisar la bandeja de entrada.
La combinación que funciona es simple: aviso automático todos los días, prueba de restauración completa un par de veces al año, y una copia fuera del servidor para que haya algo que restaurar.