Conceptos básicos de DR
La recuperación ante desastres (DR) se prepara para fallos a nivel de región o de sitio completo. Define el RPO (cuántos datos puedes perder) y el RTO (cuánto tiempo hasta que el servicio regrese) por nivel de aplicación, y luego diseña copias de seguridad y réplicas para que coincidan.
Receta
Ejemplo de matriz de niveles para cargas de trabajo de PostgreSQL 18.4.
| Nivel | RPO | RTO | Patrón |
|---|---|---|---|
| Nivel 0 (pagos) | < 1 min | < 1 hr | Réplica síncrona o asíncrona + WAL fuera del sitio |
| Nivel 1 (aplicación principal) | < 15 min | < 4 hr | Réplica asíncrona entre regiones + PITR |
| Nivel 2 (analítica) | < 24 hr | < 24 hr | Volcado lógico diario a la región DR |
-- Documenta la ventana de pérdida aceptada (tabla de metadatos interna)
INSERT INTO dr_tier_registry (service, tier, rpo_minutes, rto_minutes, approved_by)
VALUES ('checkout-db', 0, 1, 60, 'cto@example.com');Cuándo usar esto: Antes de firmar SLAs de clientes o controles SOC2 que mencionen la continuidad del negocio.
Ejemplo de trabajo
Traduce los requisitos de negocio a controles técnicos:
# Región DR: verifica que llegó el último archivo WAL
aws s3 ls s3://prod-pg-wal-dr/ --recursive | tail -5
# Retraso de la réplica entre regiones (física asíncrona)
psql -h dr-replica.eu-west.db.internal -c "
SELECT now() - pg_last_xact_replay_timestamp() AS replay_age;"-- Consulta resumen para partes interesadas (adjunto del runbook)
SELECT tier, rpo_minutes, rto_minutes,
rpo_minutes || ' min de pérdida de datos máx' AS rpo_plain,
rto_minutes || ' min de tiempo de inactividad máx' AS rto_plain
FROM dr_tier_registry
ORDER BY tier;Lo que esto demuestra:
- El RPO/RTO son números de negocio respaldados por el retraso de la replicación y la frescura del archivo.
- Los recursos de la región DR deben existir antes del desastre, no aprovisionarse durante el incidente.
- La tabla de registro fuerza la aprobación explícita de las ventanas de pérdida de datos.
Profundización
RPO vs RTO
| Término | Pregunta respondida | Palancas de PostgreSQL |
|---|---|---|
| RPO | ¿Cuántos datos podemos perder? | Rep. síncrona, frecuencia de archivo, antigüedad de la copia de seguridad |
| RTO | ¿Cuánto tiempo hasta que los usuarios sean atendidos? | Automatización de restauración, corte de DNS, escalado de aplicaciones |
| MRT | Tiempo medio de recuperación (histórico) | Mediciones de simulacro |
HA vs DR
| Alcance | HA | DR |
|---|---|---|
| Fallo | Nodo, AZ, primario | Región, proveedor, ransomware |
| Herramientas | Patroni 3.x, PgBouncer | Réplica entre regiones, copia de seguridad fuera del sitio |
| RTO | Segundos a minutos | Horas |
| Frecuencia de prueba | Fallo trimestral | Día de juego anual o semestral |
Pérdida de datos aceptada
Documenta en lenguaje claro: "El Nivel 1 acepta que hasta 15 minutos de transacciones confirmadas pueden no ser recuperables si se pierden simultáneamente la copia de seguridad primaria y la local."
Trampas
- Réplica en la misma región como DR - La pérdida de región mata a ambas. Solución: WAL entre regiones y réplica.
- RPO solo en el papel - No hay medición del retraso del archivo o del retraso de la reproducción. Solución: Paneles con alertas alineadas con SLO.
- RTO ignora DNS y la aplicación - Base de datos restaurada en 30 min; aplicaciones caídas 6 h. Solución: Día de juego de extremo a extremo.
- Un nivel para todas las bases de datos - Pagar de más o proteger de menos. Solución: Nivel por servicio en el registro.
- DR nunca probado - Copias de seguridad en frío corruptas. Solución: Días de Juego de DR en el calendario.
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| Activo-activo multiregión | RTO extremo | SaaS B2B estándar |
| DR solo con copia de seguridad (sin réplica en caliente) | Analítica de Nivel 2 | Pagos de Nivel 0 |
| Base de datos global administrada | Aurora Global, etc. | Residencia de datos estricta |
Preguntas frecuentes
¿Quién aprueba el RPO?
Liderazgo de producto + legal + ingeniería. Los DBA implementan; no aceptan unilateralmente la pérdida de datos.
¿Es posible un RPO cero?
La replicación síncrona dentro de la región se acerca a cero pérdida confirmada; el RPO cero entre regiones requiere arquitecturas especializadas y un costo de latencia.
¿DR para clúster Patroni?
Alcance de Patroni separado en la región DR o restauración desde pgBackRest a un nuevo clúster; documenta el corte.
¿Ransomware y DR?
Copias de seguridad inmutables fuera del sitio y entorno de restauración aislado; la replicación sola replica cargas útiles cifradas.
¿Cómo se relaciona con el SLO de tiempo de actividad?
HA protege el presupuesto de errores mensual; DR protege los fallos existenciales de la región. Ver SLOs de tiempo de actividad para almacenes de datos.
Relacionados
- Réplicas entre regiones - sitios DR asíncronos
- Runbook y comunicaciones de DR - declaración de incidentes
- Conceptos básicos de HA - límite HA vs DR
- Conceptos básicos de PITR - precisión de rebobinado
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.