Plan de Recuperación ante Desastres¶
Un plan de recuperación ante desastres es el documento que responde, antes del incidente, a dos preguntas que nadie responde bien en medio de uno: cuántos datos podemos perder y en cuánto tiempo necesitamos volver. Todo lo demás — topología, replicación, copias de seguridad, costo — se deriva de esas dos respuestas.
El RPO mide datos perdidos; el RTO mide tiempo detenido. Son números del negocio, no de la infraestructura.
RPO y RTO¶
- RPO (Recovery Point Objective) — cuántos datos es aceptable perder, medido en tiempo. Un RPO de 5 minutos significa aceptar la pérdida de hasta 5 minutos de transacciones.
- RTO (Recovery Time Objective) — cuánto tiempo puede estar indisponible el servicio hasta volver a atender.
Ambos tienen precio. Un RPO cero exige replicación síncrona, que cobra latencia en cada escritura. Un RTO de segundos exige capacidad ociosa en la otra región. El trabajo de arquitectura es encontrar el punto donde el costo del riesgo y el costo de la protección se cruzan.
| Nivel | RPO típico | RTO típico | Arreglo |
|---|---|---|---|
| Copia restaurable | Horas | Horas | Copia fuera del sitio, restauración bajo demanda |
| Réplica asíncrona | Segundos a minutos | Minutos | Réplica caliente en la otra región, promoción manual o asistida |
| Réplica síncrona entre regiones | Cercano a cero | Decenas de segundos | Quórum entre br-sp-1 y br-sp-2, promoción automatizada |
| Multi-escritura distribuida | Cero | Sin interrupción de escritura | CockroachDB con tres dominios de fallo |
Escenarios cubiertos¶
Un plan que solo prevé "el centro de datos se incendió" cubre el escenario más raro e ignora los frecuentes.
| Escenario | Frecuencia | Respuesta |
|---|---|---|
| Fallo de disco o de nodo | Común | La réplica asume; ninguna acción humana |
| Fallo de host o rack | Común | La anti-affinity mantiene vivo el quórum |
| Corrupción lógica / error humano | Común | Restauración puntual (PITR) — la replicación no ayuda aquí |
| Fallo de red entre regiones | Ocasional | Fencing y quórum evitan el split-brain |
| Pérdida de una región entera | Raro | Failover hacia la región sobreviviente |
| Ransomware / borrado malicioso | Raro, grave | Copia inmutable con retención protegida |
El desastre más común es humano
En la práctica, el incidente que más datos destruye no es la caída del centro de datos — es el comando equivocado, el deploy con error y el borrado indebido. Por eso la copia con PITR forma parte del plan de DR, no es un asunto aparte.
Estructura del plan¶
El plan es un documento operativo, no una presentación. Lo que contiene:
- Inventario — sistemas, bases, dependencias y criticidad de cada uno.
- RPO y RTO por sistema — no todo necesita el mismo nivel, y tratar todo como crítico encarece sin proteger más.
- Criterio de declaración — qué caracteriza un desastre y quién tiene autoridad para declararlo. Sin eso, la primera media hora se gasta decidiendo si es hora de actuar.
- Procedimiento de failover — un paso a paso ejecutable, con comandos, no con principios.
- Comunicación — quién avisa a clientes, al equipo y, cuando corresponde, a las autoridades.
- Procedimiento de failback — cómo volver, que es la mitad olvidada de la mayoría de los planes.
- Registro del ejercicio — fecha y resultado del último simulacro.
Failover entre regiones¶
Las dos regiones de InteSys son brasileñas y están en la región metropolitana de São Paulo — br-sp-1 (Cirion SAO1) y br-sp-2 (Equinix SP3) — interconectadas por enlaces Lan2Lan o túneles cifrados. La latencia entre ellas permite replicación síncrona, lo que hace viable un RPO cercano a cero sin salir del país.
Secuencia de failover:
- Detectar — más de un observador confirma la pérdida. Un observador único no decide; un fallo de red momentáneo no es un desastre.
- Declarar — la persona con autoridad declara, según los criterios escritos.
- Aislar (fencing) — se impide que el primario antiguo acepte escritura. Sin eso, dos primarios corrompen los datos.
- Promover — la réplica más avanzada de la región sobreviviente asume, tras verificar su posición de replicación.
- Redirigir — el proxy pasa a apuntar al nuevo primario; la aplicación mantiene la misma dirección.
- Verificar — sanidad de los datos, latencia y tasa de error antes de declarar el servicio restablecido.
- Comunicar — estado hacia dentro y hacia fuera, con una estimación de normalización.
Failback¶
Volver es una operación planificada, nunca urgente:
- reconstruir la región recuperada como réplica de la actual;
- sincronizar y esperar lag cero;
- elegir una ventana de baja carga;
- ejecutar el cambio controlado, con el mismo procedimiento de fencing;
- confirmar que replicación, copias y alertas volvieron al estado normal.
No hay prisa para el failback
Si la región sobreviviente está atendiendo con desempeño aceptable, el retorno puede esperar a que se corrija la causa raíz. Un failback apresurado suele generar el segundo incidente.
Simulacros¶
Un plan nunca ejecutado es una hipótesis.
| Ejercicio | Frecuencia | Qué valida |
|---|---|---|
| Failover en entorno de prueba | Trimestral | El procedimiento es correcto y está actualizado |
| Restauración completa cronometrada | Semestral | El RTO acordado es real |
| Failover controlado en producción | Anual, en ventana | Que el plan funciona con datos y tráfico reales |
| Revisión de contactos y autoridad | Semestral | Que las personas del plan siguen siendo las correctas |
Cada ejercicio termina con un informe: tiempo medido, desvíos del procedimiento y correcciones aplicadas al runbook.
Soberanía de datos en el plan de DR¶
El plan entero se ejecuta dentro de Brasil. Réplicas, logs, copias y el destino del failover permanecen en br-sp-1 y br-sp-2, bajo jurisdicción brasileña y sin transferencia internacional de datos personales.
Cuando el cliente pide una copia de contingencia en otro país — exigencia corporativa o aislamiento geográfico de la copia — se configura en volumen cifrado, con la transferencia internacional documentada en el diseño de la solución. Es decisión del cliente, nunca un valor por defecto de la plataforma.
Páginas Relacionadas¶
- Copias de Seguridad y Restauración — La capa que cubre el error humano y la corrupción
- Replicación — El mecanismo detrás del failover
- Administración — Rutinas que mantienen el plan ejecutable
- MySQL Multi-Región · PostgreSQL Multi-Región · CockroachDB
- Centros de Datos InteSys — br-sp-1 y br-sp-2