Sincronizar una carpeta grande entre dos servidores (reanudable, en segundo plano)

Última actualización: 2026-08-05

Tienes una carpeta grande —decenas de gigabytes— en un servidor y quieres una copia exacta en otro. No puedes vigilar una terminal durante horas, y una transferencia que muere a mitad de camino no debería empezar de cero. relayium sync está hecho para esto: un espejo incremental unidireccional que se salta lo que ya está, reanuda un archivo enviado a medias desde donde se detuvo y verifica de extremo a extremo cada archivo que envía.

Esta guía configura una transferencia sin supervisión y con recuperación automática: autoriza al emisor una vez, ejecuta el proceso a la escucha en segundo plano y dirige relayium sync desde un bucle de reintentos dentro de tmux para que siga adelante a través de las caídas de conexión hasta que toda la carpeta haya llegado.

Por qué relayium sync encaja en esta tarea

sync es un espejo incremental unidireccional sobre el protocolo nativo (instala relayium en ambos extremos). Tres propiedades hacen que sea seguro ejecutarlo y volver a ejecutarlo sin supervisión:

Se salta los archivos que ya están: un archivo cuya copia en el receptor coincide en tamaño y hora de modificación no se envía de nuevo.
Reanuda archivos parciales: si un archivo se transfirió a medias cuando cayó la conexión, la siguiente ejecución continúa desde el desplazamiento de bytes que ya está en disco en lugar de reiniciarlo.
Verifica lo que envía: cada archivo transferido —incluido uno reanudado— se comprueba de extremo a extremo contra el SHA-256 del emisor, y una discrepancia se informa como fallo. Los archivos que omite se deciden por tamaño y mtime, y no se vuelven a hashear, así que sync no dice nada del contenido que no envió.
Por todo esto, el comando es idempotente: volver a ejecutarlo solo hace el trabajo que queda, que es justo lo que permite a un bucle de reintentos terminar una transferencia enorme.

Requisitos previos

Lo que necesitas

