Automatiza copias de seguridad cifradas del servidor con una tarea cron

Última actualización: 2026-09-01

Las copias de seguridad que tienes que acordarte de ejecutar no ocurren. cron sí se acuerda, y la CLI de Relayium está hecha para eso: un único comando no interactivo que copia (o replica) un directorio a otra máquina y verifica cada archivo que transfiere.

Esta guía cubre cómo programar relayium push y el relayium sync incremental desde cron, los dos transportes a los que puedes apuntar cualquiera de ellos, y las líneas de crontab para copiar.

push frente a sync: copia completa o réplica incremental

Tanto push como sync mueven un directorio a otra máquina y ambos son seguros de ejecutar repetidamente, pero resuelven problemas de copia de seguridad ligeramente distintos.

push envía una copia por SSH o daemon-direct cada vez que lo ejecutas: sencillo, e incluso funciona contra un servidor pelado sin relayium instalado gracias a un respaldo con tar. sync, en cambio, mantiene el destino como una réplica incremental unidireccional del origen: solo se reenvían los archivos cambiados, así que un sync nocturno de un directorio grande es rápido después de la primera ejecución. sync siempre necesita el protocolo nativo de relayium en ambos extremos: no tiene respaldo con tar.

Usa push para una copia programada sencilla, sobre todo hacia un servidor que quizá no tenga relayium instalado.
Usa sync para un directorio grande o que cambia con frecuencia, donde reenviar todo cada noche sería un desperdicio.
Ambos verifican lo que transfieren con un SHA-256 por archivo en el protocolo nativo. Ni push ni pull reanuda; de los tres, solo sync continúa un archivo parcial, y la alternativa con tar no verifica ni reanuda nada.

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 ».

Dos transportes: SSH o daemon-direct

Apunta cualquiera de los comandos a un destino SSH (al estilo scp, usando tu ~/.ssh/config) o, si la otra máquina ejecuta relayium serve, directamente a ella por el protocolo daemon-direct, sin necesidad de SSH.

# destino SSH — usa tus claves y tu configuración de SSH existentes
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct — el destino ejecuta "relayium serve", no hace falta SSH
relayium push ./data relayium://backup-server:9031

Las conexiones daemon-direct usan TLS 1.3 fijado con confianza en el primer uso, y luego se comprueban contra esa misma huella en cada ejecución posterior.
sync acepta las mismas dos formas de destino que push.

Prográmalo con cron

Lo que necesitas antes del paso 1

La CLI en esta máquina, y también en el destino si piensas usar sync. sync no tiene repliegue a tar.
Una clave SSH sin frase de paso, o un destino que ejecute relayium serve. cron no tiene agente ni terminal, así que no puede responder a una petición de frase de paso.
Un directorio de origen que exista en el momento en que cron se dispara, no uno en un montaje de red que solo está presente mientras tienes la sesión abierta.
Un sitio donde escribir un registro. Una tarea de cron cuya salida no va a ninguna parte es una copia de seguridad de la que te enterarás el día que la necesites.

Tanto push como sync son comandos únicos y no interactivos, así que se integran directamente en un crontab. Apúntalos a una clave SSH sin frase de contraseña (o a un agente) y registra la salida para que los fallos sean visibles:

# copia completa cada noche a las 2 — añádela a tu crontab (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/$(date +\%F)/ >> ~/relayium-backup.log 2>&1

# en su lugar, réplica incremental cada 15 minutos
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

Averigua dónde está realmente relayium. cron no usa el PATH de tu shell, e install.sh se repliega a ~/.local/bin cuando no puede escribir en /usr/local/bin, que es justo el sitio que cron nunca ve.
```
command -v relayium
```
Comprueba que la clave funciona sin nadie al teclado. BatchMode=yes falla en lugar de preguntar, que es exactamente la situación de cron.
```
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
```
Ejecuta la orden entera a mano una vez, escrita exactamente como la ejecutará cron, ruta absoluta incluida.
```
/usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/
```
Solo entonces añade la programación. Conserva la ruta absoluta y la redirección.
```
crontab -e
```
Tras la primera ejecución programada, lee el registro en vez de suponer. Es el paso que la gente se salta, y es el que se lo habría dicho.
```
tail -n 20 ~/relayium-backup.log
```

Qué aspecto tiene un montaje que funciona

relayium se resuelve a una ruta absoluta que puedes pegar en el crontab, y la comprobación de ssh con BatchMode termina con 0 sin imprimir ni pedir nada. Una copia de seguridad que solo funciona desde tu shell interactiva todavía no está programada.

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ echo $?
0

El comando termina con un código distinto de cero si algún archivo falla su comprobación de integridad, así que el aviso por correo de cron ante fallos detecta los problemas.
Un sync interrumpido se pone al día en la siguiente ejecución programada: lo que ya coincide se salta y un archivo parcial se continúa. Un push interrumpido no reanuda, pero como cada noche escribe en su propio directorio con fecha, la noche siguiente es una copia completa y limpia en lugar de un rechazo.

Replicar borrados y sincronización en tiempo real

