Recuperación ante desastres: definir un RTO y un RPO adecuados

La mayoría de los planes de recuperación ante desastres fallan el mismo día en que se redactan, no el día de la interrupción. Alguien elige cifras redondas que parecen seguras, nadie calcula su costo y la brecha solo aparece cuando una base de datos ya está en llamas. La salida consiste en tratar el RTO y el RPO como decisiones de negocio con un costo asociado, no como distintivos técnicos de honor.

Qué significan realmente el RTO y el RPO

Dos siglas cargan con la mayor parte del peso en cualquier conversación sobre recuperación ante desastres, así que vale la pena ser preciso con ellas.

El RTO (Recovery Time Objective) es el tiempo que un sistema puede permanecer inactivo antes de que esa inactividad cause un daño inaceptable. Si tu servicio de pago tiene un RTO de una hora, te comprometes a que vuelva a atender a los clientes dentro de los sesenta minutos posteriores al inicio de un incidente.

El RPO (Recovery Point Objective) es la cantidad de datos que puedes permitirte perder, medida en tiempo. Un RPO de cinco minutos significa que, tras la recuperación, aceptas perder como máximo los últimos cinco minutos de escrituras. El RPO es en realidad una afirmación sobre la frecuencia con la que capturas un estado recuperable.

La trampa está en tratar ambos como "lo más bajo posible". Un valor cercano a cero en ambos es técnicamente alcanzable, pero la curva de costo es implacable. Reducir a la mitad tu RTO o tu RPO rara vez duplica el costo. A menudo lo multiplica por cinco o por diez en cuanto añades replicación síncrona, infraestructura en espera y el tiempo de ingeniería necesario para mantenerlo todo en orden.

El RTO y el RPO no son lo mismo que un SLA

Un SLA describe las operaciones normales, por ejemplo un 99,9 por ciento de disponibilidad mensual. El RTO y el RPO describen las anormales: la caída de una región, un evento de ransomware, una mala migración que corrompe una tabla. Un servicio puede cumplir su SLA todos los meses durante años y aun así quedar arrasado por un único desastre para el que nunca fue diseñado para sobrevivir. Mantén estas cifras en documentos separados para que nadie confunda "por lo general fiable" con "recuperable".

Parte del impacto en el negocio, no de la infraestructura

El error número uno que vemos son ingenieros que fijan el RTO y el RPO desde el lado técnico. El orden correcto es el inverso. Partes de un análisis de impacto en el negocio y dejas que este dicte los niveles.

Recorre cada sistema crítico y hazle a su responsable tres preguntas sencillas:

1. Si esto está caído durante una hora, ¿qué se rompe en el negocio? ¿Y a las cuatro horas, o durante un día entero?
2. Si perdemos aquí los últimos quince minutos de datos, ¿es una molestia o un problema legal y financiero?
3. ¿Qué hace la gente manualmente mientras el sistema está caído, y cuánto tiempo pueden sostenerlo?

Las respuestas se agrupan de forma natural. Un libro mayor de facturación y un blog de marketing no merecen la misma protección, y pagar por protegerlos por igual es la manera de desperdiciar los presupuestos de recuperación ante desastres. Según nuestra experiencia, la mayoría de las organizaciones terminan con tres o cuatro niveles en lugar de un único objetivo para toda la empresa.

Un modelo de niveles práctico

Aquí tienes una estructura de niveles que usamos como punto de partida en los proyectos con clientes. Ajusta las cifras a tu propia tolerancia al riesgo.

• Nivel 0, crítico para la misión: RTO de minutos, RPO cercano a cero. Pagos, autenticación, la base de datos transaccional central. Estos justifican un respaldo en caliente (hot standby) y replicación síncrona o casi síncrona.
• Nivel 1, crítico para el negocio: RTO de una a cuatro horas, RPO de quince minutos. Los servicios de aplicación principales y sus almacenes de apoyo. Suele encajar un respaldo templado (warm standby) con replicación asíncrona frecuente.
• Nivel 2, importante: RTO de un día hábil, RPO de unas horas. Herramientas internas, informes, sistemas de back-office. A menudo basta con restaurar desde una copia de seguridad.
• Nivel 3, aplazable: RTO de varios días, RPO de veinticuatro horas. Archivos, registros, todo lo que puedas reconstruir. El almacenamiento en frío económico es la respuesta correcta.

