Mejores Prácticas de PITR

Alinea la retención de WAL con las ventanas legales/de cumplimiento. Estas reglas mantienen la recuperación a punto en el tiempo (PITR) confiable cuando alguien elimina la tabla incorrecta.

Cómo Usar Esta Lista

• Aplica al habilitar archive_mode o al elegir la retención de copias de seguridad en la nube.
• Revisa antes de migraciones importantes (crea una lista de verificación de puntos de restauración).
• Combina con el Manual de Ejecución de Drills de PITR trimestral.
• Comparte la sección de retención con los interesados legales/de cumplimiento.

A - Archivado

• Habilita archive_mode en el primario desde el primer día. No después del primer incidente.
• Monitorea pg_stat_archiver.failed_count con un umbral de alerta de 1. Cualquier fallo amplía el RPO.
• archive_command idempotente (test ! -f o pgBackRest). Las reintentos deben tener éxito.
• Replica el archivo WAL a una segunda región/cuenta. La pérdida de región no debe romper la cadena.
• Establece archive_timeout apropiado para bases de datos de bajo tráfico. Evita RPO obsoleto en sistemas inactivos.

B - Retención y Cumplimiento

• Retención de WAL >= mínimo de retención legal + margen operativo. Retención legal de 90 días significa archivar al menos 90 días más un margen.
• Documenta el RPO como el último archivo exitoso, no como la etiqueta de la ventana de copia de seguridad. Comunicación honesta con los interesados.
• Extiende la retención para retención por litigio sin eliminar claves. Almacenamiento inmutable o bloqueo de objetos.
• Verifica cruzadamente la retención de la consola en la nube con la hoja de cálculo de cumplimiento. El valor predeterminado de 7 días de RDS no es suficiente para muchos regímenes.
• Clasifica la retención por clasificación de la base de datos. Clústeres con PII por más tiempo que análisis internos.

C - Puntos y Objetivos de Restauración

• pg_create_restore_point antes de DDL de alto riesgo. Obligatorio en los tickets de cambio.
• Usa la zona horaria explícita en recovery_target_time. UTC con desplazamiento en los manuales.
• Prefiere recovery_target_action = pause para el primer intento. Valida antes de promover.
• Nunca hagas PITR in-place sobre el data_dir de producción. Restaura a un entorno nuevo; cambia después de la prueba.
• Registra qué tipo de objetivo se usó en el ticket de incidente. Ayuda en el postmortem y la auditoría.

D - Drills y Verificación

• Drill de PITR trimestral a un host PostgreSQL 18.4 nuevo. Registra PITR_RTO_SECONDS.
• Valida recuentos de filas y sumas de verificación de negocio después del drill. No solo pg_is_in_recovery() = false.
• Drill fallido = considera las copias de seguridad como no confiables hasta que se arreglen. Riesgo de datos de Sev-2.
• Incluye la ruta de restauración de pgBackRest o la nube en la rotación. No pruebes solo archivos cp de shell.
• Prueba de humo de la aplicación en la instancia restaurada antes de declarar éxito. DB arriba != aplicación completa.

E - Integración de Herramientas

• Patroni: documenta el arranque desde copia de seguridad para PITR de clústeres nuevos. No failover in-place.
• pgBackRest: verifica stanza y archive-push en la misma monitorización de trabajos. Cadena unificada.
• Cifra los archivos en reposo (S3 SSE-KMS, gpg). WAL contiene todos los datos.
• Restringe IAM de restauración a roles de "break-glass". Evita la sobrescritura accidental de producción.
• Mapea los pasos de la interfaz de usuario de PITR de la nube a los equivalentes del manual DIY. Los equipos híbridos se mantienen alineados.

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de PITR - arquitectura
• archive_mode y archive_command - envío
• Opciones de Objetivo de Recuperación - condiciones de parada
• Mejores Prácticas de Copia de Seguridad - copias de seguridad complementarias

Versiones de la Pila: 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+.