3 min de lectura<\/p>\n
La cuesti\u00f3n no es si una regi\u00f3n en la nube fallar\u00e1, sino cu\u00e1ndo lo har\u00e1. AWS us-east-1, Azure South Central y GCP europe-west1 han sufrido interrupciones significativas en los \u00faltimos a\u00f1os. Las empresas sin un plan probado de recuperaci\u00f3n ante desastres se enfrentan entonces a una pregunta existencial: \u00bfcon qu\u00e9 rapidez podremos volver a estar operativas – y cu\u00e1ntos datos habremos perdido?<\/strong><\/p>\n Objetivo de tiempo de recuperaci\u00f3n (RTO)<\/strong> responde a esta pregunta: \u00bfcu\u00e1l es el tiempo m\u00e1ximo aceptable de inactividad? Un RTO de 4 horas significa que el servicio debe restablecerse completamente dentro de las 4 horas siguientes al fallo.<\/p>\n Objetivo de punto de recuperaci\u00f3n (RPO)<\/strong> responde a esta otra: \u00bfqu\u00e9 volumen de p\u00e9rdida de datos es aceptable? Un RPO de 1 hora implica que, como m\u00e1ximo, se pueden perder los datos generados durante la \u00faltima hora.<\/p>\n Ambas m\u00e9tricas definen el dise\u00f1o de la recuperaci\u00f3n ante desastres y su costo. Un RTO de cero y un RPO de cero exigen una arquitectura multi-regi\u00f3n activa-activa – la opci\u00f3n m\u00e1s cara – , mientras que un RTO de 24 horas y un RPO de 24 horas pueden cubrirse con copias de seguridad diarias – la m\u00e1s econ\u00f3mica – . El arte consiste en encontrar el equilibrio justo entre las necesidades del negocio y el presupuesto disponible.<\/p>\n Copia de seguridad y restauraci\u00f3n:<\/strong> Copias peri\u00f3dicas almacenadas en otra regi\u00f3n. En caso de desastre: se despliega la infraestructura y se restauran los datos. RTO: de 4 a 24 horas. RPO: depende de la frecuencia de las copias. Coste: m\u00ednimo (solo almacenamiento). Adecuada para cargas de trabajo no cr\u00edticas.<\/p>\n Pilot Light:<\/strong> Una infraestructura m\u00ednima (r\u00e9plicas de bases de datos, DNS) permanece activa permanentemente en la regi\u00f3n de DR. En caso de desastre: se escalan los recursos de c\u00f3mputo y se redirige el tr\u00e1fico. RTO: de 30 a 60 minutos. RPO: minutos (gracias a la replicaci\u00f3n). Coste: del 10 al 20 % de los costes de producci\u00f3n.<\/p>\n Warm Standby:<\/strong> Una versi\u00f3n escalada de la producci\u00f3n opera en la regi\u00f3n de DR con capacidad reducida. En caso de desastre: se escala verticalmente y se redirige el tr\u00e1fico. RTO: de 10 a 30 minutos. RPO: segundos. Coste: del 30 al 50 % de los costes de producci\u00f3n.<\/p>\n Multi-regi\u00f3n activa-activa:<\/strong> Capacidad total en ambas regiones, con tr\u00e1fico distribuido entre ellas. La ca\u00edda de una regi\u00f3n se compensa autom\u00e1ticamente. RTO: menos de 1 minuto. RPO: cero. Coste: del 200 al 300 % (m\u00e1s complejidad). Ideal para servicios cr\u00edticos para el negocio y cercanos al cliente.<\/p>\n Los planes de DR basados en procedimientos manuales suelen fracasar en situaciones reales debido al estr\u00e9s, la presi\u00f3n de tiempo y la falta de credenciales accesibles. Infrastructure as Code (Terraform, CloudFormation, Pulumi) convierte los entornos de DR en declarativos y reproducibles.<\/p>\n El patr\u00f3n habitual es describir por completo la infraestructura de producci\u00f3n mediante c\u00f3digo. En caso de desastre, ese mismo c\u00f3digo se ejecuta en la regi\u00f3n de destino, ajustando \u00fanicamente las variables espec\u00edficas de la regi\u00f3n. Lo que manualmente requerir\u00eda horas, con IaC se logra en minutos. Y adem\u00e1s es verificable: las simulacros de DR se llevan a cabo peri\u00f3dicamente para asegurar que el c\u00f3digo funciona correctamente.<\/p>\n Replicaci\u00f3n s\u00edncrona<\/strong> escribe los datos simult\u00e1neamente en ambas regiones. RPO: cero (sin p\u00e9rdida de datos). Su inconveniente: aumenta la latencia, ya que cada escritura debe esperar la confirmaci\u00f3n desde la regi\u00f3n de DR. Solo resulta viable entre regiones separadas por menos de 50 ms de latencia.<\/p>\n Replicaci\u00f3n as\u00edncrona<\/strong> escribe primero localmente y replica despu\u00e9s, con cierto retraso. RPO: desde segundos hasta minutos (seg\u00fan el retardo de replicaci\u00f3n). Su ventaja: no afecta la latencia de la producci\u00f3n. Es el est\u00e1ndar para DR entre regiones.<\/p>\n Servicios gestionados como Aurora Global Database, Cosmos DB y Cloud Spanner ofrecen replicaci\u00f3n multi-regi\u00f3n con niveles de coherencia configurables, eliminando la necesidad de gestionar infraestructuras de replicaci\u00f3n propias.<\/p>\n Un plan de DR que no se ha probado no es un plan: es una mera esperanza. Estudios indican que el 40 % de las empresas que nunca han probado su plan de DR fracasan en un escenario real por problemas imprevistos: credenciales caducadas, puntos finales de API modificados, formatos de datos incompatibles\u2026 Todos ellos problemas que solo salen a la luz mediante pruebas rigurosas.<\/p>\n Mejor pr\u00e1ctica: simulacros trimestrales de DR en los que la regi\u00f3n de respaldo asuma efectivamente el tr\u00e1fico. Netflix marc\u00f3 un precedente con su \u00abIngenier\u00eda del caos\u00bb (Chaos Monkey, simulaci\u00f3n de interrupciones regionales), demostrando c\u00f3mo garantizar continuamente la resistencia a fallos. Los servicios administrados AWS Fault Injection Service y Azure Chaos Studio ofrecen soluciones de ingenier\u00eda del caos listas para usar.<\/p>\n Depende de la estrategia elegida: copia de seguridad y restauraci\u00f3n solo requiere almacenamiento (unos pocos euros\/mes por TB). Pilot Light representa del 10 al 20 % de los costes de producci\u00f3n. Warm Standby, del 30 al 50 %. Active-Active, del 200 al 300 %. Para la mayor\u00eda de las pymes, Pilot Light representa el punto \u00f3ptimo entre coste y disponibilidad.<\/p>\n<\/details>\n Como m\u00ednimo, cada trimestre. Para sistemas cr\u00edticos, mensualmente. Cada prueba debe documentarse exhaustivamente: qu\u00e9 funcion\u00f3, qu\u00e9 fall\u00f3 y qu\u00e9 acciones correctivas son necesarias. Las pruebas automatizadas de DR (mediante Terraform y CI\/CD) permiten realizarlas con mayor frecuencia sin incrementar la carga manual.<\/p>\n<\/details>\n S\u00ed, para sistemas no cr\u00edticos. Pero para cualquier sistema que requiera un RTO inferior a 4 horas, las copias de seguridad no bastan: el proceso de restauraci\u00f3n lleva demasiado tiempo. Restaurar bases de datos de varios terabytes puede tardar horas. En esos casos, Pilot Light o Warm Standby son opciones mucho m\u00e1s adecuadas.<\/p>\n<\/details>\n Los fallos multi-regi\u00f3n en un \u00fanico proveedor son extremadamente raros, aunque posibles (por ejemplo, fallos de DNS o errores globales en IAM). Para alcanzar la m\u00e1xima resiliencia, algunas empresas adoptan DR multi-nube: producci\u00f3n en AWS y DR en Azure, o viceversa. La complejidad es considerable, pero justificable para infraestructuras cr\u00edticas.<\/p>\n<\/details>\n Velero es el est\u00e1ndar para DR en Kubernetes: respalda el estado del cl\u00faster y los vol\u00famenes persistentes, y permite restaurarlos en otra regi\u00f3n o en otro cl\u00faster. Para cargas de trabajo sin estado, GitOps (ArgoCD) suele ser suficiente: el estado del cl\u00faster est\u00e1 definido en un repositorio Git y puede desplegarse en cualquier momento en un nuevo cl\u00faster.<\/p>\n<\/details>\n Fuente de imagen: Pexels \/ Jakub Zerdzicki<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"~7 Min. Lesezeit<\/span>RTO y RPO: las dos m\u00e9tricas que lo determinan todo<\/h2>\n
Las cuatro estrategias de DR en la nube<\/h2>\n
Infrastructure as Code como impulsor de la DR<\/h2>\n
Replicaci\u00f3n de datos: s\u00edncrona frente a as\u00edncrona<\/h2>\n
Pruebas de DR: el factor de \u00e9xito subestimado<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfCu\u00e1nto cuesta la recuperaci\u00f3n ante desastres en la nube?<\/strong><\/summary>\n
\u00bfCon qu\u00e9 frecuencia se deben realizar pruebas de DR?<\/strong><\/summary>\n
\u00bfEs suficiente una copia de seguridad como estrategia de DR?<\/strong><\/summary>\n
\u00bfQu\u00e9 ocurre en caso de un fallo multi-regi\u00f3n?<\/strong><\/summary>\n
\u00bfC\u00f3mo planifico la DR para cargas de trabajo Kubernetes?<\/strong><\/summary>\n