Asignar cada sistema a un nivel es la hora más valiosa que dedicarás, porque convierte una ansiedad difusa en un pequeño conjunto de objetivos concretos y cotizables.

Ajusta la estrategia de recuperación a las cifras

Una vez que cada sistema tiene un nivel, la estrategia casi se elige sola. El patrón clásico aquí, popularizado por las arquitecturas de referencia en la nube, abarca cuatro enfoques amplios ordenados del más barato al más caro.

• Copia de seguridad y restauración: Copias de seguridad periódicas en almacenamiento duradero, reconstrucción bajo demanda. El costo más bajo, RTO medido en horas o días, RPO ligado a la frecuencia de las copias. Correcto para los niveles 2 y 3.
• Pilot light: Datos centrales replicados de forma continua, una infraestructura mínima en funcionamiento y el resto aprovisionado cuando ocurre el desastre. Un buen punto intermedio para muchos sistemas de nivel 1.
• Respaldo templado (warm standby): Una copia reducida pero siempre activa del entorno que escalas durante la conmutación por error (failover). RTO de minutos a un número bajo de horas.
• Respaldo en caliente o multisitio activo-activo: Capacidad totalmente duplicada funcionando en vivo, con el tráfico desplazándose con poca o ninguna interrupción. La única forma de alcanzar los objetivos de nivel 0, y con un precio acorde.

El equilibrio enfrenta el dinero y la complejidad con la velocidad de recuperación. El activo-activo te ofrece el mejor RTO y RPO, pero te obliga a resolver la consistencia de los datos entre sitios, duplica gran parte de tu costo de operación y añade sus propios modos de fallo. No compres protección de nivel 0 para un sistema de nivel 2 solo porque la diapositiva de un proveedor lo hizo parecer fácil.

Si estás sopesando esto frente a tu gasto en la nube más amplio, nuestra guía de optimización de costos en la nube explica cómo evitar que la capacidad en espera se convierta silenciosamente en tu mayor partida de gasto.

Diseña para los fallos que realmente ocurren

Las caídas de la nube a escala de región acaparan los titulares, pero no son el desastre más común al que respondemos. Las amenazas cotidianas son más prosaicas y más peligrosas porque los equipos las planifican de forma insuficiente.

• Borrado accidental y despliegues erróneos: Una migración elimina una columna, un script trunca una tabla. La replicación no te salva aquí, porque copia fielmente el error a tu respaldo en segundos.
• Ransomware e infiltrados malintencionados: Tus copias de seguridad también son un objetivo. Si pueden alcanzarse y cifrarse con las mismas credenciales que producción, no son verdaderas copias de seguridad.
• Corrupción de datos que se propaga en silencio: El peor tipo, porque puede propagarse a cada réplica e incluso a copias de seguridad recientes antes de que nadie lo advierta.

Por eso el RPO no puede satisfacerse solo con replicación en vivo. Necesitas copias de seguridad inmutables, versionadas e idealmente sin conexión o aisladas de forma lógica (air-gapped), con suficiente retención para retroceder más allá de una corrupción que no detectaste de inmediato. La resiliencia frente al ransomware se solapa en gran medida con tu postura de seguridad más amplia, así que vale la pena leerlo junto con nuestra guía sobre la arquitectura zero trust. El mismo principio de limitar el radio de impacto se aplica directamente a proteger tus datos de recuperación.

El plan no vale nada hasta que lo pruebas

