Automatize backups criptografados do servidor com uma tarefa cron

Última atualização: 2026-09-01

Backups que você precisa lembrar de executar não acontecem. O cron lembra, e a CLI do Relayium foi feita para isso: um único comando não interativo que copia (ou espelha) um diretório para outra máquina e verifica cada arquivo que transfere.

Este guia aborda como agendar o relayium push e o relayium sync incremental pelo cron, os dois transportes para os quais você pode apontar qualquer um deles e as linhas de crontab para copiar.

push versus sync: cópia completa ou espelho incremental

Tanto push quanto sync movem um diretório para outra máquina e ambos são seguros para rodar repetidamente, mas resolvem problemas de backup um pouco diferentes.

push envia uma cópia por SSH ou daemon-direct a cada execução — simples, e funciona até contra um servidor pelado sem o relayium instalado, graças a um recurso alternativo com tar. Já o sync mantém o destino como um espelho incremental e unidirecional da origem: apenas os arquivos alterados são reenviados, então um sync noturno de um diretório grande fica rápido depois da primeira execução. O sync sempre precisa do protocolo nativo do relayium nas duas pontas — ele não tem recurso alternativo com tar.

Use push para uma cópia agendada direta, especialmente para um servidor que talvez não tenha o relayium instalado.
Use sync para um diretório grande ou que muda com frequência, onde reenviar tudo toda noite seria desperdício.
Ambos verificam o que transferem com um SHA-256 por arquivo no protocolo nativo. Nem o push nem o pull retoma; dos três, só o sync continua um arquivo parcial, e a alternativa com tar não verifica nem retoma nada.

Antes de começar

Tudo abaixo é a CLI do relayium, então instale-a primeiro se ainda não tiver. No macOS ou Linux, um comando coloca um binário pré-compilado no seu PATH:

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

Prefere escolher o arquivo você mesmo, ou está no Windows? Pegue um binário na página de releases — relayium.com/cli lista todas as opções de instalação (ou go build -o relayium ./cmd/relayium se você tiver Go).
relayium --version confirma que está instalada. Pule isso e os comandos abaixo só imprimirão “command not found”.

Dois transportes: SSH ou daemon-direct

Aponte qualquer um dos comandos para um destino SSH (no estilo scp, usando seu ~/.ssh/config) ou, se a outra máquina estiver rodando relayium serve, direto para ela pelo protocolo daemon-direct — sem precisar de SSH.

# destino SSH — usa suas chaves e sua configuração de SSH existentes
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct — o destino roda "relayium serve", sem precisar de SSH
relayium push ./data relayium://backup-server:9031

As conexões daemon-direct usam TLS 1.3 fixado com confiança no primeiro uso e, depois, são verificadas contra essa mesma impressão digital em todas as execuções seguintes.
O sync aceita as mesmas duas formas de destino que o push.

Agende com o cron

O que você precisa antes do passo 1

A CLI nesta máquina, e também no destino se pretende usar o sync. O sync não tem recurso ao tar.
Uma chave SSH sem frase secreta, ou um destino rodando relayium serve. O cron não tem agente nem terminal, então não consegue responder a um pedido de frase secreta.
Um diretório de origem que exista no momento em que o cron dispara — não um em montagem de rede que só está presente enquanto você está logado.
Um lugar para escrever um log. Uma tarefa de cron cuja saída não vai a lugar nenhum é um backup do qual você vai saber no dia em que precisar dele.

Tanto push quanto sync são comandos únicos e não interativos, então se encaixam direto em um crontab. Aponte-os para uma chave SSH sem senha (ou um agente) e registre a saída para que as falhas fiquem visíveis:

# cópia completa toda noite às 2h — adicione ao seu crontab (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/$(date +\%F)/ >> ~/relayium-backup.log 2>&1

# no lugar disso, espelho incremental a cada 15 minutos
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

Descubra onde o relayium realmente está. O cron não usa o PATH do seu shell, e o install.sh recorre a ~/.local/bin quando não consegue escrever em /usr/local/bin — exatamente o lugar que o cron nunca enxerga.
```
command -v relayium
```
Confirme que a chave funciona sem ninguém ao teclado. BatchMode=yes falha em vez de perguntar, que é justamente a situação do cron.
```
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
```
Rode o comando inteiro à mão uma vez, escrito exatamente como o cron vai rodar, caminho absoluto incluído.
```
/usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/
```
Só então adicione o agendamento. Mantenha o caminho absoluto e o redirecionamento.
```
crontab -e
```
Depois da primeira execução agendada, leia o log em vez de supor. É o passo que as pessoas pulam, e é o que teria contado.
```
tail -n 20 ~/relayium-backup.log
```

Como é uma configuração que funciona

O relayium resolve para um caminho absoluto que dá para colar no crontab, e a checagem de ssh com BatchMode termina em 0 sem imprimir nem pedir nada. Um backup que só funciona a partir do seu shell interativo ainda não está agendado.

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

O comando termina com código diferente de zero se algum arquivo falhar na verificação de integridade, então o aviso por e-mail em caso de falha do cron detecta os problemas.
Um sync interrompido se atualiza na próxima execução agendada: o que já corresponde é pulado e um arquivo parcial é continuado. Um push interrompido não retoma — mas, como cada noite escreve no seu próprio diretório com data, a noite seguinte é uma cópia completa e limpa em vez de uma recusa.

