Sincronizar backups entre servidores con NFS o rsync

Sincronizar backups entre servidores es una de esas tareas que no admite medias tintas: un backup que no se replica a una ubicación remota es, en la práctica, un punto único de fallo. Aquí comparamos las dos soluciones más extendidas en entornos Linux, NFS y rsync, y te mostramos cómo implementarlas paso a paso con configuraciones listas para producción. Si prefieres delegar, en RedServicio (redservicio.net) contamos con especialistas que pueden configurar y auditar tu infraestructura de respaldo.

¿NFS o rsync? Ventajas y cuándo elegir cada solución

Ambas resuelven el problema de mover datos entre servidores, pero con enfoques muy distintos. Y elegir bien desde el principio te ahorrará horas de mantenimiento y más de un dolor de cabeza con la integridad de los datos.

NFS: un sistema de archivos compartido en red

NFS (Network File System) monta un directorio remoto como si fuera local. Es la opción adecuada cuando necesitas acceso continuo y transparente a los archivos del backup: por ejemplo, para que varias aplicaciones lean del mismo repositorio o para centralizar almacenamiento de varios servidores web.

• Ventaja principal: transparencia total; las aplicaciones trabajan con archivos remotos como si fueran locales.
• Inconvenientes: mayor superficie de ataque, dependencia de la red en tiempo real y ausencia de compresión o cifrado nativos (hará falta Kerberos o un túnel para seguridad fuerte).
• Ideal cuando: varios servidores necesitan escribir o leer en el mismo volumen de backup a la vez.

rsync: transferencia eficiente y diferencial

rsync va por otro camino. Copia únicamente los bloques que han cambiado, lo que lo hace extraordinariamente eficiente para sincronizar backups de forma programada. Además trabaja sobre SSH, así que el cifrado viene de serie.

• Ventaja principal: ahorro masivo de ancho de banda en sincronizaciones recurrentes.
• Inconvenientes: no es un sistema de archivos en tiempo real; la sincronización ocurre cuando se ejecuta el cron o el script, ni antes ni después.
• Ideal cuando: quieres réplicas periódicas del backup entre servidores con verificación de integridad.

Cómo montar un servidor NFS en Linux paso a paso

Lo primero: instalar el paquete del servidor NFS en la máquina que almacenará los backups (ejemplo en Debian/Ubuntu):

1. Instala el servicio: sudo apt install nfs-kernel-server
2. Crea el directorio compartido: sudo mkdir -p /srv/backups && sudo chown nobody:nogroup /srv/backups
3. Edita el archivo /etc/exports y añade una línea por cada cliente autorizado:
   /srv/backups 192.168.1.20(rw,sync,no_subtree_check,no_root_squash)
4. Aplica los cambios y exporta:
   sudo exportfs -ra
5. Verifica que el puerto 2049 está abierto en el firewall y que el servicio está activo con sudo systemctl status nfs-server.

Consejo de seguridad: evita usar (rw) sin restricción de IP y, siempre que puedas, sustituye no_root_squash por la opción por defecto, root_squash, que impide que el root del cliente actúe como root en el servidor NFS. Con la configuración aplicada, tu servidor ya exporta el recurso de backups a los equipos autorizados.

Configuración del cliente NFS para montar el recurso remoto

En el cliente, instala las utilidades NFS y monta el recurso compartido:

1. Instala el paquete: sudo apt install nfs-common
2. Crea el punto de montaje: sudo mkdir -p /mnt/backups
3. Prueba el montaje manual:
   sudo mount -t nfs 192.168.1.10:/srv/backups /mnt/backups

¿Quieres que el montaje sea permanente? Añade esta línea al archivo /etc/fstab:

192.168.1.10:/srv/backups /mnt/backups nfs defaults,soft,timeo=30,_netdev 0 0

La opción soft con timeo=30 evita que el servidor se bloquee indefinidamente si el NFS remoto deja de responder. Algo crítico en servidores de producción web, donde un cuelgue de este tipo puede tirar servicios enteros. La opción _netdev, por su parte, garantiza que el sistema no intente montar el recurso antes de tener red disponible.

Verifica el montaje con df -h /mnt/backups y fuerza el montaje de fstab con sudo mount -a. Con esto, tus scripts de backup pueden escribir directamente en /mnt/backups y los datos residirán físicamente en el servidor remoto. Y si surge cualquier problema de permisos o rendimiento en tu montaje NFS, el equipo de RedServicio puede diagnosticarlo y optimizarlo por ti.

Cómo sincronizar backups entre servidores con rsync