Un plan de recuperación ante desastres que nunca se ha ejecutado es una hipótesis, no una capacidad. La brecha entre el RTO que anotaste y el RTO que realmente puedes alcanzar suele ser grande, y solo lo descubres realizando el simulacro.

Integra las pruebas en un calendario y aumenta el realismo con el tiempo:

1. Repaso teórico (trimestral): El equipo recorre un escenario paso a paso. Barato, y expone con rapidez los runbooks que faltan y las responsabilidades poco claras.
2. Restauración de componentes (mensual): Restaura una sola base de datos o servicio desde una copia de seguridad en un entorno aislado y verifica que los datos estén intactos y sean utilizables, no solo que el archivo se descargó.
3. Simulacro de conmutación por error completa (dos veces al año): Conmuta todo un nivel a su destino de recuperación y mide el RTO real con un cronómetro. Compáralo con tu objetivo.
4. Game day con elementos sorpresa: Una vez que lo básico es sólido, introduce un giro inesperado, por ejemplo una credencial que falta o un runbook obsoleto, para probar cómo improvisa el equipo.

Dos cosas hacen que estos simulacros valgan la pena. Primero, cronométralos siempre y registra las cifras reales, porque "pareció rápido" no es una métrica. Segundo, verifica los datos recuperados con comprobaciones reales: recuentos de filas, sumas de comprobación (checksums), una prueba de humo de la aplicación. Una restauración que se completa pero devuelve una base de datos corrupta ha cumplido tu RTO y ha fallado por completo a tu negocio.

Modos de fallo comunes que conviene evitar

A lo largo de las auditorías se repiten los mismos errores, y vale la pena nombrarlos para que puedas contrastar tu propio plan con ellos.

• Copias de seguridad no probadas. El trabajo de copia de seguridad se muestra en verde durante años y nadie restaura nunca a partir de él. La primera restauración real revela que le faltaba un esquema crítico desde el principio.
• Ignorar las dependencias. Conmutas la aplicación pero olvidas que necesita DNS, un almacén de secretos, una cola de mensajes y una API de terceros que tiene su propia caída. El orden de recuperación importa, así que documéntalo.
• Un único punto de fallo en la ruta de recuperación. El runbook vive solo en el portátil del único ingeniero que está ilocalizable durante el incidente. Guárdalo donde sobreviva al desastre.
• Un RPO que ignora los datos en tránsito. Replicas la base de datos pero no la cola de eventos sin procesar, de modo que la recuperación pierde transacciones que estaban a medio camino.

Mantén el plan al día

Los sistemas cambian cada semana, y un plan de recuperación ante desastres escrito para la arquitectura del año pasado no recuperará la de este año. Vincula una revisión ligera a tu proceso de cambios para que cualquier nuevo servicio de nivel 0 o nivel 1 reciba un RTO y un RPO asignados antes de salir a producción. Revisa el plan completo al menos dos veces al año, y siempre después de un incidente real, porque la revisión posterior al incidente es tu fuente más honesta de lo que el plan calculó mal.

Cómo puede ayudar Innovation T

En Innovation T, nuestros servicios de nube y DevOps comienzan la recuperación ante desastres donde corresponde: con un análisis de impacto en el negocio que convierte temores difusos en un conjunto claro de niveles, cada uno con un RTO y un RPO que puedes defender ante finanzas. A partir de ahí diseñamos la arquitectura de recuperación acorde, ya sea copia de seguridad y restauración para sistemas de back-office o un respaldo templado para tu vía de ingresos, y construimos la automatización que hace que la conmutación por error sea rápida y repetible en lugar de heroica. También realizamos los simulacros contigo, medimos las cifras de recuperación reales y cerramos la brecha entre el plan sobre el papel y el plan que funciona a las tres de la madrugada.

Si tu plan actual nunca ha sobrevivido a una prueba real, o no estás seguro de cuál sería hoy tu verdadero RTO, ponte en contacto. Te ayudaremos a definir objetivos que se ajusten a tu negocio y a construir la resiliencia para cumplirlos de verdad.