Backup incremental PostgreSQL con rsync: guía completa

📅 Publicado el 28 de septiembre, 2026 · Por Equipo RedServicio

El backup incremental de PostgreSQL es, probablemente, la forma más eficiente de proteger bases de datos grandes sin llenar el disco ni saturar la red. La diferencia con un backup completo es sencilla: en lugar de copiar todos los datos en cada ejecución, solo se transfieren los cambios desde la última copia. Nada más. En este artículo verás cómo combinar las herramientas nativas de PostgreSQL con rsync para montar un sistema de respaldo robusto, automatizable y, sobre todo, barato. Si administras un servidor en producción, esto te va a ahorrar horas de trabajo y bastantes gigabytes de almacenamiento.

¿Qué es un backup incremental y por qué usarlo en PostgreSQL?

Un backup incremental copia únicamente los bloques de datos que han cambiado desde el último respaldo. Y en PostgreSQL esto importa mucho, porque las bases en producción crecen hasta decenas o cientos de gigabytes. Hacer un volcado completo diario con pg_dump puede tardar horas y ocupar un espacio desproporcionado. Lo he visto en servidores donde el backup nocturno terminaba cuando ya era hora de empezar el día laboral.

Hay dos caminos principales para implementar esta estrategia:

• Backups físicos incrementales: se combina un backup base creado con pg_basebackup y la sincronización de los archivos WAL (Write-Ahead Log) mediante rsync. Es el método que cubriremos aquí.
• Archivado continuo (PITR): los WAL se envían a un archivo histórico, lo que permite restaurar la base a cualquier punto en el tiempo. Un lujo cuando alguien borra una tabla a las 14:37 de la tarde.

Las ventajas son claras: menos ancho de banda, ventanas de backup más cortas, restauraciones más rápidas y menos coste de almacenamiento. Además, al tratarse de backups físicos, la restauración recupera el clúster completo con su configuración exacta. pg_dump no siempre garantiza eso.

Requisitos previos: preparando tu servidor PostgreSQL y rsync

Antes de tocar nada, asegúrate de cumplir estos requisitos en tu servidor:

• PostgreSQL 9.6 o superior (se recomienda 13+ por las mejoras en pg_basebackup).
• rsync instalado tanto en el servidor de base de datos como en el de destino. Compruébalo con rsync –version.
• Acceso SSH entre servidores mediante claves, para transferencias seguras sin contraseña.
• Espacio suficiente en el servidor de destino para el backup base y los incrementales.

Habilitar el archivado WAL

Abre el archivo postgresql.conf y ajusta estos parámetros:

• wal_level = replica
• archive_mode = on
• archive_command = ‘rsync -a %p usuario@destino:/backups/wal/%f’

Luego reinicia el servicio: sudo systemctl restart postgresql. ¿Cómo saber si funciona? Revisa el directorio de destino; con el tiempo deberían ir apareciendo archivos WAL. Si tras un rato no hay nada, algo falla. No sigas sin resolverlo.

Crear el usuario de backup

Merece la pena usar un rol dedicado con solo los privilegios necesarios:

• Ejecuta: CREATE ROLE backupuser WITH REPLICATION LOGIN PASSWORD ‘tu_contraseña_segura’;
• Configura el acceso en pg_hba.conf para ese usuario desde la IP del servidor de backup.

Con esto, el servidor está listo para generar copias físicas de forma segura.

Creando el backup base con pg_basebackup

El backup base es la fotografía completa del clúster sobre la que se aplicarán los incrementales. Ejecuta desde el servidor de destino o desde el propio servidor de base de datos:

• pg_basebackup -h servidor_origen -U backupuser -D /backups/base -Fp -Xs -P

Los parámetros clave:

• -Fp: formato plano (plain), necesario para que rsync pueda comparar archivos.
• -Xs: incluye los archivos WAL necesarios en modo streaming, garantizando consistencia.
• -P: muestra el progreso en pantalla.

Cuando termine, verifica que el directorio /backups/base contenga la estructura completa del clúster: los directorios base, global y el archivo postgresql.conf. Ese será el punto de partida de todo tu sistema de backups incrementales.

