Fundamentos de la computación en la nube
Respaldos y recuperación ante desastres
Qué acotan realmente el Recovery Time Objective y el Recovery Point Objective, y las 4 estrategias de recuperación ante desastres entre las que eligen los equipos de nube cuando la redundancia dentro de una región no alcanza.
- Definir el Recovery Time Objective y el Recovery Point Objective, y explicar qué acota cada uno
- Explicar cómo automatiza AWS Backup la protección de datos mediante planes de respaldo, programaciones y reglas de retención
- Comparar respaldo y restauración, pilot light, warm standby y multi-sitio activo/activo por costo, complejidad y velocidad de recuperación
- Aplicar los requisitos de RTO y RPO de un escenario para elegir la estrategia de recuperación ante desastres adecuada
Cuando la redundancia dentro de una región no alcanzó
Las últimas 2 lecciones cubrieron la redundancia dentro de 1 sola región de AWS: repartir instancias y bases de datos entre zonas de disponibilidad para que la falla de 1 centro de datos no se lleve todo el sistema. Eso protege contra una falla de hardware o un corte de energía. No sirve de nada si un despliegue con errores corrompe una tabla de la base de datos, o si toda una región geográfica queda fuera de servicio, exactamente la brecha que señaló antes en este curso la lección de regiones y zonas de disponibilidad. Esta lección trata sobre el plan para justo eso: cuando la falla es más grande de lo que la redundancia a nivel zona pudo absorber alguna vez.
Dos preguntas antes de cualquier plan de recuperación: cuántos datos, cuánto tiempo caído
Todo plan de recuperación ante desastres empieza respondiendo 2 preguntas separadas, y confundirlas es el error más común de los equipos.
El Recovery Point Objective (RPO) acota la pérdida de datos aceptable. Responde "¿cuántos datos podemos permitirnos perder?", medido como el tiempo máximo aceptable entre ahora y el último punto desde el que podrías recuperarte. Un RPO de 15 minutos significa que tus respaldos o tu replicación tienen que correr al menos con esa frecuencia, o arriesgas perder más de lo que el negocio puede tolerar.
El Recovery Time Objective (RTO) acota el tiempo de inactividad aceptable. Responde "¿cuánto tiempo podemos estar caídos?", medido como el retraso máximo aceptable entre el inicio de una caída y la restauración del servicio. Un RTO de 1 hora significa que todo el proceso de recuperación, detectar la falla, levantar infraestructura, restaurar datos, tiene que terminar dentro de esa hora.
Una base de datos de pedidos de comercio electrónico con un RPO de 15 minutos y un RTO de 1 hora está prometiendo 2 cosas muy distintas: como máximo 15 minutos de pedidos perdidos, y como máximo 1 hora antes de que la tienda vuelva a tomar pedidos. Cumplir las 2 exige ingeniería deliberada, y cumplirlas de forma más estricta siempre cuesta más.
Respaldos: la base debajo de cada estrategia
Ninguna estrategia de recuperación ante desastres funciona sin respaldos confiables debajo de ella. AWS Backup centraliza ese trabajo entre servicios, EC2, RDS, DynamoDB, EFS y más, mediante planes de respaldo: políticas que definen programaciones y retención. Un plan típico podría combinar una regla diaria, que respalda cada noche y guarda cada respaldo por 1 mes, con una regla mensual, que respalda 1 vez al mes y guarda esa copia por 1 año completo. Los recursos se asignan a un plan simplemente etiquetándolos, y los respaldos pueden copiarse en automático a otra región de AWS con la misma programación, que es justo lo que convierte un respaldo rutinario en la materia prima que una estrategia de recuperación ante desastres realmente puede usar.
Las 4 estrategias de recuperación ante desastres, de la más barata a la más cara
Con los respaldos como base, la pregunta pasa a ser cuánta infraestructura mantienes corriendo en una ubicación secundaria, y estar listo cuesta dinero sin importar si el desastre llega o no.
| Estrategia | Qué corre en la región secundaria antes de un desastre | Costo relativo | RTO/RPO relativo |
|---|---|---|---|
| Respaldo y restauración | Nada; solo existen los respaldos ahí | El más bajo | El más lento, mayor riesgo de pérdida de datos |
| Pilot light | Los datos centrales se replican en vivo; el cómputo permanece apagado hasta la conmutación | Bajo | Más rápido, pero la infraestructura igual hay que encenderla y escalarla |
| Warm standby | Una copia reducida pero completamente funcional de toda la pila | Moderado | Más rápido todavía; solo necesita escalar, no desplegar desde cero |
| Multi-sitio activo/activo | La pila completa, ya sirviendo tráfico de producción en vivo | El más alto | El más rápido; la conmutación es redirigir tráfico, no construir nada |
Respaldo y restauración reconstruye todo, datos e infraestructura, desde cero después de que se declara un desastre, usualmente mediante Infrastructure as Code, por eso es lo más lento pero lo más barato en el día a día. Pilot light mantiene la capa de datos replicándose de forma continua pero deja el resto de la pila apagado, necesitando encenderse y escalarse antes de poder servir tráfico. Warm standby va más lejos, manteniendo una versión más pequeña de toda la aplicación ya corriendo, así que la recuperación significa escalar un despliegue existente en vez de desplegarlo por primera vez. Multi-sitio activo/activo elimina por completo el paso de encendido: más de 1 región ya está atendiendo tráfico de producción, así que una falla a nivel región solo significa redirigir solicitudes lejos de la región que no puede atenderlas.
Ejemplo trabajado: ajustar la estrategia al requisito
Un tablero interno de reportes puede tolerar varias horas de inactividad y perder hasta 1 día de datos sin dañar el negocio de forma medible; respaldo y restauración no solo es aceptable aquí, es la decisión de ingeniería correcta, porque pagar por una estrategia más "caliente" sería gastar dinero que el requisito nunca pidió. Un servicio de autorización de pagos es el caso opuesto: 1 minuto de inactividad o cualquier transacción perdida es inaceptable, lo que justifica el costo y la complejidad de multi-sitio activo/activo. Ningún equipo está equivocado. Cada uno ajustó la estrategia al RTO y RPO que su negocio realmente necesita, que es justo el punto de tener 4 estrategias en vez de recurrir siempre a la más cara por defecto.
El límite entre respaldo y restauración, y pilot light
Estas 2 son el par que más se confunde, porque las 2 mantienen tus datos seguros en una segunda región y las 2 se ven, desde afuera, como "tenemos respaldos en otro lado". La diferencia está en qué pasa con el cómputo. Respaldo y restauración no tiene ninguna infraestructura lista de antemano; todo se aprovisiona desde Infrastructure as Code solo después de declarar un desastre. Pilot light mantiene un núcleo mínimo, casi siempre solo la capa de datos, activo y replicándose de forma continua, mientras el resto de la pila (los servidores de aplicación, por ejemplo) permanece completamente apagado hasta que la conmutación lo activa. Esa única diferencia, si hay algo más que datos ya esperando ahí, es lo que separa a la estrategia más barata de la siguiente.
Activo-activo vuelve a aparecer, a mayor escala
Multi-sitio activo/activo no es una idea nueva inventada solo para recuperación ante desastres. Es el patrón de redundancia activo-activo de la lección anterior, donde cada réplica sirve tráfico al mismo tiempo, estirado desde la escala de zonas de disponibilidad dentro de 1 región hasta la escala de regiones completas. El mecanismo es el mismo; solo cambian la geografía y lo que está en juego.
Error de concepto: los respaldos solos no son un plan de recuperación ante desastres
Es tentador tratar "tenemos respaldos automáticos nocturnos en una segunda región" como si fuera lo mismo que "tenemos un plan de recuperación ante desastres". No lo es. Un respaldo del que nunca se ha restaurado es una hipótesis sobre cómo iría la recuperación, no evidencia de que va a funcionar. Un plan real tiene un procedimiento de restauración documentado y ensayado, y un RTO conocido que el liderazgo realmente aprobó como aceptable. Los respaldos son necesarios para cada una de las 4 estrategias de arriba; no son suficientes para ninguna de ellas por sí solos.
Pistas de examen: emparejar un escenario con una estrategia
| Si el escenario dice... | Apunta a |
|---|---|
| "Sensible al costo", "puede tolerar horas o días de inactividad" | Respaldo y restauración |
| "Los datos centrales deben mantenerse al día, pero el costo de infraestructura completa preocupa" | Pilot light |
| "Necesita recuperación más rápida que pilot light, ya corriendo pero a menor escala" | Warm standby |
| "No puede tolerar ninguna inactividad notable, el costo es secundario" | Multi-sitio activo/activo |
| "Pérdida de datos máxima aceptable" | RPO |
| "Tiempo de inactividad máximo aceptable" | RTO |
Dónde te deja esto
Elegir una estrategia de recuperación ante desastres es elegir un punto en un dial entre el costo constante y la velocidad de recuperación, no buscar una sola respuesta perfecta; el punto correcto es dondequiera que caigan el RTO y el RPO reales del negocio, ni un poco más caro que eso. Los respaldos hacen posible cada estrategia, pero solo un procedimiento de restauración probado los convierte en un plan de verdad. La próxima lección cierra este tema con una pregunta distinta: ¿cómo te enteras realmente de que ocurrió una falla, y qué promete en realidad el SLA de un proveedor de nube cuando no se cumple?