Las empresas hablan de backup como si fuera sinónimo de continuidad, pero no lo es. Una copia de seguridad te dice que los datos existen en algún sitio. La continuidad operativa te dice si puedes volver a facturar, despachar pedidos, atender incidencias y cerrar el día después de un fallo. Son problemas distintos. Y confundirlos sale caro.
Tener una copia no es lo mismo que poder volver a operar.
La diferencia parece teórica hasta que ocurre el incidente. Entonces aparecen las preguntas incómodas: ¿qué se restaura primero?, ¿quién autoriza el orden?, ¿qué sistemas dependen de cuál?, ¿cuánto tardamos en descubrir que la copia no arranca o que faltan credenciales? Muchas compañías no fallan por no tener backup. Fallan porque nunca ensayaron una recuperación completa.
El error de pensar en datos cuando el negocio necesita procesos
Un backup protege archivos, bases de datos y máquinas virtuales. Pero el negocio no funciona en archivos: funciona en procesos. Si tu ERP vuelve antes que el ecommerce, pero el stock no está reconciliado, la operación entra en conflicto. Si el correo vuelve antes que la autenticación, el equipo puede empezar a trabajar, pero no con seguridad real. Si la base de datos está restaurada pero el sistema de pagos sigue caído, la venta no se recupera.
Por eso conviene pensar en “servicios críticos” y no solo en sistemas. Un servicio crítico suele combinar varias piezas:
- Identidad y acceso
- ERP o gestión de pedidos
- Ecommerce o canal de ventas
- Base de datos y almacenamiento
- Integraciones con logística, facturación o soporte
La pregunta útil no es “¿está respaldado?”. Es “¿qué necesita estar listo para reanudar esta función concreta?”.
Qué debe medirse de verdad: RTO, RPO y dependencia operativa
Hay tres métricas que deberían salir de la teoría y entrar en la conversación del comité de dirección:
- RPO: cuánta pérdida de datos toleras.
- RTO: cuánto tiempo puedes estar parado.
- Orden de recuperación: qué se levanta primero y por qué.
En muchas empresas el RPO se mide en horas porque “se hace backup cada noche”, pero el RTO no se conoce. Ese vacío es peligroso. Si no sabes cuánto tardas en volver a operar, el backup es solo un seguro parcial.
Un criterio práctico: define por proceso, no por tecnología. Por ejemplo, “procesar pedidos” puede requerir ERP, ecommerce, stock, pasarela de pago y etiqueta logística. Si uno de esos elementos queda fuera del plan, el proceso sigue roto aunque el resto funcione.
Otro detalle importante: las restauraciones deben probarse en un entorno aislado, con datos reales anonimizados o clonados, y con cronología completa. Restaurar un archivo de prueba no demuestra nada. Restaurar una operación completa sí.
Mini caso: cuando la copia existía, pero nadie podía volver a vender
Una empresa mediana de distribución tenía backups diarios, replicación en nube y un proveedor convencido de que todo estaba cubierto. Tras un incidente de ransomware, los archivos críticos existían, pero el entorno restaurado falló por tres motivos: las credenciales habían cambiado, una integración con el transportista no estaba documentada y el ERP necesitaba una validación manual que nadie sabía ejecutar.
El resultado no fue pérdida total de datos. Fue algo más incómodo: tres días de operación parcial, pedidos detenidos y equipos improvisando por correo y hojas de cálculo. La lección no fue “necesitamos más backup”. Fue “necesitamos una secuencia de recuperación probada, con responsables y dependencias visibles”.
Ese tipo de situación es común porque muchas organizaciones protegen componentes, no flujos de negocio.
La decisión incómoda: no todo debe volver al mismo tiempo
Aquí está la parte que a menudo incomoda a dirección: en una recuperación seria, no todo vuelve a la vez. Y no debería.
Intentar levantar todos los sistemas simultáneamente suele empeorar la situación. Genera colisiones de datos, accesos inconsistentes y una falsa sensación de progreso. Es mejor aceptar una jerarquía:
- Identidad y accesos
- Datos y transacciones críticas
- Procesos de venta y despacho
- Sistemas auxiliares y analítica
Esto obliga a tomar una decisión que muchas organizaciones evitan: qué procesos tienen prioridad real y cuáles pueden esperar unas horas. No es una decisión técnica pura. Es una decisión de negocio.
También conviene decidir qué automatizar y qué dejar manual en una recuperación. A veces, un paso manual documentado es más fiable que una automatización no probada. La obsesión por “todo automático” puede ocultar fragilidad.
Señales de que tu plan no está listo
Algunas señales son muy claras:
- Nadie conoce el RTO del ERP o del ecommerce.
- El último simulacro fue parcial o se hizo “sin afectar a nadie”.
- Las dependencias con proveedores externos no están inventariadas.
- La restauración depende de una persona concreta.
- Las credenciales, claves o secretos no están incluidos en el plan.
- El orden de recuperación se decide durante el incidente.
Si reconoces dos o más, no tienes un plan de continuidad sólido; tienes documentación de backup.
Qué hacer antes del próximo incidente
Empieza por un mapa simple de servicios críticos y dependencias. Después define:
- RTO y RPO por servicio
- Prioridad de recuperación
- Responsable de cada paso
- Prueba trimestral o semestral con evidencia
- Procedimiento para credenciales, accesos y cambios de configuración
El objetivo no es diseñar una fortaleza perfecta. Es reducir el tiempo de duda cuando algo falla. Porque en una crisis, el mayor coste no siempre es la pérdida de datos; muchas veces es el tiempo perdido decidiendo cómo volver a operar.
En Codefuente solemos ver que las mejores mejoras no empiezan con más tecnología, sino con una definición seria de qué significa “recuperar” para cada negocio.