Prácticas recomendadas de copia de seguridad

Automatiza las restauraciones, no solo las volcados: las copias de seguridad no probadas son una ficción. Estas reglas mantienen las copias de seguridad de PostgreSQL recuperables bajo la presión de un incidente real.

Cómo usar esta lista

• Aplica al diseñar trabajos de copia de seguridad y retención.
• Utiliza la ejecución mensual de verificación como una lista de verificación de aprobado/fallido.
• Empareja con los requisitos de retención de cumplimiento.
• Revisa después de cualquier simulacro de restauración fallido o lento.

A - Estrategia

• Utiliza copias de seguridad lógicas y físicas juntas. Lógicas para objetos; físicas para PITR y clúster completo.
• Sigue la regla 3-2-1: tres copias, dos medios, uno fuera del sitio. Independiente de la replicación.
• Nunca trates la réplica en espera como una copia de seguridad. La replicación reproduce eliminaciones y corrupción.
• Vuelca los globales (pg_dumpall -g) según lo programado. Los roles y tablespaces no están solos en el volcado por base de datos.
• Cifra las copias de seguridad en reposo y en tránsito. S3 SSE-KMS, TLS o gpg para archivos.

B - Operaciones de volcado

• Prefiere -Fc o -Fd sobre SQL plano para tamaños de producción. Permite la restauración paralela.
• Ejecuta pg_dump grandes fuera de horas pico o desde una réplica en espera. Reduce la carga principal.
• Las tablas de Nivel 0 obtienen volcados dedicados a nivel de objeto. Más rápido que el clúster completo para recuperaciones rápidas ante errores.
• Supervisa la duración del trabajo de volcado y el tamaño de la salida. Una reducción repentina significa fallo o esquema vacío.
• El rol de copia de seguridad utiliza privilegios mínimos con acceso de lectura a todos los datos necesarios. Documenta la política de omisión de RLS.

C - Físico y WAL

• Habilita archive_mode o pgBackRest para copias de seguridad capaces de PITR. La replicación sola es insuficiente.
• Supervisa pg_stat_archiver.failed_count. Los fallos de archivo amplían silenciosamente el RPO.
• Conserva WAL según la ventana de cumplimiento más un margen de seguridad. Alinea con las retenciones legales.
• Prueba la restauración física trimestralmente. La verificación solo lógica omite las brechas de WAL.
• Coordina la pausa de Patroni solo cuando la herramienta de copia de seguridad lo requiera. Documenta en el manual de ejecución.

D - Verificación

• Automatiza la restauración mensual en una instancia PostgreSQL 18.4 nueva. No solo ls -l en los archivos.
• Registra RESTORE_RTO_SECONDS en cada ejecución de verificación. Demuestra las afirmaciones de RTO del liderazgo.
• Compara recuentos de filas o sumas de verificación después de la restauración. Detecta volcados truncados.
• Alerta ante fallos de verificación como riesgo de datos de severidad 1. Trata como incidente de producción.
• Obtén la copia de verificación de la réplica fuera del sitio. La copia de seguridad en disco local puede mentir.

E - Operaciones y Acceso

• Restringe el IAM del bucket de copias de seguridad solo a los roles de copia de seguridad y verificación. Sin servidores de aplicaciones.
• Retención de versiones: diaria 7, semanal 4, mensual 12 como mínimo para el nivel 0. Ajusta al nivel de RPO.
• Documenta quién puede activar la restauración y a qué entornos. Evita la sobrescritura de producción.
• El manual de ejecución vincula el ID de copia de seguridad con los pasos de restauración. El personal de guardia no busca en la wiki durante una alerta de severidad.
• Post-incidente: si se usó una copia de seguridad, reestablece la línea base y verifica la siguiente copia. Confirma que la cadena está intacta.

Preguntas frecuentes

Relacionado

• Conceptos básicos de copia de seguridad - lógica vs física
• Verificación de copia de seguridad - prueba automatizada
• Conceptos básicos de PITR - cadena WAL
• Prácticas recomendadas de DR - postura fuera del sitio

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