Esta guía usa daemon directo (relayium://), así que los dos servidores no necesitan acceso SSH entre sí.
Abre el puerto del proceso a la escucha (9031 por defecto) al emisor en el cortafuegos o grupo de seguridad del receptor.
Sitio para toda la carpeta en el receptor. Compara du -sh /root/workspace en el emisor con df -h /root en el receptor antes de lanzar una transferencia de varias horas.

Instala relayium en ambos servidores (sync habla el protocolo nativo, así que debe estar presente en cada extremo):

# en AMBOS servidores
curl -fsSL https://relayium.com/install.sh | sh

Autorizar al emisor una vez (en el receptor)

El receptor aprueba la máquina emisora una vez; la aprobación se escribe en disco y sigue siendo válida entre reinicios, así que nunca la repites. Inicia el proceso a la escucha en una terminal y apunta --dir al directorio padre — relayium sync /root/workspace reproduce workspace/... en el receptor, así que --dir /root deposita los archivos en /root/workspace/.

En la primera conexión del emisor (siguiente sección), serve muestra su dirección y su huella y te pide que lo apruebes; responde y y se recuerda para siempre:

# en el RECEPTOR (en primer plano, para aprobar de forma interactiva)
relayium serve --dir /root --port 9031

# en el RECEPTOR, en la primera conexión:
Incoming push from 203.0.113.9:52140
  fingerprint: 9f2c41ab…
Accept and remember this peer? [y/N] y

Para una configuración totalmente sin supervisión, sáltate el aviso: ejecuta relayium id en el emisor para imprimir su huella, y luego relayium authorize <huella> en el receptor.
--dir es el padre de la carpeta que sincronizas, no la carpeta en sí; de lo contrario los archivos llegan un nivel demasiado profundo (p. ej. /root/workspace/workspace).

Ejecutar el proceso a la escucha en segundo plano (en el receptor)

Una vez autorizada la huella, detén el serve en primer plano (Ctrl-C) y relánzalo desacoplado para que sobreviva a tu cierre de sesión. Carga la huella guardada y acepta al emisor en silencio: esta vez no hay aviso. La misma línea anota el PID del nuevo proceso en ~/relayium-serve.pid, y así es como el último paso de esta guía detiene el proceso a la escucha que lanzó, en vez de todo comando relayium de la máquina:

# en el RECEPTOR
nohup relayium serve --dir /root --port 9031 > ~/relayium-serve.log 2>&1 & echo $! > ~/relayium-serve.pid

serve maneja las conexiones de una en una y sigue ejecutándose, así que está listo para cada reconexión del bucle de reintentos de abajo.
Para una bandeja de entrada siempre activa, ejecútalo bajo systemd en su lugar (Restart=always, --config-dir /etc/relayium).

Ejecutar el sync en un bucle de reintentos bajo tmux (en el emisor)

Las transferencias largas se interrumpen: una sesión caída, una red inestable, un reinicio. La solución no es una herramienta sofisticada; es un bucle que vuelve a ejecutar sync hasta que tiene éxito, más un multiplexor de terminal para que sobreviva a tu cierre de sesión. Aquí tmux es más limpio que nohup: no hay redirección de salida que puedas equivocar, y puedes volver a conectarte para ver el progreso.

Inicia una sesión de tmux, luego ejecuta el espejo en un bucle until: reintenta cada 10 segundos hasta que sync devuelve éxito, y luego sale por sí solo:

Abre una sesión de tmux en el emisor, para que el bucle sobreviva a la sesión ssh desde la que lo lanzaste.
```
# en el EMISOR
tmux new -s xfer      # apt install -y tmux si falta
```
Ejecuta el espejo dentro de un bucle until. Reintenta cada 10 segundos hasta que sync devuelva éxito, y entonces sale por su cuenta.
```
until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done
```
Desconéctate con Ctrl-b y luego d. El bucle sigue en marcha; vuelve a conectarte cuando quieras mirarlo.
```
tmux attach -t xfer
```

Cómo se ve una pasada correcta

Cada pasada imprime una línea por cada archivo que realmente envió, y luego un resumen que enfrenta lo enviado con lo que el receptor ya tenía. El bucle acaba la primera vez que sync devuelve éxito, y ese resumen es el estado del espejo.

relayium sync /root/workspace relayium://203.0.113.43:9031
  workspace/data/part-004.bin (1073741824 bytes)
synced: 1 sent, 812 unchanged

Cada reintento hace menos: los archivos ya transferidos se saltan, un archivo enviado a medias se reanuda; así el bucle converge y termina.
El progreso imprime una línea por archivo completado, así que un archivo grande se transfiere en silencio hasta que termina. El silencio no es un atasco (ver resolución de problemas).

Verificar y terminar

La transferencia está completa cuando el bucle until termina y vuelves a un prompt de shell normal. Confirma que ambos lados coinciden, y luego detén el proceso a la escucha:

Espera a que el bucle until termine por su cuenta. Volver a un prompt de shell normal significa que la transferencia acabó, no que la interrumpiste.

Compara los totales en los dos servidores.

# compara los totales en AMBOS servidores
du -sh /root/workspace

Detén el proceso a la escucha en el receptor cuando los totales coincidan. La señal va al PID que anotaste al lanzarlo, y no a todo comando relayium de la máquina por coincidencia de texto, y el archivo de PID se borra solo si esa señal tuvo éxito. Un archivo de PID que quedó de una ejecución anterior puede nombrar un PID que el sistema ya reutilizó, así que si no tienes la certeza de que siga siendo el tuyo, imprime primero la línea de comandos de ese PID y mátalo solo si aparece serve.
```
# en el RECEPTOR, una vez verificado
ps -p "$(cat ~/relayium-serve.pid)" -o command=
kill "$(cat ~/relayium-serve.pid)" && rm ~/relayium-serve.pid
```

Cómo se ve un espejo terminado

du -sh informa del mismo total en los dos servidores, y el bucle until te ha devuelto a un prompt de shell normal en lugar de reintentar otra vez. Que los totales coincidan es una comprobación gruesa de completitud, no una prueba de integridad: sync decidió por tamaño y mtime qué archivos no enviar, así que el total no dice nada del contenido de los archivos que omitió.

# the same total, on BOTH servers
46G	/root/workspace

Lo que sync envió está verificado: cada archivo transferido se comprobó con SHA-256 al llegar, y una salida limpia significa que ninguna de esas comprobaciones falló. Lo que omitió solo se cotejó por tamaño y mtime, así que unos totales de du -sh iguales son una comprobación de sensatez sobre la completitud, no una prueba de que el contenido omitido siga coincidiendo. Si necesitas esa prueba, compara las sumas de verificación archivo por archivo en los dos servidores.

Resolución de problemas

En un espejo de varias horas aparecen seis cosas. Tres parecen fallos y no lo son; las otras tres sí, y cada una tiene un comando que dice cuál tienes delante.

Síntoma, comprobación, solución

Hace mucho que no se imprime nada y la transferencia parece atascada.

# en el EMISOR, dos veces, con unos segundos de diferencia
ss -tinp dst :9031
# ESTAB    se alcanzó el proceso a la escucha; no prueba que los bytes se muevan
# SYN-SENT no alcanza al proceso a la escucha

El progreso solo se imprime cuando termina un archivo, así que un único archivo grande se transfiere en completo silencio. ESTAB solo demuestra alcanzabilidad — un socket establecido puede quedarse inactivo o atascado — y por sí solo nunca es prueba de avance. Ejecuta la comprobación dos veces con unos segundos de diferencia y compara el contador bytes_acked que -i imprime para ese socket: si sube, la transferencia avanza; si no cambia, es un atasco real.

El socket se queda en SYN-SENT y la transferencia no arranca en absoluto.

# en el RECEPTOR
sudo ufw allow from 203.0.113.9 to any port 9031 proto tcp
ss -tlnp | grep 9031

El puerto está bloqueado. Abre 9031/TCP solo al emisor — sustituye 203.0.113.9 por la dirección del propio emisor, su IP pública o la privada si los dos servidores comparten red — acota el grupo de seguridad en la nube a esa misma fuente y luego comprueba que serve está realmente a la escucha. Es la causa más frecuente de una transferencia que nunca empieza.

Pegar el comando de segundo plano deja la shell en un prompt de continuación >.

tmux new -s xfer
until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done

Un comando nohup de varias líneas con comillas y una redirección > suele romperse en la redirección al pegarlo. Usa en su lugar tmux con este bucle de una sola línea: no hay redirección que equivocar, y puedes volver a conectarte para mirarlo.

La limpieza mató algo que no querías matar.

pgrep -af relayium
ps -p "$(cat ~/relayium-serve.pid)" -o command=
tmux kill-session -t xfer
kill "$(cat ~/relayium-serve.pid)" && rm ~/relayium-serve.pid

Matar por patrón de línea de comandos envía la señal a todo proceso cuya línea de comandos contenga ese texto, que en una máquina con más de una transferencia en marcha no es el que querías. Tampoco detiene el espejo: el bucle until es el dueño del sync, así que un hijo muerto vuelve a arrancar diez segundos después. Mira con pgrep -af y luego termina lo que esta guía realmente posee: tmux kill-session -t xfer acaba con el bucle, y un kill al PID que hay en ~/relayium-serve.pid detiene el proceso a la escucha que lanzaste. Si el archivo de PID lleva ahí desde una ejecución anterior, imprime su línea de comandos antes de señalarlo, porque un PID que el sistema ha reutilizado pertenece a algo completamente distinto.

Quieres dejar fuera un subdirectorio y no existe ninguna opción de exclusión.

relayium sync /root/workspace/src /root/workspace/data relayium://203.0.113.43:9031

sync acepta -i y -p, --delete, --watch y --config-dir; nada que filtre una ruta en medio del árbol. Nombra en su lugar los subdirectorios que sí quieres: cada fuente llega bajo el --dir del receptor con su propio nombre, así que frente a serve --dir /root/workspace este comando reconstruye /root/workspace/src y /root/workspace/data y nunca recorre un venv regenerable.

Una fuente que esperabas duplicar llega vacía.

relayium sync ./links relayium://203.0.113.43:9031
# warning: no regular files to send (symlinks and special files are skipped)

sync solo transfiere archivos regulares, y ese aviso es exactamente el aspecto de un árbol hecho únicamente de enlaces simbólicos. Apunta sync a los directorios a los que apuntan los enlaces, y crea aparte en el receptor los enlaces que necesites.

Preguntas frecuentes

¿Qué pasa si la transferencia se interrumpe a mitad de camino?

No se pierde nada. Vuelve a ejecutar relayium sync: se salta los archivos que ya están en el receptor y reanuda un archivo enviado a medias desde el desplazamiento de bytes que ya está en disco. El bucle until de esta guía lo hace automáticamente hasta que toda la carpeta queda replicada.

¿En qué se diferencia esto de rsync?

Ambos hacen replicación incremental unidireccional, pero relayium sync se ejecuta sobre una conexión TLS fijada sin necesidad de cuenta SSH (daemon directo), autentica las dos máquinas por huella de certificado y verifica con SHA-256 cada archivo que transfiere. Igual que rsync por defecto, un archivo cuyo tamaño y mtime ya coinciden en el receptor se omite en lugar de volver a hashearse. Es el mismo motor de transferencia que los otros modos de relayium.

¿sync elimina en el receptor los archivos que quité del origen?

Solo si lo pides. Por defecto sync solo añade y actualiza. Pasa --delete para replicar las eliminaciones, y el receptor debe ejecutar serve con --allow-delete para que se respeten; de lo contrario la eliminación se ignora y se informa de vuelta.

¿Puedo mantener dos carpetas sincronizadas de forma continua?

Sí. Añade --watch y sync se mantiene en ejecución, volviendo a replicar ante cualquier cambio bajo el origen. Para un traslado puntual de una carpeta grande no lo necesitas: el bucle de reintentos más un sync normal bastan.

¿Tengo que abrir un puerto?

Para daemon directo, sí: el puerto del proceso a la escucha (9031 por defecto) debe ser alcanzable desde el emisor. Si prefieres no abrir un puerto y ya tienes SSH entre los servidores, sync también funciona sobre SSH: relayium sync /path user@host:/path (relayium debe estar instalado en el remoto).

Replica una carpeta entre dos de tus propios servidores: incremental, reanudable, sin tener que vigilar.

Obtener la CLI