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

Última actualización: 2026-07-08

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 cada archivo de extremo a extremo.

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 cada archivo: cada archivo se comprueba con SHA-256 de extremo a extremo, así que se sabe que un espejo completado está intacto.
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

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

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.

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:

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

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:

# en el EMISOR
tmux new -s xfer      # apt install -y tmux si falta

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 ejecutándose después de que cierres la terminal. Vuelve a conectarte con tmux attach -t xfer.
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:

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

# en el RECEPTOR, una vez verificado
pkill -f 'relayium serve'

Cada archivo se comprobó con SHA-256 al llegar, así que tamaños coincidentes más una salida limpia significan una copia intacta.

Resolución de problemas

Algunas cosas que parecen problemas pero normalmente no lo son, y la que normalmente sí lo es (un puerto bloqueado).

La falta de salida no es un atasco. El progreso solo se imprime cuando cada archivo termina, así que un archivo grande se transfiere en silencio. Comprueba el estado real en el emisor con ss -tnp | grep 9031 — ESTAB significa que está conectado y transfiriendo; SYN-SENT significa que no puede alcanzar el proceso a la escucha.
SYN-SENT significa que el puerto está bloqueado. Abre 9031/TCP al emisor en el receptor (grupo de seguridad en la nube, o ufw allow 9031/tcp). Esta es la causa más común de una transferencia que nunca empieza.
Prefiere tmux más un bucle de una sola línea antes que un nohup de varias líneas. Pegar en una shell un comando de varias líneas con comillas y una redirección > a menudo se rompe en la redirección o te deja en un prompt de continuación >.
Al limpiar procesos, haz una coincidencia precisa (pkill -f 'relayium sync'), no pkill relayium — una coincidencia amplia puede matar un proceso relayium no relacionado que se ejecute en la misma máquina.
No hay ninguna opción de exclusión: nombra tus orígenes en su lugar. sync acepta -i y -p (identidad y puerto SSH), --delete, --watch y --config-dir, y nada que filtre una ruta en medio del árbol. Para dejar atrás un directorio regenerable como un virtualenv de Python, sincroniza los subdirectorios que de verdad quieres: sync admite varios orígenes a la vez, y cada uno llega bajo el --dir del receptor con su propio nombre. relayium sync /root/workspace/src /root/workspace/data relayium://203.0.113.43:9031 contra serve --dir /root/workspace los reconstruye en /root/workspace/src y /root/workspace/data, y el venv no se recorre nunca.
Los enlaces simbólicos y los archivos especiales se saltan — sync solo transfiere archivos regulares. Maneja por separado cualquier enlace simbólico importante.

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 cada archivo con SHA-256. 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