De forma predeterminada, sync solo añade o actualiza archivos en el destino. Añade --delete para convertirlo en una réplica de verdad que también elimina los archivos que el origen ya no tiene: el lado receptor debe estar escuchando explícitamente con serve --allow-delete, o los borrados se omiten en silencio y se informan de vuelta como denegados. sync además rechaza --delete de plano si el directorio de origen no se resuelve en ningún archivo, de modo que un error de tecleo en la ruta de origen no puede vaciar el destino.

Si prefieres no esperar al siguiente tic de cron, --watch mantiene relayium sync en ejecución y vuelve a sincronizar automáticamente un instante después de que cambie cualquier archivo bajo el origen: una alternativa ligera al sondeo programado.

relayium sync ./data user@backup-server:/srv/backups/ --delete replica los borrados (el receptor necesita serve --allow-delete).
relayium sync ./data user@backup-server:/srv/backups/ --watch se mantiene en ejecución y vuelve a sincronizar al cambiar algo, en lugar de ejecutarse una sola vez desde cron.

Cuando no funciona

Todos estos casos son invisibles hasta que miras el registro: por eso la redirección va en la línea del crontab y no es opcional. El quinto es peor que invisible, porque parece un éxito.

Síntoma, comprobación, solución

El registro dice relayium: command not found, pero la misma orden funciona en tu shell.

tail -n 5 ~/relayium-backup.log
# /bin/sh: relayium: command not found

cron corre con un PATH mínimo, normalmente solo /usr/bin:/bin. Si install.sh no pudo escribir en /usr/local/bin, el binario está en ~/.local/bin, donde cron no mirará jamás. Pon en la línea del crontab la ruta absoluta que da command -v, o añade una línea PATH= al principio del crontab.

El registro muestra la conexión ssh rechazada, o nada después de la primera ejecución.

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

cron no tiene ssh-agent ni terminal, así que una clave con frase de paso solo puede colgarse o fallar. Apunta -i a una clave sin frase de paso reservada para las copias, y compruébalo con BatchMode=yes, que se niega a preguntar en lugar de esperar a alguien que no está.

sync se ejecuta limpiamente, pero los archivos borrados en el origen siguen en el destino.

grep -i deni ~/relayium-sync.log

El borrado se activa en el lado receptor. Sin serve --allow-delete enfrente, los borrados se omiten y se informan como denegados, y por eso la respuesta está en el registro y no en el código de salida. Reinicia el receptor del otro lado con --allow-delete.

sync rechaza --delete de plano.

relayium sync ~/documents user@backup-server:/srv/backups/ --delete
# refusing --delete with an empty source: this would delete everything on the destination. Check the path(s).

El origen no resolvió ningún archivo, así que el espejo habría vaciado el destino. Ese rechazo es deliberado. Revisa la ruta por si hay una errata, y comprueba que lo que deba estar montado ahí lo esté a la hora en que se dispara cron y no solo cuando tienes sesión abierta.

La copia se ejecuta, termina con 0, y no es lo que crees.

ssh user@backup-server command -v relayium

Cuando la máquina remota no tiene relayium, push se repliega a un flujo tar simple sobre SSH. Los archivos llegan, así que nada se queja, pero ese camino no tiene verificación SHA-256 por archivo ni comprobación de colisiones por adelantado, que son justo las dos razones para programar esto en lugar de un scp. Instala la CLI en el destino para recuperarlas. sync no tiene este fallo: como no tiene ningún repliegue, falla ruidosamente.

Preguntas frecuentes

¿El servidor de copias de seguridad necesita relayium instalado?

Depende del comando. push funciona de cualquier forma: con relayium instalado usa el protocolo nativo (comprobación de colisiones por adelantado + SHA-256 por archivo); sin él, push recurre a un simple flujo tar por SSH, así que un servidor pelado sigue funcionando. sync siempre necesita el protocolo nativo de relayium en el extremo remoto: no hay respaldo con tar para sync, así que instálalo allí primero.

¿La copia de seguridad va cifrada y verificada?

Sí. Cada archivo se comprueba con un hash SHA-256 de extremo a extremo, y al enviar por SSH o daemon-direct los bytes ya están protegidos por el cifrado de esa conexión: nada más que configurar.

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

Depende de qué comando hayas programado. sync continúa: la siguiente ejecución se salta lo que ya coincide y sigue con un archivo parcial, y --no-resume desactiva eso. push no reanuda en ninguno de los dos protocolos: rechaza un destino que ya existe, que es la razón por la que la línea push de arriba escribe en un directorio con fecha, de modo que la noche siguiente es una copia completa y limpia en lugar de un rechazo. --no-resume se acepta en push y no hace nada.

¿Puede --delete vaciar mi destino por accidente?

sync se niega a ejecutarse con --delete si el directorio de origen no contiene ningún archivo, y el receptor tiene que iniciarse con serve --allow-delete para que los borrados surtan efecto siquiera; de lo contrario se omiten y se te informa de ello.

¿Necesito una cuenta o esto cuesta algo?

No. La CLI es gratis y no necesita cuenta para push, pull ni sync: la transferencia va por tu propia conexión SSH o una conexión de daemon directo, no a través de los servidores de Relayium.

Pon tus copias de seguridad en un calendario que no tienes que recordar: cifradas en tránsito, verificadas por archivo y gratis.

Obtener la CLI