Espelhar exclusões e sincronização em tempo real

Por padrão, o sync apenas adiciona ou atualiza arquivos no destino. Adicione --delete para torná-lo um espelho de verdade, que também remove os arquivos que a origem não tem mais — o lado receptor precisa estar escutando explicitamente com serve --allow-delete, ou as exclusões são silenciosamente ignoradas e reportadas de volta como negadas. O sync também recusa --delete de imediato se o diretório de origem não resolver em nenhum arquivo, de modo que um erro de digitação no caminho de origem não pode apagar o destino.

Se você preferir não esperar o próximo ciclo do cron, --watch mantém o relayium sync em execução e sincroniza novamente de forma automática logo após qualquer arquivo sob a origem mudar — uma alternativa leve à sondagem agendada.

relayium sync ./data user@backup-server:/srv/backups/ --delete espelha as exclusões (o receptor precisa de serve --allow-delete).
relayium sync ./data user@backup-server:/srv/backups/ --watch permanece em execução e sincroniza novamente a cada mudança, em vez de rodar uma única vez pelo cron.

Quando não funciona

Cada um destes casos é invisível até você olhar o log — por isso o redirecionamento está na linha do crontab e não é opcional. O quinto é pior que invisível: ele parece sucesso.

Sintoma, checagem, correção

O log diz relayium: command not found, mas o mesmo comando funciona no seu shell.

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

O cron roda com um PATH mínimo, normalmente só /usr/bin:/bin. Se o install.sh não conseguiu escrever em /usr/local/bin, o binário está em ~/.local/bin, onde o cron nunca vai procurar. Use na linha do crontab o caminho absoluto que o command -v mostra, ou coloque uma linha PATH= no topo do crontab.

O log mostra a conexão ssh recusada, ou nada depois da primeira execução.

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

O cron não tem ssh-agent nem terminal, então uma chave com frase secreta só pode travar ou falhar. Aponte o -i para uma chave sem frase secreta reservada aos backups e confirme com BatchMode=yes, que se recusa a perguntar em vez de esperar por alguém que não está lá.

O sync roda limpo, mas os arquivos apagados na origem continuam no destino.

grep -i deni ~/relayium-sync.log

A exclusão é uma opção do lado receptor. Sem serve --allow-delete do outro lado, as exclusões são puladas e reportadas como negadas — por isso a resposta está no log e não no código de saída. Reinicie o receptor do outro lado com --allow-delete.

O sync recusa o --delete de saída.

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

A origem não resolveu nenhum arquivo, então o espelho teria esvaziado o destino. Essa recusa é proposital. Verifique o caminho por causa de um erro de digitação, e verifique se o que deveria estar montado ali está montado na hora em que o cron dispara, e não só quando você está logado.

O backup roda, sai com 0, e não é o que você pensa.

ssh user@backup-server command -v relayium

Quando a máquina remota não tem relayium, o push recorre a um fluxo tar simples sobre SSH. Os arquivos chegam, então nada reclama — mas esse caminho não tem verificação SHA-256 por arquivo nem checagem de colisão antecipada, que são exatamente os dois motivos para agendar isto em vez de um scp. Instale a CLI no destino para recuperá-las. O sync não tem essa falha: como não tem recurso nenhum, ele falha alto em vez disso.

Perguntas frequentes

O servidor de backup precisa do relayium instalado?

Depende do comando. push funciona nos dois casos: com o relayium instalado, ele usa o protocolo nativo (checagem de colisão antecipada + SHA-256 por arquivo); sem ele, push recorre a um fluxo tar simples por SSH, então um servidor pelado ainda funciona. O sync sempre precisa do protocolo nativo do relayium no lado remoto — não há recurso alternativo com tar para o sync, então instale-o lá primeiro.

O backup é criptografado e verificado?

Sim. Cada arquivo é conferido com um hash SHA-256 de ponta a ponta, e ao enviar por SSH ou daemon-direct os bytes já estão protegidos pela criptografia daquela conexão — nada mais a configurar.

O que acontece se a tarefa cron for interrompida no meio?

Depende de qual comando você agendou. O sync continua: a próxima execução pula o que já corresponde e leva adiante um arquivo parcial, e o --no-resume desliga isso. O push não retoma em nenhum dos dois protocolos — ele recusa um destino que já existe, que é o motivo de a linha de push acima escrever em um diretório com data, para que a noite seguinte seja uma cópia completa e limpa em vez de uma recusa. O --no-resume é aceito pelo push e não faz nada.

O --delete pode apagar meu destino por acidente?

O sync se recusa a rodar com --delete se o diretório de origem não contiver nenhum arquivo, e o receptor precisa ser iniciado com serve --allow-delete para que as exclusões tenham efeito — caso contrário, elas são ignoradas e reportadas a você.

Preciso de uma conta ou isso custa alguma coisa?

Não. A CLI é gratuita e não precisa de conta para push, pull ou sync — a transferência ocorre pela sua própria conexão SSH ou por uma conexão direta de daemon, não pelos servidores do Relayium.

Coloque seus backups em um cronograma que você não precisa lembrar — criptografados em trânsito, verificados por arquivo e gratuitos.

Obter a CLI