Haz copias de seguridad de archivos en tu propio servidor por SSH con la CLI de Relayium

Última actualización: 2026-09-01

Si ya tienes acceso SSH a una máquina — un VPS, un servidor doméstico, un NAS, una estación de trabajo —, puedes hacer copias de seguridad de tus archivos en ella con la CLI de Relayium sin montar un servicio de sincronización ni una cuenta. La transferencia se ejecuta sobre tu conexión SSH existente, así que los bytes van directos a tu servidor y nunca pasan por Relayium.

Esta guía cubre cómo hacer push y pull de directorios, qué cubre y qué no cubre la comprobación de integridad, por qué push se niega a ejecutarse dos veces hacia el mismo destino, y cómo ejecutarlo de forma programada con cron.

Antes de empezar

Todo lo de abajo es la CLI de relayium, así que instálala primero si aún no la tienes. En macOS o Linux, un solo comando deja un binario precompilado en tu PATH:

curl -fsSL https://relayium.com/install.sh | sh

¿Prefieres elegir el archivo tú mismo, o estás en Windows? Coge un binario de la página de releases — relayium.com/cli lista todas las opciones de instalación (o go build -o relayium ./cmd/relayium si tienes Go).
relayium --version confirma que está instalada. Sáltate esto y los comandos de abajo solo imprimirán « command not found ».

Envía (push) un directorio a tu servidor

Lo que necesitas

El acceso SSH que ya usas. ssh user@your-server true tiene que volver en silencio: push reutiliza exactamente esa conexión y no configura nada por su cuenta.
Un destino con permiso de escritura en el servidor. El directorio padre de la ruta de destino debe existir y ser escribible por ese usuario SSH.
Opcionalmente relayium en el servidor, que es lo que aporta la comprobación de colisiones por adelantado y el SHA-256 por archivo. Sin él, push sigue funcionando mediante un simple flujo tar, que no verifica nada.
Ninguna cuenta de Relayium y ningún demonio en ninguno de los dos extremos. Nada de esto habla con los servidores de Relayium.

push toma una o más fuentes y un destino al estilo scp. Relayium se conecta por SSH usando tus claves y tu configuración habituales, y luego transmite los archivos al directorio de destino:

Confirma el acceso SSH que push va a reutilizar. Un retorno silencioso significa que tus claves, tu alias de host y tu puerto ya son correctos.
```
ssh user@your-server true
```
Averigua qué protocolo vas a obtener. Una ruta indica el protocolo nativo —comprobación de colisiones por adelantado y SHA-256 por archivo—; ninguna salida indica el flujo tar, que no comprueba nada archivo por archivo.
```
ssh user@your-server command -v relayium
```
Envía el directorio. El destino es al estilo scp, y la barra final significa «dentro de este directorio».
```
relayium push ./photos user@your-server:backups/
```
Indica la clave o el puerto solo para este comando si tu configuración de ssh todavía no cubre ese host.
```
relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/
```
Comprueba qué llegó. push ./photos recrea photos/ bajo el destino, así que el nombre de la carpeta viaja con ellos.
```
ssh user@your-server ls backups/photos
```

Cómo se ve una ejecución correcta

Con el protocolo nativo, push imprime una línea por archivo terminado y sale con 0. Contra un servidor sin nada instalado imprime una sola línea de resumen: esa es la vía tar, y también es un éxito.

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)

# against a server with no relayium installed, one summary line instead:
sent 2 file(s) (zero-dependency mode)

Reutiliza tu ~/.ssh/config, así que los alias de host, las claves y los puertos que ya configuraste funcionan sin más.
Si relayium está instalado en el servidor, usa el protocolo nativo: se comprueba todo el lote en busca de colisiones antes de enviar un solo byte, y cada archivo que transfiere se verifica por SHA-256 y se coloca en un área temporal antes de instalarlo.
Si no lo está, recurre a canalizar un flujo tar hacia la máquina remota, de modo que hasta un servidor sin nada instalado y sin relayium funciona.

Recupera (pull) los archivos

Restaurar es el mismo comando a la inversa: indica una fuente remota y un directorio de destino local. Así recuperas una copia de seguridad, o sincronizas la salida de un servidor hacia tu portátil:

relayium pull user@your-server:backups/ ./restore

A diferencia de push, pull siempre necesita relayium ya instalado en el remoto — no tiene alternativa con tar, así que instálalo allí primero si falta.

La integridad viene de serie — la reanudación no

Cuando relayium está en ambos extremos, cada archivo que push transfiere se verifica de extremo a extremo con un hash SHA-256 y se coloca en un área temporal antes de instalarlo — lo que llega al servidor es byte por byte lo que enviaste. Eso sí es real, y es la razón para instalar relayium en el destino.

Lo que push no hace es reanudar. Los archivos se instalan de uno en uno según van pasando, así que una conexión que se corta a medias deja en su sitio los que ya llegaron — y como ahora existen, volver a lanzar el mismo push lo rechaza la comprobación de colisiones en lugar de continuar. Envía los archivos que faltan de forma explícita, o usa relayium sync, que es el modo que se salta lo que ya coincide y que sí continúa un archivo parcial en una ejecución posterior.

--no-resume se acepta en push y pull y allí no hace nada. Es real en un proceso serve a la escucha que recibe un sync, que es donde puede existir un archivo parcial.

