El respaldo existía. Restaurar iba a tomar once días
Caso real, anonimizado: una empresa industrial con respaldos que corrían todas las noches y se completaban sin errores. Nadie había cronometrado nunca una restauración. Cuando lo hicimos, el tiempo de recuperación era de entre nueve y once días. Qué encontramos, qué se cambió y qué revisar en tu empresa esta semana.
El encargo
Una empresa industrial nos pidió una auditoría de infraestructura. No había pasado nada: querían saber en qué estado estaban antes de que pasara. Ese solo hecho ya las pone en el grupo minoritario de las que revisan mientras todo funciona.
Publicamos el caso sin nombre ni detalles que permitan identificarlas, porque lo que encontramos no es particular de esa empresa. Lo hemos visto tantas veces que se ha vuelto un patrón.
Lo que estaba bien
Conviene decirlo primero, porque no era un desastre: los respaldos existían y funcionaban. Corrían todas las noches, terminaban sin errores, quedaban registrados y ocupaban lo que tenían que ocupar. Si mirabas el panel, todo estaba en verde.
El personal técnico hacía su trabajo. El problema no era negligencia. Era una pregunta que nadie había hecho.
La pregunta que faltaba
La pregunta no es “¿tenemos respaldos?”. Es “¿cuánto tardamos en volver a operar?”.
Ese número tiene nombre técnico —RTO, tiempo objetivo de recuperación— y la mayoría de las empresas no lo tiene medido. Tienen una intuición: “un día, quizá dos”. La intuición viene de imaginar la restauración, no de haberla hecho.
Nosotros la hicimos. Sobre el papel primero, cronometrando cada paso después. El resultado fue entre nueve y once días para volver a la operación normal.
De dónde salían once días
No de un solo problema. De la suma de varios, y ninguno era evidente por separado:
Todo vivía en el mismo lugar. Los respaldos estaban en la misma sala que los servidores que respaldaban. Perfecto para restaurar un archivo borrado por error; inútil ante lo que realmente hace perder una empresa: un incendio, un robo, una inundación, un cifrado por ransomware que alcanza también a las copias.
No había copia fuera de sitio. O sea, no había plan para el escenario que justifica todo el esfuerzo de respaldar.
La ventana nocturna no alcanzaba. Los trabajos de respaldo se ejecutaban uno detrás de otro porque el sistema los serializa, no en paralelo como suponía el calendario. Sumados, se pasaban de la madrugada, y los últimos de la fila terminaban tarde o no terminaban.
La secuencia de restauración no estaba escrita. Qué se levanta primero, qué depende de qué, qué credenciales hacen falta y en qué orden. Sin eso, una recuperación se convierte en investigación — y la investigación se hace justo el día en que nadie tiene la cabeza para investigar.
Once días no es el tiempo de copiar los datos de vuelta. Es el tiempo de averiguar cómo hacerlo mientras la empresa está parada.
Lo que se hizo
Nada exótico. La regla de siempre, aplicada de verdad:
Tres copias, en dos medios distintos, una fuera de sitio. Se sumó una segunda copia local en un sistema independiente del principal —para que un fallo del respaldo no se lleve también al respaldo del respaldo— y una copia externa fuera de las instalaciones, cifrada, para el escenario en que el edificio deja de estar disponible.
Se ordenó la ventana. Conociendo que los trabajos se serializan, se replanificaron los horarios y las prioridades para que todo cierre dentro de la madrugada, con margen.
Se escribió el procedimiento de restauración y se probó. No se leyó: se ejecutó.
Se limpió lo que sobraba. De paso aparecieron unos 355 GB ocupados por copias antiguas que ya no respaldaban nada. Espacio que volvió a estar disponible sin comprar un disco.
El tiempo de recuperación pasó de días a horas.
El punto que generaliza
Si te llevas una sola frase de este artículo, que sea esta:
Un respaldo no está verificado hasta que lo restauras.
Ver el trabajo en verde no es verificarlo. Ver el archivo con el tamaño correcto no es verificarlo. Nos ha tocado encontrar un respaldo “exitoso” que pesaba veinte bytes: el proceso terminaba bien, el archivo existía, y adentro no había nada. El panel decía verde durante semanas.
La única prueba que cuenta es levantar el respaldo en otro lado y ver el sistema funcionando. Si nunca lo has hecho, no sabes si tienes respaldos: sabes que tienes archivos.
Tres cosas para revisar esta semana
- ¿Dónde está la copia que sobrevive al edificio? Si la respuesta es “en el mismo cuarto”, tienes una copia, no un respaldo.
- ¿Cuándo restauraste por última vez? Si no hay fecha, ese es el hallazgo.
- ¿Está escrito el orden de levantada? Qué primero, qué después, con qué credenciales. Si vive en la cabeza de una persona, tu plan de continuidad depende de que esa persona conteste el teléfono.
Y una advertencia honesta: tener tres copias tampoco resuelve todo. Frente a un ransomware, lo que protege es que las copias no se puedan borrar ni alterar durante un plazo definido, y que la retención cubra el tiempo que un atacante puede pasar dentro sin que lo veas. Es el siguiente escalón, y conviene planificarlo desde el principio, no después del susto.
Si quieres saber cuál es tu número
Medir el tiempo real de recuperación no toma semanas: toma una prueba bien hecha. Y es la única cifra que te dice si tu plan de continuidad es un plan o una expectativa.
- Respaldos y recuperación ante desastres — copias verificadas, fuera de sitio, con prueba de restauración.
- Soporte técnico y servicios administrados — monitoreo proactivo, para que el problema se vea antes de que detenga algo.
- Beneficios de un backup off-site — por qué la copia externa es la que realmente te salva.
O escríbenos y hacemos la prueba de restauración sobre tu infraestructura actual.