Respaldo y continuidad

Tener respaldo no significa poder recuperar su empresa

16 de septiembre de 2026 · 6 minutos de lectura

La conversación se repite con una regularidad incómoda. Preguntamos si la empresa tiene respaldos y la respuesta es que sí, que el sistema envía un correo todas las mañanas y que dice correcto. Preguntamos cuándo fue la última vez que alguien restauró algo con esa copia y aparece el silencio.

Ese silencio es el problema. Un respaldo que nunca se restauró no es un respaldo: es una suposición bien documentada.

Qué falla, en la práctica

No hace falta un desastre para que una copia resulte inservible. Basta con una de estas situaciones, todas bastante frecuentes:

• La copia existe, pero no incluye lo importante. Se respalda la carpeta de datos y no la base de datos, que estaba abierta y el sistema la saltó en silencio durante meses.
• La copia está completa, pero no se puede abrir. El respaldo se cifró con una clave que quedó guardada en el servidor que falló.
• La copia funciona, pero está en el mismo sitio. Un disco externo conectado al servidor desaparece con él si hay un incendio, un robo o un cifrado por ataque.
• La copia funciona y está separada, pero restaurar toma cinco días. Recuperar varios terabytes por un enlace de internet modesto tarda mucho más de lo que la gerencia imagina.
• La copia funciona, pero nadie sabe en qué orden levantar los sistemas. El servidor de aplicaciones no arranca sin la base de datos, que no arranca sin el servicio de directorio, que estaba en el equipo que también falló.

Ninguna de estas situaciones aparece en el correo de las mañanas. Todas aparecen el día de la falla.

La prueba que cambia la conversación

Una prueba de restauración consiste en tomar una copia, levantar con ella un servicio en un entorno aislado y comprobar tres cosas: que abre, que los datos están completos hasta la fecha esperada y cuánto tiempo tomó todo el proceso, cronómetro en mano.

Es un ejercicio incómodo la primera vez, porque casi siempre encuentra algo. Precisamente por eso vale la pena hacerlo en un martes tranquilo y no durante una emergencia.

La regla que sigue vigente

La formulación clásica sigue siendo un buen punto de partida: tres copias de la información, en dos tipos de soporte distintos, con al menos una fuera del sitio. A eso conviene añadir hoy una cuarta condición: al menos una copia que no se pueda borrar ni sobrescribir desde la red donde viven los servidores, porque eso es exactamente lo que busca un ataque de cifrado.

No es una regla sofisticada ni cara. Es la diferencia entre perder una mañana y perder el trabajo de un trimestre.

Qué se hace con los hallazgos

Encontrar que el respaldo no restaura no es una mala noticia, es información que llega a tiempo. A partir de ahí el trabajo es ordenado: definir qué servicios son críticos, acordar cuánto tiempo puede estar detenido cada uno y cuánta información se puede perder, y recién entonces diseñar el esquema que cumple con esos números.

Esos dos números tienen nombre propio y merecen su propia explicación: RTO y RPO explicados para gerentes.

Si en su empresa hace más de seis meses que nadie restaura nada, ese es el punto de partida natural. Un diagnóstico de respaldo y recuperación responde la única pregunta que importa: si mañana falla un servidor, ¿sabemos exactamente cómo recuperar la operación?