RTO (Recovery Time Objective): máximo tiempo permisible que un sistema puede estar offline. Para transacciones: 1-4 horas. Para email: 4-8 horas. Para sistemas batch nocturnos: 24 horas.
Qué es la continuidad de negocio
Continuidad de negocio es el conjunto de procesos, tecnologías y planes que aseguran que las operaciones críticas de una organización puedan continuar durante y después de un incidente (ciberataque, desastre natural, fallo de infraestructura). Combina backup, recuperación ante desastres, documentación de procesos críticos y entrenamiento de equipo. Diferencia entre una organización que se recupera en horas versus una que cierra durante meses.
Por qué importa
Ransomware que encripta todos tus datos, brecha de datos que requiere reconstruir infraestructura, fallo de infraestructura cloud: tu negocio no espera que arregles. Cada hora de downtime cuesta dinero: ingresos perdidos, clientes insatisfechos, reputación dañada. Para un banco o hospital, downtime de horas es catastrófico. Para startup, downtime de días es muerte. Continuidad de negocio responde: si lo peor ocurre, cuánto tiempo puedo permitirme estar offline? Cuántos datos puedo perder? Qué procesos son tan críticos que no pueden esperar? Con eso defines inversión en backup, redundancia y recuperación. Para requisitos DORA, NIS2, ISO 27001, continuidad de negocio es obligatorio. Las regulaciones españolas exigen plan documentado y simulaciones anuales.
Puntos clave
RPO (Recovery Point Objective): máxima cantidad de datos que permites perder. Para datos críticos: 1 hora. Para datos menos críticos: 24 horas. Define frecuencia de backup.
Backup vs Disaster Recovery: backup es copias de datos. DR es capacidad de restaurar operaciones en nuevo sitio. Tienes que hacer ambos: sin backup, sin qué restaurar. Sin DR, no puedes restaurar aunque tengas backup.
Estrategias de recuperación: Cold site (lento, barato), Warm site (balance), Hot site (rápido, caro). La mayoría elige Warm site con replicación a datacentro alterno.
Ejemplo: plan de continuidad que evita pérdida de negocio
Empresa de e-commerce: 50% de ingresos anuales ocurren en Black Friday (2 semanas). Define: RTO 2 horas (no puede estar offline más durante esas semanas), RPO 1 hora (no puede perder últimas transacciones). Implementa: base de datos replicada en tiempo real a datacentro alterno, aplicaciones desplegadas en ambos datacenters con balanceador de carga, backup incremental cada hora. Ransomware ataca, encripta servidor principal en viernes. Sistema detecta inconsistencia, activa failover a datacentro alterno en 15 minutos (muy por debajo de 2 horas). Cero transacciones perdidas. Si no tuviera plan, downtime de 48 horas durante Black Friday habría significado pérdida de 3-4 millones en ingresos.
Errores habituales
- Hacer backup pero no testear recuperación. Backup que no puede restaurarse es inutilidad. Testear recuperación significa seleccionar al azar algunos archivos, intentar restaurarlos, validar que funciona. Mínimo semestral.
- RTO/RPO no alineados con negocio. IT decide 4 horas RTO porque es lo que datacentro tarda. Pero negocio necesita 30 minutos. Brecha de expectativas causa crisis cuando falla.
- Continuidad de negocio solo en IT. Negocio no sabe qué procesos son críticos. Procesos manuales que nadie documenta se pierden. Requiere colaboración: IT propone, negocio prioriza.
- Asumir que cloud provider gestiona tu continuidad. Responsabilidad compartida: provider gestiona infraestructura, tú gestionas tu arquitectura. Una sola región en AWS que falla: sí sigue siendo tu problema.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Cuál es la diferencia entre RTO y RPO?
RTO (Recovery Time Objective) es tiempo máximo que puedes estar offline. RPO (Recovery Point Objective) es máxima cantidad de datos que puedes perder. Una base de datos con RTO 1 hora y RPO 15 minutos significa: recuperas en 1 hora, pero puedes perder últimos 15 minutos de transacciones.
¿Cada cuánto hay que testear el plan de continuidad?
Simulaciones completas mínimo anual. Mejor semestral. Tests de recuperación de backups específicos trimestral. Para sistemas críticos, más frecuente. ISO 27001 requiere test documentado mínimo anual.
¿Backup en cloud es suficiente para continuidad?
Backup en cloud resuelve RPO (tienes datos recientes). Pero si tu aplicación depende de infraestructura on-premise, aunque tengas datos en cloud no puedes recuperar rápido (no tienes servers donde restaurar). Necesitas DR arquitectura completa, no solo datos.