Ni push ni pull reanuda, en ninguno de los dos protocolos. Usa sync para un directorio que esperes que se interrumpa; la alternativa con tar no reanuda ni verifica nada archivo por archivo.
La comprobación SHA-256 se ejecuta automáticamente; una discrepancia se informa y ese archivo se marca como fallido.

Ejecútalo de forma programada con cron

Programa sync, no push. push rechaza un destino que ya existe, así que un push nocturno al mismo directorio tiene éxito una vez y se rechaza todas las noches siguientes. sync es el modo pensado para una ejecución repetida: se salta los archivos cuyo tamaño y fecha de modificación no han cambiado, envía solo lo que cambió y continúa un archivo parcial que dejó una ejecución interrumpida. Es un único comando no interactivo que usa tus claves SSH, así que encaja directamente en cron. Apúntalo a una clave sin frase de contraseña (o a un agente), y registra la salida para poder ver los fallos:

# copia de seguridad cada noche a las 2 — añádela a tu crontab (crontab -e)
0 2 * * * relayium sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

Un sync nocturno que se interrumpe simplemente continúa la noche siguiente: lo que ya coincide se salta, y un archivo parcial se continúa en lugar de empezarse de nuevo.
El comando termina con un código distinto de cero si algún archivo falla su comprobación de integridad, así que el correo de fallo de cron detecta los problemas.

Cuando una copia no llega

Una copia programada falla en silencio por naturaleza: nadie está mirando el terminal. Estos cuatro casos cubren casi todo, y cada uno se decide con un comando que puedes ejecutar ahora mismo.

Síntoma, comprobación, solución

La tarea de cron se queda colgada, o el registro termina en una petición de contraseña.

ssh -i ~/.ssh/backup_key -o BatchMode=yes user@your-server true
# Permission denied (publickey).

BatchMode=yes se niega a preguntar y falla, lo que convierte un cuelgue mudo en esta línea. Añade la parte pública de esa clave al ~/.ssh/authorized_keys del servidor, o apunta la tarea a una clave que el agente ya tenga cargada.

La línea del crontab se ejecuta pero el registro sigue vacío.

command -v relayium
# /usr/local/bin/relayium

cron corre con un PATH mínimo que normalmente no incluye /usr/local/bin, así que la línea falla antes de que relayium arranque. Escribe en la entrada del crontab la ruta absoluta que acaba de imprimir la comprobación, y conserva la redirección >> ~/relayium-backup.log 2>&1 para que el próximo fallo se vea.

Un sync nocturno interrumpido vuelve a empezar desde cero en la ejecución siguiente.

ssh user@your-server command -v relayium
# (no imprime nada)

Falta relayium en el remoto. sync no tiene alternativa alguna y por tanto ni siquiera arranca, y push cae al flujo tar, que no verifica nada y siempre reenvía cada archivo entero. Instálalo en el servidor. Solo sync continúa un archivo parcial en la ejecución siguiente: ni push ni pull reanuda, en ninguno de los dos protocolos. Si ya usas sync, comprueba además que no estás pasando --no-resume, que desactiva a propósito esa reanudación en el proceso a la escucha.

«N file(s) failed integrity check» y una salida distinta de cero.

relayium push ./photos user@your-server:backups/
# 1 file(s) failed integrity check: [photos/IMG_0413.jpg]
echo $?
# 1

El SHA-256 calculado al llegar no coincidió con el enviado, y el protocolo nativo deja cada archivo en una zona temporal y solo lo instala cuando el hash cuadra: esa ruta nunca se escribió en el servidor y allí no hay nada que borrar. Repetir el lote entero lo sigue rechazando la comprobación de colisiones, porque los demás archivos de ese lote ya están en su sitio, así que repite el push solo con esa ruta. Si vuelve a fallar no es un error puntual de tránsito: revisa el archivo de origen (si algo escribe en él mientras se lee) y el almacenamiento de ambos lados.

Preguntas frecuentes

¿Los archivos pasan por los servidores de Relayium?

No. push y pull se ejecutan enteramente sobre tu propia conexión SSH. Los servidores de Relayium nunca intervienen y no necesitas ninguna cuenta.

¿El servidor necesita tener relayium instalado?

Depende de la dirección. Para push es opcional: con relayium en el remoto obtienes el protocolo nativo — una comprobación de colisiones por adelantado y comprobaciones SHA-256 por archivo sobre todo lo que transfiere — y sin él, push recurre a un simple flujo tar sobre SSH, que sigue funcionando pero no verifica nada archivo por archivo. Para pull es obligatorio: pull siempre necesita relayium en el remoto (no tiene alternativa con tar), así que instálalo allí primero.

¿Cómo elige qué clave SSH y qué puerto usar?

Lee tu ~/.ssh/config igual que hace ssh, así que los alias de host, las claves y los puertos se recogen automáticamente. También puedes sobrescribirlos por comando con -i para el archivo de identidad y -p para el puerto.

¿Es más rápido que rsync?

Para enviar a tu propio servidor está en el mismo orden de magnitud que rsync sobre SSH; el objetivo no es superar a rsync, sino darte una sola herramienta que además hace transferencias entre redes y de servidor a servidor con la misma comprobación de integridad por archivo.

Haz la copia de seguridad de tu próximo directorio de la forma directa — por tu propio SSH, con comprobación de integridad por archivo y gratis.

Obtener la CLI