Cada vez que entramos a hacer un diagnóstico de infraestructura preguntamos lo mismo: “¿tienen respaldos?”. La respuesta siempre es que sí. La siguiente pregunta es la que incomoda: “¿cuándo fue la última vez que restauraron uno?”. Ahí es donde el cuarto se queda callado.
No es negligencia. Es que el respaldo es de esas cosas que parecen resueltas porque hay un software instalado y nadie ha visto una alerta roja. El problema es que un trabajo de respaldo puede terminar “exitosamente” y aun así producir un archivo del que no se puede recuperar nada útil.
El escenario real: un ransomware cifra el servidor de archivos un jueves. El respaldo existe, está en un disco conectado al mismo servidor, y también quedó cifrado. El respaldo en la nube sí sobrevivió, pero nunca se probó la restauración completa y tarda 40 horas en bajar. La empresa estuvo cinco días sin operar.
Por qué fallan los respaldos que “sí existen”
Estas son las causas concretas que encontramos, en orden de frecuencia:
- Está todo en el mismo lugar. El respaldo vive en un disco conectado al mismo servidor o en la misma red sin aislamiento. Lo que mate al original mata a la copia.
- Respalda archivos, no sistemas. Se copian carpetas, pero no el estado de la base de datos, ni la configuración del servidor, ni las máquinas virtuales. Recuperar los archivos no te devuelve la operación.
- Bases de datos respaldadas “en caliente”. Copiar el archivo de una base de datos mientras está en uso, sin usar el mecanismo propio del motor, produce copias inconsistentes que no montan.
- Nadie revisa los avisos. El sistema manda correo de error desde hace meses a un buzón que ya no lee nadie, o a un empleado que se fue.
- Alcance incompleto. Se respalda el ERP, pero no el servidor de licencias, ni la configuración del firewall, ni los buzones. En una recuperación real, esas piezas faltantes son las que detienen todo.
- Nunca se probó. La causa raíz de todas las anteriores. Ninguno de esos problemas se detecta hasta que intentas restaurar.
La regla 3-2-1, y por qué hoy se le agregan dos números
La regla clásica es sencilla y sigue vigente: 3 copias de tus datos, en 2 medios distintos, con 1 fuera de sitio. Con el ransomware como amenaza dominante, la industria le añadió dos dígitos:
| Número | Qué significa | Por qué importa |
|---|---|---|
| 3 copias | El dato original más dos respaldos | Una sola copia de seguridad es un punto único de falla |
| 2 medios | Por ejemplo disco local y nube, o disco y cinta | Un problema de un medio no se propaga al otro |
| 1 fuera de sitio | Copia geográficamente separada | Incendio, inundación o robo en la sede no se lleva todo |
| 1 inmutable | Copia que no se puede alterar ni borrar por un periodo definido | El ransomware moderno busca y cifra los respaldos primero |
| 0 errores | Restauraciones verificadas periódicamente | Es el único número que convierte la teoría en certeza |
De los cinco, el que casi nadie implementa es la copia inmutable. Y es justo la que decide si pagas un rescate o no. Un atacante que entra con credenciales de administrador puede borrar todos los respaldos accesibles desde la red; una copia inmutable, por diseño, no se puede eliminar aunque se tengan las llaves.
Dos números que tu dirección debería conocer: RPO y RTO
Casi ninguna PyME los tiene definidos, y son los que traducen la tecnología a lenguaje de negocio.
RPO — cuánta información puedes permitirte perder
Si respaldas una vez al día a medianoche y el servidor muere a las 5 de la tarde, perdiste 17 horas de trabajo: capturas, pedidos, correos, movimientos de inventario. Ese es tu RPO real. La pregunta para dirección no es técnica: “¿cuánto nos cuesta volver a capturar un día entero de operación, y podemos siquiera reconstruirlo?”.
RTO — cuánto puedes estar detenido
Es el tiempo entre la caída y volver a operar. Incluye conseguir hardware, reinstalar, bajar el respaldo y validar. Muchas empresas descubren que su RTO real son días cuando asumían que eran horas, simplemente porque nadie cronometró una restauración completa.
Una forma directa de aterrizarlo en la junta de dirección: toma lo que factura la empresa en un día, divídelo entre las horas laborales y multiplícalo por tu RTO real. Ese número, más el costo de recapturar el trabajo perdido en tu ventana de RPO, es lo que cuesta no tener respaldos probados.
Cómo probar que tu respaldo sirve
Probar no es abrir un archivo del respaldo. Es reconstruir el servicio y comprobar que la operación puede continuar sobre él. Un ejercicio mínimo, trimestral:
- Elige un sistema crítico: el ERP, el servidor de archivos o la base de datos principal.
- Restaura en un entorno aislado, nunca sobre producción, para no arriesgar lo que sí funciona.
- Cronometra desde cero. El reloj corre desde que declaras el incidente hasta que el sistema está usable. Ese es tu RTO verdadero.
- Que lo valide un usuario del área. Alguien de operación o contabilidad debe confirmar que los datos están completos y cuadran. TI no siempre nota que falta un módulo.
- Documenta y corrige. Qué falló, qué faltó, cuánto tardó. Esa bitácora también es evidencia de diligencia si algún día tienes que demostrarla.
Lista de verificación rápida
- ¿Sé exactamente qué sistemas están incluidos en el respaldo, y cuáles no?
- ¿Existe al menos una copia fuera de la red de producción?
- ¿Alguna copia es inmutable o tiene retención bloqueada?
- ¿Las bases de datos se respaldan con el mecanismo propio del motor?
- ¿Alguien revisa los avisos de fallo, y ese alguien sigue en la empresa?
- ¿Restauramos algo en los últimos tres meses y cronometramos cuánto tardó?
- ¿Dirección conoce y aceptó por escrito el RPO y el RTO actuales?
Si dudaste en tres o más, tu continuidad depende de la suerte. La buena noticia es que casi siempre se corrige con configuración y disciplina, no con inversión mayor.
En nuestro Diagnóstico de Infraestructura y Seguridad no preguntamos si tus respaldos funcionan: restauramos uno. Un sistema acordado contigo de antemano —normalmente una base de datos—, en un entorno aislado, comprobando que el respaldo se lea, que arranque y que sus servicios levanten, con el reloj corriendo. La validación funcional de la aplicación la hace quien la conoce, de tu lado. Es el hallazgo que más rápido cambia una conversación de presupuesto.