Script de backup incremental PostgreSQL con rsync: ejemplo completo

Tienes ya la base de respaldo. Falta lo otro: un script que haga las copias incrementales cada día. El mecanismo es más simple de lo que parece. En cada ejecución, rsync compara el directorio del clúster con la última copia disponible y transfiere únicamente los bloques que cambiaron; el resto no se duplica, porque el sistema trabaja con enlaces duros.

Un ejemplo funcional, para que lo adaptes a tu entorno:

1. Define las variables de entorno: rutas de origen, destino y la fecha actual, que servirá para nombrar cada copia.
2. Crea el directorio del día con cp -al: este comando duplica la estructura de la última copia mediante enlaces duros, sin consumir espacio adicional (casi ninguno, en realidad).
3. Ejecuta pg_basebackup o rsync sobre esa copia: los archivos modificados se sobrescriben y los nuevos se añaden, mientras los intactos quedan como enlaces.
4. Registra el resultado: guarda un log con fecha, duración y estado. Cuando algo falle, lo agradecerás.

El esqueleto del script podría quedar así:

#!/bin/bash
FECHA=$(date +%Y-%m-%d)
ULTIMA=$(ls -1d /backups/incrementales/* | tail -1)
cp -al $ULTIMA /backups/incrementales/$FECHA
rsync -a –delete /var/lib/postgresql/16/main/ /backups/incrementales/$FECHA/
rsync -a /backups/incrementales/$FECHA/ usuario@servidor-remoto:/backups/remoto/$FECHA/

¿Y en producción? Ahí la cosa cambia un poco. Lo más robusto es detener el servicio brevemente o, mejor, usar una réplica en standby como origen de las copias: así garantizas consistencia sin tocar el servicio principal. Si trabajas con un hosting gestionado como el de RedServicio, puedes coordinar estas ventanas de mantenimiento con el equipo de soporte y minimizar cualquier impacto.

Automatización con cron y verificación de las copias de seguridad

Un backup que no se automatiza tarde o temprano se olvida. Es así de simple. Programa el script con cron editando el crontab del usuario postgres:

crontab -e -u postgres

y añade una línea como esta para que el incremental corra cada noche a las 3:00:

0 3 * * * /usr/local/bin/backup_incremental.sh >> /var/log/backup_pg.log 2>&1

Pero programar la tarea no basta. Tienes que verificar que las copias son restaurables, porque un backup no comprobado es, en el fondo, una suposición. Alguna vez he visto administradores descubrirlo demasiado tarde. Mi recomendación:

• Pruebas de restauración mensuales: levanta un PostgreSQL en un contenedor Docker o en un servidor de pruebas y restaura la última copia completa más los incrementales.
• Control de espacio en disco: monitoriza el crecimiento de /backups y define una política de retención; por ejemplo, eliminando copias de más de 30 días con find -mtime +30 -exec rm -rf {} \;.
• Alertas por correo o Telegram: añade al script una notificación cuando el comando termine con error. Quieres enterarte del fallo el mismo día, no tres semanas después.
• Copias externas: aplica la regla 3-2-1 y mantén al menos una copia fuera del servidor, ya sea en otro datacenter o en almacenamiento en la nube.

Conclusión: protege tus datos con una estrategia de backups sólida

Combinar backup incremental PostgreSQL con rsync da una solución eficiente, barata y totalmente controlable: una copia base con pg_basebackup, incrementales diarios con enlaces duros, transferencia cifrada a un servidor remoto y verificación periódica de restauraciones. El espacio necesario y el tiempo de cada copia se reducen de forma drástica, sin renunciar a la seguridad de tus datos.

Eso sí: la fiabilidad de todo este plan depende también de la infraestructura que lo soporta. Discos rápidos, conectividad estable y, sobre todo, un equipo que responda cuando algo falla a las 3 de la madrugada (y algo fallará, créeme). En RedServicio llevamos años acompañando a webmasters y empresas con hosting de calidad, soporte técnico 24/7 y la asesoría necesaria para diseñar políticas de copias de seguridad a medida. Si prefieres dedicar tu tiempo a tu proyecto y no a tus backups, para eso estamos.