Definición de RTO, RPO y niveles de recuperación

La planificación de la continuidad empresarial (BCP) es el proceso de garantizar que las funciones empresariales críticas puedan continuar durante un desastre y después de este. En la informática en la nube, esto se traduce en diseñar sistemas que puedan recuperarse de los fallos dentro de unos límites aceptables de tiempo y pérdida de datos. Dos métricas clave —RTO y RPO— definen qué significa «aceptable» para cada carga de trabajo.

El objetivo de tiempo de recuperación (RTO) es el periodo máximo aceptable durante el que un sistema puede estar fuera de servicio después de un desastre. Responde a la pregunta: «¿Cuánto tiempo puede tolerar la empresa que esta aplicación esté inactiva?». El RTO se expresa en unidades de tiempo: horas, minutos o segundos. Un sistema de procesamiento de pagos podría tener un RTO de 15 minutos, mientras que un portal interno de recursos humanos podría tener un RTO de 24 horas.

El objetivo de punto de recuperación (RPO) es la cantidad máxima aceptable de pérdida de datos, medida en tiempo. Responde a la pregunta: «¿Cuántos datos puede permitirse perder la empresa?». Si el RPO es de 1 hora, la empresa acepta perder hasta 1 hora de transacciones. El RPO determina con qué frecuencia debe realizar copias de seguridad o replicar los datos. Un RPO de 0 requiere replicación síncrona, que es costosa y puede afectar al rendimiento de escritura.

Es importante no confundir RTO y RPO:

• RTO se refiere al tiempo: cuánto tiempo permanece inactivo el sistema
• RPO se refiere a los datos: cuántos datos se pierden

Un sistema podría tener un RTO corto (recuperación rápida), pero un RPO largo (aceptación de una pérdida de datos considerable), o viceversa. Lo ideal es que ambos sean cortos, pero lograrlo requiere una inversión considerable en replicación y capacidad de espera activa.

No todas las cargas de trabajo tienen el mismo nivel de criticidad. Un enfoque habitual consiste en clasificarlas en niveles de recuperación según su impacto empresarial:

• Nivel 1 (crítico para la misión) — RTO/RPO estrictos, coste más elevado (por ejemplo, pagos y plataformas de negociación)
• Nivel 2 (crítico para el negocio) — RTO/RPO moderados (por ejemplo, CRM y ERP)
• Nivel 3 (no crítico) — RTO/RPO flexibles, coste más bajo (por ejemplo, entornos de desarrollo y archivos)

Los distintos niveles de recuperación se corresponden con diferentes funcionalidades de Azure:

• Nivel 1 — escrituras en varias regiones de Cosmos DB, grupos de conmutación por error automática de SQL, arquitectura activo-activo y Traffic Manager
• Nivel 2 — Azure Site Recovery en una región secundaria, replicación geográfica de SQL (réplica de lectura) y copias de seguridad diarias con retención de 30 días
• Nivel 3 — Azure Backup con programaciones semanales, sin replicación y restauración desde una instantánea

Para justificar la inversión en una arquitectura con un RTO bajo, calcule el coste del tiempo de inactividad de la carga de trabajo. Esto incluye la pérdida de ingresos, las penalizaciones del SLA para los clientes, la pérdida de productividad del personal y el daño a la reputación. Si el coste de 1 hora de inactividad es de 500.000 $, gastar 50.000 $ al mes en una configuración activo-activo se justifica fácilmente. Use estas cifras para elaborar un caso empresarial que respalde el nivel de recuperación adecuado.

Azure Site Recovery (ASR) es el servicio principal para alcanzar los objetivos de RTO/RPO del nivel 2 en Azure. ASR replica continuamente las máquinas virtuales en una región secundaria y puede iniciar una conmutación por error en cuestión de minutos. La frecuencia de replicación de las máquinas virtuales de Azure es de cada 30 segundos (coherente con los bloqueos) o de 1 a 4 horas (coherente con la aplicación), por lo que el RPO suele encontrarse dentro de ese intervalo, según la configuración.

Para las cargas de trabajo cuyo RPO se mide en horas, Azure Backup con una programación adecuada es suficiente. Por ejemplo, un RPO de 4 horas requiere un intervalo de copia de seguridad de 4 horas como máximo. Azure Backup admite directivas mejoradas que permiten programaciones de copias de seguridad cada hora para las máquinas virtuales de Azure. En el caso de las bases de datos, la restauración a un momento dado (PITR) con copias de seguridad de los registros de transacciones puede lograr un RPO inferior a 1 hora con un coste menor que ASR.

Los objetivos de RTO y RPO deben estar documentados formalmente en un análisis de impacto empresarial (BIA) y ser revisados por las partes interesadas técnicas y empresariales. El BIA asigna cada aplicación a su nivel de recuperación, documenta los objetivos de RTO/RPO, identifica los servicios de Azure que cumplirán esos objetivos y especifica la programación de pruebas (la frecuencia con la que se valida el plan de recuperación ante desastres mediante simulacros).

Los objetivos de RTO y RPO son aspiraciones hasta que se validan mediante pruebas de recuperación ante desastres. Durante una prueba de recuperación ante desastres, mida el tiempo real de recuperación (¿cumple el RTO establecido?) y la pérdida real de datos en el punto de recuperación (¿cumple el RPO establecido?). Si la prueba revela deficiencias, actualice la arquitectura o los procedimientos hasta alcanzar los objetivos de forma constante. Documente los resultados de las pruebas para las auditorías de cumplimiento.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que el RTO es el tiempo de inactividad máximo aceptable, mientras que el RPO es la pérdida máxima aceptable de datos medida en tiempo; las cargas de trabajo se clasifican en niveles de recuperación que se asignan a servicios específicos de Azure; y las pruebas son esenciales para validar que los objetivos de RTO/RPO se pueden alcanzar. A continuación, exploraremos los planes de recuperación y la conmutación por error automatizada con Azure Site Recovery.