RTO, RPO y la prueba de restauración que casi nadie ha hecho

Pregunta a un equipo de ingeniería si tiene copias de seguridad y la respuesta es que sí, inmediata y con seguridad. Pregunta cuándo fue la última vez que restauraron una en un entorno funcionando, de principio a fin y con un cronómetro en marcha, y se hace el silencio. En los entornos que auditamos la respuesta honesta suele ser "nunca", o "hace año y medio, y era una sola base de datos".

Ese hueco es donde una caída se convierte en un incidente de una semana. Que el trabajo de copia termine bien es una marca verde en una consola. La restauración son cuarenta pasos que tocan IAM, DNS, secretos, certificados TLS, una pasarela de pago de un tercero y una persona que ya no trabaja aquí. Nadie ha recorrido esa secuencia, así que nadie sabe que tarda once horas en lugar de las dos que promete el documento de recuperación ante desastres. El arreglo no es más copia. Son objetivos que puedas defender y una prueba que los demuestre.

Fija los objetivos por servicio, no para toda la empresa

Un único "RTO de 4 horas, RPO de 15 minutos" para toda la compañía es un documento escrito para contestar un cuestionario. Es inasumible donde es estricto e inútil donde es laxo, porque tu ruta de pago y tu herramienta interna de gastos no merecen el mismo dinero.

El objetivo de tiempo de recuperación es cuánto puede estar caído el servicio. El objetivo de punto de recuperación es cuántos datos aceptas perder. Los dos son decisiones de negocio con precio de ingeniería, y los dos tienen un responsable con nombre y apellidos.

Hazlo como una tabla, una fila por servicio:

La columna de justificación es la que importa. Impide que un equipo pida un RPO de un minuto para todo y después no financie nada. Un nivel 3 con un RTO honesto de cinco días es una respuesta legítima, y libera presupuesto para el nivel 1.

Después contrasta los objetivos con la realidad. Un RPO de un minuto significa replicación casi síncrona, no snapshots nocturnos. Un RTO de una hora significa que el entorno pasivo ya existe, no que alguien lo va a levantar con Terraform durante el incidente.

Una copia que existe no es una copia que puedas restaurar

La distinción es aburrida y es todo el artículo. Formas habituales en que una copia que "existe" falla en el momento de la verdad, varias de las cuales son además lo que un atacante busca a propósito, como vemos en copias que sobreviven al ransomware:

• El snapshot está en la misma cuenta, la misma región y con la misma clave de cifrado que aquello que protege.
• El volcado de base de datos es lógicamente inconsistente porque se tomó con una lectura no coherente.
• La restauración necesita una clave de KMS cuya política solo daba acceso al rol que se ha borrado.
• La copia tiene datos pero no la versión de esquema, y la aplicación se niega a arrancar contra ella.
• La ventana de retención es de 7 días y la corrupción empezó hace 12.
• Restaurar tarda 9 horas porque el volumen son 8 TB y el nivel de almacenamiento limita el rendimiento de la primera lectura.

Esa última es la sorpresa fiable. Un nivel de archivo frío no restaura a la velocidad de un snapshot templado, y los volúmenes grandes rehidratados desde almacenamiento de objetos están "disponibles" mucho antes de rendir. Mídelo una vez con tus propios datos y no volverás a citar un tiempo de restauración sacado de la página de un fabricante.

La prueba de restauración trimestral y lo que produce

Una vez por trimestre, por cada servicio de nivel 1, restaura en un entorno aislado y arranca la aplicación contra esa copia. No un checksum. No un "el snapshot montó". La aplicación respondiendo a una petición real, con los datos presentes.

Hazlo como ejercicio cronometrado y con alguien tomando notas. Registra:

• Hora de inicio, primera lectura correcta, primera escritura correcta, servicio completo restaurado.
• Cada paso manual, incluidos los que alguien improvisó.
• Cada credencial, clave o aprobación que hubo que buscar en lugar de consultar.
• El RPO medido, que es la marca de tiempo del registro más reciente que recuperaste de verdad.

La salida son dos artefactos: un runbook de una página actualizado y una lista de defectos con dueño. Los defectos son el objetivo. Una prueba que no encuentra nada no fue una prueba real, normalmente porque alguien preparó el entorno de antemano.

Los experimentos de caos son la misma disciplina aplicada a modos de fallo distintos de la pérdida de datos, y los dos programas deberían compartir calendario. Cubrimos la puerta de entrada en los primeros experimentos de ingeniería del caos.

Las dependencias que nadie apunta

• DNS. Restaurar el servicio en otro sitio no sirve de nada si el registro sigue apuntando al viejo y el TTL es de 24 horas. Baja el TTL de los registros críticos antes de necesitarlo, y ten claro quién puede cambiarlos a las tres de la mañana.
• Secretos y configuración. La instancia restaurada necesita claves de API, contraseñas de base de datos y secretos de cliente OAuth. Si tu almacén de secretos está dentro del radio de impacto de la caída, la restauración está bloqueada por lo mismo que se rompió.
• Certificados TLS. Las cadenas de CA privada y los certificados fijados caducan, y la automatización de renovación suele vivir en la máquina que acabas de perder.
• Terceros. Pasarelas de pago, proveedores de identidad y APIs de socios suelen filtrar por IP de origen. Tu entorno de recuperación tiene otras. Regístralas por adelantado.
• Licencias y cuotas. Una restauración en una cuenta nueva choca con las cuotas por defecto de inmediato. Pide los incrementos antes del incidente, no durante.
• Las personas. Una sola persona que conoce la secuencia es un punto único de fallo con vacaciones.

Escribe el plan para las tres de la mañana

El plan de recuperación que tiene la mayoría de las organizaciones es un documento de 40 páginas con tabla de control de cambios. Nadie lo lee durante un incidente.

Lo que funciona es una página por servicio: precondiciones, comandos en orden, verificación, vuelta atrás y dos números de teléfono. Copiable y pegable, y guardado en un sitio alcanzable cuando el entorno principal está caído, lo que significa que no puede estar solo en el wiki que corre sobre el clúster afectado. Imprime una copia. Suena absurdo hasta que la caída es la del proveedor de identidad.

Construimos esta tabla y hacemos la primera prueba de restauración en la fase de resiliencia de un proyecto cloud. Esa primera prueba es casi siempre la que revela los números de verdad.

Qué hacer esta semana

Elige tu base de datos más importante. Restaura la copia de anoche en un entorno desechable y cronométralo, desde que pulsas empezar hasta que la aplicación sirve una consulta real. Apunta el número al lado del RTO de tu documento de recuperación. Si los dos números no coinciden, ya tienes el ticket más útil de tu backlog.