Mejores Prácticas de DR

La región de DR debe ejecutar restauraciones antes de que las necesites. Estas reglas convierten la DR de una presentación de diapositivas a una capacidad de recuperación probada.

Cómo Usar Esta Lista

• Aplica durante la revisión anual de arquitectura y la preparación de SOC2.
• Puntuación de cada elemento después del pase/fallo del día de juego de DR.
• Empareja con el registro de nivel de Conceptos Básicos de DR.
• Las revisiones legales/de cumplimiento cubren las secciones de retención y comunicaciones.

A - Planificación

• Documenta RPO/RTO por nivel de servicio con aprobación ejecutiva. Sin aceptación implícita de pérdida de datos.
• Separa HA (AZ/nodo) de DR (región) en diagramas de arquitectura. Herramientas y RTO diferentes.
• La región de DR cumple con los requisitos de residencia de datos. Jurisdicción aprobada antes de replicar PII.
• El manual de operaciones indica quién declara el desastre. Autoridad de IC documentada.
• Plantillas de comunicación al cliente pre-aprobadas por legal. Sin promesas improvisadas de pérdida de datos.

B - Postura Técnica

• Archivo WAL entre regiones o copia de seguridad administrada entre regiones. La pérdida de la región principal no significa perder la única copia.
• Réplica asíncrona en caliente entre regiones o stanza de DR restaurable. Solo copia de seguridad en frío para el nivel 2+ solamente.
• La región de DR ejecutó una restauración o promoción exitosa en los últimos 12 meses. Evidencia archivada.
• Alcance independiente de Patroni/etcd por región para autoalojado. Evita el split-brain a través de WAN.
• Copia de seguridad inmutable (S3 Object Lock, WORM). El ransomware no puede eliminar la única copia de seguridad.

C - Operaciones

• Día de juego de DR anual con prueba de humo de DNS y aplicaciones. No solo psql en el host de DR.
• Revisión trimestral del lag entre regiones contra el nivel de RPO. Alerta sobre el lag de reproducción p99.
• Procedimiento de retorno a la normalidad (fail-back) de DR documentado. El ejercicio no deja la DR como la primaria accidental.
• Credenciales de "break-glass" almacenadas de forma segura para la promoción de DR. Accesibles durante la interrupción de la región.
• Postmortem después de cualquier DR real o día de juego fallido. Rastrea la brecha de RTO hasta la remediación.

D - Medición

• Registra DR_GAME_DAY_RTO y compara con el registro de nivel. El liderazgo ve el RTO medido, no teórico.
• Rastrea la divergencia de datos en el momento de la promoción. Informes honestos de RPO.
• Playbook de página de estado enlazado desde PagerDuty. Latencia de comunicaciones medida.
• Verificación de copias de seguridad extrae de la copia de la región de DR. La copia principal local no es suficiente.
• Rastro de auditoría: quién promovió, cuándo, qué ID de copia de seguridad. Evidencia de cumplimiento.

E - Costo y Alcance

• Dimensiona correctamente la instancia de DR; documenta el procedimiento de escalado. Control de costos de DR en frío con un manual para escalar.
• El nivel 2+ puede usar DR solo con copia de seguridad y RTO más largo. No sobreconstruyas análisis con el costo de DR de nivel 0.
• Revisa las características de DR en la nube frente a Patroni autoalojado anualmente. Evita pagar por ambos sin querer.
• Excluye bases de datos no críticas del gasto de DR de nivel 0. Límite de alcance explícito.

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de DR - Marco RPO/RTO
• Réplicas entre Regiones - DR en caliente
• Días de Juego de DR - calendario de ejercicios
• Mejores Prácticas de Copia de Seguridad - copias fuera del sitio

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+.