NFS expone el disco remoto como si fuera local. Rsync funciona justo al revés: es el servidor de origen el que envía los datos modificados hacia el destino. Y solo lo modificado. Esta transmisión diferencial, que se apoya en el algoritmo delta-transfer, resulta enormemente eficiente cuando tus backups ocupan gigas pero cada día solo cambian unos megas.

El comando básico para sincronizar backups entre servidores es este:

rsync -avz –delete /var/backups/ usuario@servidor-destino:/backups/wordpress/

Vamos opción por opción, porque no todas se explican solas:

• -a (archivo): preserva permisos, propietarios, marcas de tiempo y enlaces simbólicos. Imprescindible si quieres poder restaurar WordPress tal cual estaba.
• -v: modo verbose. Práctico para auditar qué se está transfiriendo, sobre todo las primeras veces.
• -z: compresión durante la transferencia. Recomendable si los servidores no comparten red local; si están en el mismo datacenter, quizá te sobre.
• –delete: elimina en el destino lo que ya no existe en origen, de modo que mantienes una réplica exacta. Ojo aquí. Si borras algo por error en origen, se borrará también en destino.
• –partial: conserva las transferencias interrumpidas para reanudarlas después. Ideal cuando la conexión entre servidores no es demasiado estable.

¿Y si tu SSH no escucha en el puerto estándar? Se indica así: rsync -avz -e «ssh -p 2222» /var/backups/ usuario@destino:/backups/. La primera ejecución transferirá todo; las siguientes solo enviarán las diferencias, y pasarás de tardar horas a tardar segundos.

Automatización con cron y buenas prácticas de seguridad

Un backup manual es, tarde o temprano, un backup que se olvida. Lo he visto demasiadas veces. La solución es programar la sincronización con cron: edita el crontab del usuario con crontab -e y añade, por ejemplo:

0 3 * * * rsync -az –delete –partial /var/backups/ usuario@destino:/backups/ >> /var/log/rsync-backup.log 2>&1

Con esto la sincronización se ejecuta cada noche a las 3:00 y el resultado queda registrado en un log. Que deberás revisar de vez en cuando, no basta con que exista.

Para que cron funcione sin intervención humana necesitas autenticación por claves SSH. Genera un par dedicado solo para backups con ssh-keygen -t ed25519 -f ~/.ssh/backup_key y copia la pública al destino mediante ssh-copy-id -i ~/.ssh/backup_key.pub usuario@destino. Después referencia la clave en rsync: -e «ssh -i /home/usuario/.ssh/backup_key».

Algunas prácticas que conviene no saltarse:

• Restringe la clave en el destino: en authorized_keys, añade command=»rsync –server –sender -log . /backups/»,no-pty,no-port-forwarding para que esa clave únicamente sirva para rsync. Si alguien la compromete, poco podrá hacer con ella.
• Usa lockfiles o flock: así evitas que dos ejecuciones se solapen cuando una sincronización tarda más de lo previsto (pasa más de lo que parece).
• Notifica fallos: que te llegue un correo o una alerta cuando rsync devuelva un código de salida distinto de cero. Un cron que falla en silencio es peor que ningún cron.
• Comprueba el destino: un backup no verificado no es un backup. Restaura de vez en cuando en un entorno de pruebas y verás si todo está realmente donde debería.

Si optas por NFS, protege el montaje: limita la exportación por IP en /etc/exports, usa la opción rw,sync,no_subtree_check solo para hosts concretos y, si el tráfico viaja por Internet, cifralo con un túnel WireGuard.

Conclusión: qué solución encaja mejor con tu infraestructura

La elección entre NFS y rsync depende del escenario. NFS brilla cuando necesitas que las aplicaciones escriban directamente en el almacenamiento remoto de forma transparente, como pasa en clústeres o en servidores con poco disco local. Rsync es superior para replicación programada de backups: consume menos ancho de banda, transfiere únicamente los cambios y no mantiene una conexión permanente que acabe siendo una superficie de ataque más.

En muchos entornos lo que mejor funciona es la combinación: rsync nocturno para replicar los backups hacia un servidor secundario, y NFS reservado para lo que realmente necesite acceso en tiempo real. Lo esencial, sea cual sea el camino, se resume en tres cosas. Que la sincronización sea automática. Que la transferencia vaya cifrada. Y que la restauración esté probada de verdad.

Si necesitas ayuda para diseñar tu estrategia de backups, automatizar las tareas o resolver cualquier incidencia con NFS, rsync o cron, en RedServicio (redservicio.net) encontrarás soporte profesional especializado en administración de servidores y WordPress.