Cuando algo falla en tu infraestructura, el tiempo que tardas en volver a funcionar puede significar la diferencia entre un susto pasajero y un daño real al negocio. Cuatro métricas —RPO, RTO, WRT y MTD— son las que determinan esa diferencia, y cualquier empresa que gestione datos o servicios en línea debería conocerlas bien.
RPO: cuántos datos te puedes permitir perder
El RPO (Recovery Point Objective) mide el máximo de datos que una empresa puede asumir perder en caso de desastre. Dicho de otra manera, es el tiempo que transcurre entre la última copia de seguridad válida y el momento del incidente.
Si tienes un RPO de cuatro horas, necesitas hacer copias de seguridad al menos cada cuatro horas. Si el fallo ocurre a las 15:00 y tu último backup es de las 11:00, perderás cuatro horas de actividad. Para una tienda WooCommerce con pedidos continuos, eso puede suponer pérdida de datos de clientes, pedidos en proceso o pagos registrados a medias. Para un blog corporativo, quizá solo pierdes el borrador de un artículo.
Cuanto más bajo es el RPO, más frecuente debe ser la copia de seguridad y, en consecuencia, más caro resulta mantenerlo. Antes de fijar el número, vale la pena preguntarse qué volumen de actividad genera tu web por hora.
RTO: el tiempo máximo de inactividad tolerable
El RTO (Recovery Time Objective) define cuánto tiempo puede estar caído un sistema antes de que el impacto en el negocio sea inaceptable. Si tu web de reservas no puede estar offline más de dos horas sin que empieces a perder clientes, tu RTO es de dos horas.
El RTO no es solo una cuestión técnica, es un acuerdo con el negocio. El equipo técnico necesita ese número para saber con qué urgencia tiene que reaccionar y qué recursos de recuperación hay que tener preparados de antemano. Un RTO de 15 minutos requiere soluciones de alta disponibilidad bastante más costosas que un RTO de 24 horas.
En WordPress, por ejemplo, un buen plan de RTO bajo implica tener snapshots del servidor listos para restaurar, configurar alertas de monitorización que disparen el proceso de recuperación en minutos y contar con un proveedor de hosting con SLA claro. Si quieres profundizar en cómo proteger la capa técnica de tu WordPress, este artículo sobre cómo proteger WordPress contra hackers te da el contexto de partida.
WRT: el trabajo de recuperación que nadie contabiliza
El WRT (Work Recovery Time) es el tiempo que tarda el equipo en devolver los sistemas a un estado operativo completo una vez que los servidores ya están de vuelta. Aquí se incluyen tareas como verificar que los datos restaurados son correctos, reconfigura conexiones de terceros (APIs, pasarelas de pago, servicios de correo), comprobar que los formularios funcionan o revisar que los registros del sistema no muestran errores.
Es un período que a menudo se subestima en la planificación. Los equipos calculan cuánto tarda la restauración técnica, pero olvidan la verificación posterior. En la práctica, un sitio puede estar online pero con errores silenciosos que solo se descubren horas después.
MTD: el límite que no se puede cruzar
El MTD (Maximum Tolerable Downtime) es el tiempo máximo total de interrupción que la empresa puede soportar antes de sufrir daños graves: pérdida de clientes, impacto reputacional o problemas financieros que ya no se pueden remediar.
La relación entre estas métricas es directa: el MTD es el techo que define los demás valores. RTO + WRT nunca pueden superar el MTD. Si el MTD de tu negocio es de ocho horas, el RTO más el WRT debe caber en ese margen. Si no caben, tu plan de recuperación actual no es suficiente.
Esta planificación cobra especial importancia para las PYMEs, donde los recursos son limitados pero la dependencia de los sistemas digitales es cada vez mayor. En el artículo sobre ciberseguridad en PYMEs puedes ver con qué frecuencia los incidentes afectan a empresas que creían estar suficientemente preparadas.
Cómo aplicar estos conceptos en tu negocio
Fijar estos valores no es un ejercicio teórico: sirve para tomar decisiones concretas sobre infraestructura, herramientas de backup y procedimientos internos. Estos son los pasos habituales:
- Identifica los sistemas críticos: no todos tienen la misma prioridad. El carrito de compra de tu tienda es más crítico que el blog corporativo.
- Asigna RPO y RTO por sistema: cada aplicación puede tener objetivos distintos según el impacto que tenga su caída.
- Calcula el MTD con el equipo de negocio: este número no lo define IT, sino quien conoce el coste real de cada hora sin servicio.
- Pon a prueba el plan: un simulacro anual te dirá si el RTO que tienes en papel se sostiene en la práctica.
En Colorvivo trabajamos con una infraestructura diseñada para minimizar estos tiempos, con backups diarios automatizados y monitorización continua. Si quieres conocer cómo está montado nuestro entorno técnico, puedes leer sobre nuestra nueva infraestructura.
Preguntas frecuentes
¿Cuál es la diferencia entre RPO y RTO?
El RPO mide cuántos datos puedes perder (tiempo entre backups), mientras que el RTO mide cuánto tiempo puede estar caído el sistema. Son métricas complementarias: el RPO afecta a la pérdida de datos y el RTO al tiempo de inactividad del servicio.
¿Qué ocurre si el RTO supera el MTD?
Si la suma de RTO y WRT supera el MTD, el plan de recuperación no es suficiente. Significa que el proceso de restauración tarda más de lo que el negocio puede aguantar, lo que obliga a revisar la infraestructura o los procedimientos para acortar esos tiempos.
¿Qué RPO y RTO son adecuados para una PYME?
Depende del tipo de negocio y del volumen de actividad digital. Una tienda con pedidos continuos puede necesitar un RPO de 1-2 horas y un RTO de 4 horas. Un sitio corporativo con tráfico bajo puede asumir un RPO de 24 horas y un RTO de 48 horas. Lo decisivo no es seguir una cifra estándar, sino calcular cuánto le cuesta realmente cada hora de inactividad.
¿Se pueden aplicar estos conceptos a un sitio WordPress?
Sí. Para WordPress, el RPO se traduce en la frecuencia de los backups (diario, cada 6 horas, en tiempo real), el RTO en la velocidad de restauración del hosting y el WRT en el tiempo necesario para verificar que plugins, formularios y conexiones externas funcionan tras la restauración.
