Una empresa puede tener backups diarios, replicación en la nube y un proveedor que “guarda todo”, y aun así quedar paralizada durante horas o días cuando algo falla. El problema no suele ser la ausencia de copias. El problema es confundir existencia de backup con capacidad de recuperación.
Un backup que no se puede restaurar en el tiempo que el negocio necesita no es un plan de continuidad; es un seguro teórico.
La discusión seria no empieza con la tecnología, sino con una pregunta incómoda: ¿cuánto tiempo puede estar parada la operación sin comprometer ventas, facturación, atención al cliente o producción? A partir de ahí, la conversación cambia. Ya no se trata de “guardar datos”, sino de diseñar un sistema de recuperación que soporte la realidad operativa.
La falsa tranquilidad de “ya tenemos backup”
En muchas pymes, el backup se trata como una tarea administrativa. Se activa una política, se guarda una copia en la nube y se asume que el problema está resuelto. El fallo aparece cuando ocurre una restauración real.
Los síntomas típicos son fáciles de reconocer:
- nadie ha probado una restauración completa en meses o años;
- el backup vive en la misma cuenta, tenant o dominio que los sistemas de producción;
- no se sabe qué datos son críticos y cuáles pueden esperar;
- la recuperación depende de una persona concreta que “sabe cómo se hace”;
- el tiempo de restauración no coincide con el tiempo máximo que el negocio tolera.
El error de fondo es pensar en backup como almacenamiento. En términos operativos, backup es una capacidad de respuesta. Si no puedes estimar cuánto tardarás en volver a operar, cuántos datos perderás y qué sistemas deben levantarse primero, entonces no tienes un diseño de resiliencia, solo una política de copia.
Qué significa recuperar de verdad
Recuperar no es volver a ver los archivos. Es restaurar el servicio correcto, con integridad suficiente y en el orden adecuado. En un entorno de negocio, eso suele implicar tres niveles:
- Restauración técnica: que los datos existan y puedan volver a montarse.
- Restauración funcional: que los procesos clave vuelvan a operar sin errores graves.
- Restauración operativa: que la empresa pueda facturar, servir pedidos, responder incidencias o seguir produciendo.
Un escenario realista: una distribuidora mediana pierde acceso a su ERP y a parte del repositorio documental por una corrupción de almacenamiento. La empresa tiene backups nocturnos. En papel, está cubierta. Pero al probar, descubre que restaurar el ERP en el mismo entorno comprometido deja los mismos permisos rotos, que los documentos adjuntos no coinciden con los pedidos y que el equipo de operaciones no sabe qué proceso seguir primero. El problema no era el backup. Era la ausencia de un runbook de recuperación y de una prioridad clara de servicios.
Las preguntas correctas son más concretas:
- ¿Qué sistemas se restauran primero y por qué?
- ¿Cuál es el RTO de cada sistema crítico?
- ¿Qué RPO es aceptable para pedidos, contabilidad, inventario o soporte?
- ¿La restauración se hace en un entorno aislado o sobre el mismo perímetro?
- ¿Quién valida que los datos recuperados sean coherentes?
El error incómodo: hacer backups sin aislar el riesgo
Aquí está la decisión que muchas organizaciones evitan: un backup conectado de forma demasiado estrecha con la infraestructura de producción también puede ser atacado, cifrado o borrado. En incidentes de ransomware, no basta con que la copia exista; tiene que estar aislada, inmutable o al menos protegida por controles de acceso muy distintos a los del sistema principal.
Eso obliga a aceptar una incomodidad: la recuperación más segura no siempre es la más simple de administrar. Puede requerir cuentas separadas, almacenamiento con políticas de inmutabilidad, retención diferenciada y permisos que no sigan la misma lógica que el entorno diario.
También hay un trade-off económico. Más retención, más copias y más pruebas cuestan dinero y tiempo. La pregunta no es si cuestan, sino cuánto cuesta una parada. Si la respuesta es “mucho”, el backup barato sale caro.
Cómo evaluar si tu estrategia es seria
No hace falta construir un laboratorio perfecto para mejorar. Sí hace falta medir. Estos criterios suelen separar una estrategia decorativa de una estrategia útil:
- Pruebas periódicas de restauración: no solo verificar que el backup se ejecute, sino restaurar sistemas reales o subconjuntos representativos.
- Aislamiento del repositorio: separar credenciales, cuentas o dominios de administración.
- Inmutabilidad o protección contra borrado: especialmente si el riesgo de ransomware es relevante.
- Priorización por impacto: no todos los sistemas merecen el mismo objetivo de recuperación.
- Documentación operativa simple: runbook claro, con pasos, responsables y validación.
- Telemetría de recuperación: saber cuánto tarda cada restauración y dónde falla.
Si una empresa no puede responder con números a “¿cuánto tardamos en volver a operar?” y “¿cuánto dato podemos perder sin romper el negocio?”, entonces el plan no está maduro.
Un criterio práctico para decidir inversión
Conviene pensar en backup y continuidad como una cartera de riesgos. No se protege igual una contabilidad que un repositorio de marketing. No se restaura igual un archivo histórico que un ERP de pedidos. Y no se justifica el mismo nivel de protección para todo.
La decisión útil es clasificar los sistemas según criticidad y definir un objetivo realista para cada uno. A veces eso lleva a reforzar solo tres cosas: el repositorio más crítico, el procedimiento de restauración y la prueba periódica. Otras veces obliga a rediseñar por completo la estrategia de copias.
Lo importante es dejar de preguntar “¿tenemos backup?” y empezar a preguntar “¿qué ocurre si tenemos que usarlo mañana a las 9:00?”.
En Codefuente solemos abordar estas decisiones junto con continuidad operativa, cloud y seguridad, porque la respuesta rara vez es solo técnica: también es de proceso, dependencia y prioridades reales.