Consigna y contexto
Un clúster grande de PostgreSQL necesita ventanas de respaldo completo más cortas y un menor costo de almacenamiento. Diseña una cadena de respaldos base incrementales usando pg_basebackup, explicando las dependencias de WAL, los manifiestos de respaldo, pg_combinebackup, la verificación, la retención y los simulacros de recuperación.
PostgreSQL establece que un respaldo incremental no se puede restaurar directamente: debe combinarse con los respaldos anteriores de los que depende para formar un respaldo completo sintético. La herramienta valida las relaciones, pero no rastrea las dependencias por ti ni demuestra que cada respaldo esté intacto. La entrevista evalúa la evidencia de recuperabilidad, no la memorización de un solo comando de respaldo.
Qué está evaluando el entrevistador
Explicar los roles de los respaldos completos, incrementales, de WAL y de los manifiestos; respaldos de referencia, cadenas de dependencias y respaldos completos sintéticos; pg_verifybackup, sumas de verificación (checksums), versiones inmutables de objetos y verificaciones de integridad; rupturas en la cadena, respaldos en standby, retención de replication-slots/WAL, cifrado y objetivos de recuperación. Demostrar el RPO y el RTO mediante simulacros en lugar de paneles de éxito de respaldos.
Preguntas para aclarar primero
Objetivos de recuperación
Confirmar RPO, RTO, puntos en el tiempo objetivo, recuperación entre regiones, cambios permitidos de versión de PostgreSQL y si el clúster tiene múltiples tablespaces.
Carga de trabajo de respaldo
Confirmar el tamaño del respaldo completo, el volumen de cambio diario, la tasa de generación de WAL, la ventana de respaldo, el ancho de banda de red, el ciclo de vida en el almacenamiento de objetos y los límites de concurrencia.
Consistencia y cumplimiento
Confirmar el cifrado de respaldos y la rotación de claves, la retención inmutable, los permisos de eliminación, el algoritmo de checksum del manifiesto, los registros de auditoría y la frecuencia de los simulacros.
Una respuesta de 30 segundos
“Comienzo con un respaldo completo verificable, genero incrementales a partir de un manifiesto de referencia y retengo cada manifiesto, registro de dependencias y segmento continuo de WAL. Un incremental no es directamente restaurable: combino la cadena en orden con pgcombinebackup y luego aplico el WAL requerido. El almacenamiento de objetos utiliza versiones inmutables y cifrado, mientras que pgverifybackup y restauraciones de muestra validan el contenido. Si falta alguna dependencia, la automatización bloquea la eliminación de sus predecesores. Los simulacros con tamaños reales y de fallas demuestran el RPO y el RTO en lugar de confiar en las tasas de éxito de los respaldos”.
Respuesta detallada paso a paso
Paso 1: Modelar la cadena de respaldos
Registrar el respaldo completo, el respaldo de referencia de cada incremental, el rango de LSN, el manifiesto, la versión de la clave y el URI de almacenamiento. Cada nodo apunta a sus prerrequisitos; la retención primero calcula el punto en el tiempo más antiguo aún recuperable.
Paso 2: Producir incrementales
pg_basebackup puede solicitar un incremental utilizando un manifiesto de referencia; el incremental contiene los bloques modificados desde esa referencia. El respaldo aún cubre todo el clúster en lugar de un solo objeto de base de datos. La conexión de replicación necesita el privilegio REPLICATION o derechos de superusuario y suficientes walsenders.
full_0 = pg_basebackup(full)
inc_1 = pg_basebackup(incremental, reference=full_0.manifest)
inc_2 = pg_basebackup(incremental, reference=inc_1.manifest)Paso 3: Retener WAL continuo
El WAL generado durante un respaldo base debe permanecer disponible. El método stream abre una segunda conexión de replicación en paralelo; el método fetch requiere wal_keep_size o archivado para retener el WAL necesario hasta que se complete la transferencia. Los replication slots reducen el riesgo de eliminación prematura pero pueden incrementar el uso de disco, por lo que se debe monitorear el LSN requerido más antiguo.
Paso 4: Verificar manifiestos y relaciones
pg_combinebackup verifica relaciones válidas entre los respaldos de entrada, pero no la integridad de cada respaldo. Ejecuta pg_verifybackup y los checksums de manifiesto para cada nodo. Registra un nodo en el catálogo solo después de que se completen la carga de su objeto y la verificación.
Paso 5: Construir la entrada de restauración
Para un punto en el tiempo objetivo, invoca pg_combinebackup desde el completo a través del incremental objetivo en orden para producir un respaldo completo sintético. Este puede servir de base para una operación de combinación posterior, pero no reemplaza al WAL. Coloca el WAL desde el LSN de finalización del respaldo hasta el tiempo objetivo en el directorio de recuperación y configura el recovery target.
Paso 6: Manejar rupturas y retención
El programador mantiene un grafo de dependencias y el tiempo recuperable más antiguo. Si falta un prerrequisito, falla la verificación de checksum o pierde su clave, marca a todos los descendientes como no recuperables y bloquea la eliminación automática del prerrequisito. Crea periódicamente un nuevo respaldo completo o completo sintético para limitar la longitud de la cadena y el RTO.
Paso 7: Realizar simulacros de RPO y RTO
Restaura puntos en el tiempo aleatorios en aislamiento y verifica los catálogos del sistema, tablespaces, WAL, extensiones y la consistencia de la aplicación. Registra los bytes descargados, la duración de la combinación, la tasa de reproducción de WAL, el tiempo de finalización y los checksums. Inyecta errores 404 del almacenamiento de objetos, manifiestos corruptos, revocación de claves y fallas del primario.
Respuesta modelo
Trato los respaldos como un grafo de dependencias: un completo es la raíz, cada incremental apunta a una referencia y el WAL cubre el punto en el tiempo. Cada nodo almacena un manifiesto, checksum, LSN, versión de clave y URI de objeto inmutable. La recuperación combina la cadena en orden con pgcombinebackup y luego reproduce el WAL continuo; su verificación de relaciones no reemplaza las verificaciones de contenido de pgverifybackup. La retención sigue el grafo, y los simulacros cubren cadenas rotas, WAL faltante, revocación de claves y múltiples tablespaces antes de que se aprueben los criterios medidos de RPO/RTO.
Errores comunes
- Error: Tratar un incremental como un directorio directamente ejecutable/iniciable. → Por qué falla: Depende de un respaldo de referencia. → Solución: Combinarlo en un respaldo completo sintético y luego aplicar el WAL.
- Error: Confiar únicamente en una ejecución exitosa de pg_combinebackup. → Por qué falla: No demuestra que cada entrada esté intacta. → Solución: Verificar cada manifiesto/checksum y realizar restauraciones de muestra.
- Error: Retener o eliminar respaldos completos basándose únicamente en su antigüedad. → Por qué falla: Los incrementales posteriores aún pueden depender de ellos. → Solución: Utilizar el grafo de dependencias y el tiempo recuperable más antiguo.
- Error: Reportar éxito de respaldo sin WAL continuo. → Por qué falla: El punto en el tiempo objetivo no se puede reproducir. → Solución: Monitorear el LSN requerido, el retraso de archivado y el uso de slots.
Preguntas de seguimiento y respuestas
¿Cuál es la diferencia entre un respaldo completo, un completo sintético y un incremental?
Un completo es una copia independiente de los archivos del clúster. Un incremental contiene los bloques modificados desde una referencia. Un completo sintético se reconstruye a partir de la cadena y puede servir como entrada de restauración, pero aún necesita el WAL posterior al punto final del respaldo para un tiempo objetivo.
¿Por qué no extender una cadena incremental indefinidamente?
Las cadenas largas aumentan los costos de descarga, combinación, verificación y fallas, elevando el RTO. Inserta un nuevo respaldo completo o completo sintético según la tasa de cambio, el costo de almacenamiento y los datos de los simulacros.
¿Qué haces si falta un manifiesto?
Marca el nodo como no disponible para la automatización; nunca adivines dependencias a partir de los nombres de archivo. Si una copia confiable restaura el manifiesto, verifica los checksums de los archivos, los LSN y las relaciones de la cadena antes de registrarlo nuevamente.
¿Cómo demuestras que el cifrado no bloqueará la recuperación?
Restaura muestras periódicamente en aislamiento con claves actuales e históricas, probando rotación, revocación, permisos y acceso a KMS entre regiones. Emite alertas explícitas y elimina el punto en el tiempo de la declaración de recuperabilidad cuando una clave no esté disponible.