Cerramos la Parte VI con el Capítulo 26: Alta disponibilidad y disaster recovery, que trata sobre cómo conseguir que tus sistemas resistan fallos y desastres. Porque las cosas fallan: un servidor se cae, una región tiene problemas, alguien borra datos por error. La pregunta no es si fallará algo, sino cuándo, y cómo de preparado estás. Antes de ver estrategias y herramientas, necesitamos dos conceptos fundamentales que guían todas las decisiones de recuperación: RTO y RPO.

Una verdad incómoda de los sistemas: todo falla en algún momento. Discos, servidores, redes, incluso centros de datos enteros. Las empresas serias no fingen que no pasará; se preparan para cuando pase. A esa preparación para recuperarse de fallos graves se le llama disaster recovery (recuperación ante desastres, DR).

Pero «estar preparado» cuesta dinero y esfuerzo, y no todas las aplicaciones necesitan el mismo nivel. ¿Cuánto debes invertir en recuperación? Para responder, primero hay que definir qué nivel de recuperación necesitas, y eso se mide con dos preguntas: RTO y RPO.

RTO (Recovery Time Objective) es el tiempo máximo que tu sistema puede estar caído tras un desastre antes de recuperarse. Responde a la pregunta: «si esto se cae, ¿en cuánto tiempo necesito que vuelva a funcionar?»

Ejemplos de RTO según el tipo de sistema:

• Una tienda online en plena campaña: RTO de minutos (cada minuto caído = ventas perdidas).
• Una herramienta interna de informes: RTO de horas (molesto, pero tolerable).
• Un sistema de archivo histórico: RTO de días (casi nadie lo nota).

Analogía: el RTO es como preguntarte, si se te avería el coche, «¿cuánto tiempo puedo estar sin coche?». Si lo necesitas para trabajar cada día, quieres que esté arreglado en horas (RTO bajo), aunque eso signifique pagar una grúa urgente y un taller exprés. Si es un coche de fin de semana, puedes esperar una semana sin problema (RTO alto) y buscar la reparación más barata.

RPO (Recovery Point Objective) es la cantidad máxima de datos (medida en tiempo) que puedes permitirte perder en un desastre. Responde a: «si esto se cae, ¿hasta qué momento en el pasado necesito recuperar los datos sin que sea un problema?». En la práctica, marca cada cuánto necesitas hacer copias de seguridad.

Si tu última copia fue hace 1 hora y ocurre un desastre, pierdes la última hora de datos. Ejemplos:

• Un banco: RPO de segundos (no puede perder ni una transacción).
• Una tienda online: RPO de minutos (perder unos minutos de pedidos sería grave pero no catastrófico).
• Un blog: RPO de horas o un día (perder los últimos comentarios es tolerable).

Analogía: el RPO es como preguntarte «¿cuánto trabajo puedo permitirme perder si se apaga el ordenador sin guardar?». Si guardas cada 5 minutos, como mucho pierdes 5 minutos de trabajo (RPO de 5 min). Si solo guardas una vez al día, podrías perder un día entero de trabajo. Cuanto menos puedas permitirte perder, más a menudo debes guardar (copias más frecuentes).

Es fundamental no confundirlos: miden cosas diferentes.

RTO y RPO son la brújula de todo tu plan de recuperación. Cuanto más exigentes sean (RTO y RPO de minutos o segundos), más cuesta la solución (necesitas sistemas duplicados, copias constantes, automatización...). Cuanto más relajados, más barato.

Por eso, el primer paso siempre es preguntar al negocio: «¿cuánto tiempo de caída y cuántos datos podemos tolerar?». La respuesta determina cuánto invertir. No tiene sentido gastar una fortuna en recuperación instantánea para un sistema que nadie echaría de menos durante un día.

Ejemplo del mundo real: una empresa define RTO y RPO para cada sistema. Para su plataforma de pagos: RTO de 5 minutos y RPO de 0 (no pueden perder ninguna transacción ni estar caídos), así que invierten en una arquitectura duplicada y costosa. Para su sistema interno de informes: RTO de 8 horas y RPO de 24 horas, así que una simple copia diaria y una recuperación manual bastan, ahorrando mucho dinero. Misma empresa, estrategias muy distintas, cada una ajustada a lo que cada sistema realmente necesita. Definir RTO y RPO primero les permite invertir el dinero donde de verdad importa.

• Todo falla en algún momento; las empresas serias se preparan para recuperarse (disaster recovery). Pero «estar preparado» cuesta, y cada sistema necesita un nivel distinto.
• RTO (Recovery Time Objective): el tiempo máximo de caída tolerable antes de recuperarse («¿en cuánto vuelvo?»). Mira al futuro; afecta a la velocidad de recuperación.
• RPO (Recovery Point Objective): la cantidad máxima de datos (en tiempo) que puedes perder («¿cuántos datos pierdo?»). Mira al pasado; marca la frecuencia de las copias.
• No se confunden: RPO mira al pasado (datos perdidos), RTO mira al futuro (tiempo de vuelta).
• Cuanto más exigentes (minutos/segundos), más cara la solución. Por eso el primer paso es preguntar al negocio qué puede tolerar, e invertir en consecuencia.

En el siguiente subcapítulo veremos las distintas estrategias de disaster recovery (de la más barata a la más rápida) que eliges según tu RTO y RPO.