Faça backup de arquivos no seu próprio servidor via SSH com a CLI do Relayium

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

Se você já tem acesso SSH a uma máquina — um VPS, um servidor doméstico, um NAS, uma estação de trabalho —, pode fazer backup dos seus arquivos nela com a CLI do Relayium sem montar um serviço de sincronização nem uma conta. A transferência roda sobre a sua conexão SSH existente, então os bytes vão direto para o seu servidor e nunca passam pelo Relayium.

Este guia aborda como fazer push e pull de diretórios, o que a verificação de integridade cobre e o que não cobre, por que o push se recusa a rodar duas vezes para o mesmo destino, e como executá-lo de forma agendada com o cron.

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

Envie (push) um diretório para o seu servidor

O que você precisa

O acesso SSH que você já usa. ssh user@your-server true precisa voltar em silêncio: o push reaproveita exatamente essa conexão e não configura nada por conta própria.
Um destino com permissão de escrita no servidor. O diretório pai do caminho de destino tem de existir e ser gravável por aquele usuário SSH.
Opcionalmente o relayium no servidor, que é o que traz a checagem de colisão antecipada e o SHA-256 por arquivo. Sem ele o push continua funcionando, por um fluxo tar simples que não verifica nada.
Nenhuma conta do Relayium e nenhum daemon em qualquer das pontas. Nada disso conversa com os servidores do Relayium.

O push recebe uma ou mais origens e um destino no estilo scp. O Relayium se conecta por SSH usando suas chaves e sua configuração de sempre e, em seguida, transmite os arquivos para o diretório de destino:

Confirme o acesso SSH que o push vai reaproveitar. Um retorno silencioso significa que suas chaves, seu apelido de host e sua porta já estão certos.
```
ssh user@your-server true
```
Descubra qual protocolo você vai usar. Um caminho indica o protocolo nativo — checagem de colisão antecipada e SHA-256 por arquivo; nenhuma saída indica o fluxo tar, que não confere nada arquivo por arquivo.
```
ssh user@your-server command -v relayium
```
Envie o diretório. O destino é no estilo scp, e a barra no fim significa “para dentro deste diretório”.
```
relayium push ./photos user@your-server:backups/
```
Informe a chave ou a porta só para este comando se a sua configuração de ssh ainda não cobre esse host.
```
relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/
```
Confira o que chegou. push ./photos recria photos/ sob o destino, então o nome da pasta vai junto.
```
ssh user@your-server ls backups/photos
```

Como é uma execução bem-sucedida

No protocolo nativo, o push imprime uma linha por arquivo concluído e sai com 0. Contra um servidor sem nada instalado ele imprime uma única linha de resumo: esse é o caminho do tar, e também é sucesso.

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)

Ele reaproveita seu ~/.ssh/config, então os apelidos de host, as chaves e as portas que você já configurou simplesmente funcionam.
Se o relayium estiver instalado no servidor, ele usa o protocolo nativo: o lote inteiro é checado por colisões antes de qualquer byte sair, e cada arquivo transferido é verificado por SHA-256 e preparado em área temporária antes de ser instalado.
Se não estiver, ele recorre a canalizar um fluxo tar para a máquina remota, de modo que até um servidor sem nada instalado e sem relayium funciona.

Traga os arquivos de volta (pull)

Restaurar é o mesmo comando ao contrário: informe uma origem remota e um diretório de destino local. É assim que você recupera um backup ou sincroniza a saída de um servidor para o seu notebook:

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

Ao contrário do push, o pull sempre precisa do relayium já instalado no remoto — ele não tem alternativa com tar, então instale-o lá primeiro se estiver faltando.

A integridade já vem embutida — a retomada não

Quando o relayium está nas duas pontas, cada arquivo que o push transfere é verificado de ponta a ponta com um hash SHA-256 e preparado em área temporária antes de ser instalado — o que chega ao servidor é byte por byte o que você enviou. Isso é real, e é o motivo para instalar o relayium no destino.

O que o push não faz é retomar. Os arquivos são instalados um a um conforme passam, então uma conexão perdida no meio deixa no lugar os que já chegaram — e, como agora eles existem, repetir o mesmo push é recusado pela checagem de colisão em vez de continuar. Envie os caminhos que faltam explicitamente, ou use o relayium sync, que é o modo que pula o que já corresponde e que de fato continua um arquivo parcial em uma execução posterior.

--no-resume é aceito por push e pull e ali não faz nada. Ele é real em um serve à escuta que recebe um sync, que é onde um arquivo parcial pode existir.

Nem o push nem o pull retoma, em nenhum dos dois protocolos. Use o sync para um diretório que você espera ver interrompido; a alternativa com tar não retoma nem verifica nada arquivo por arquivo.
A verificação SHA-256 roda automaticamente; uma divergência é relatada e esse arquivo é marcado como falho.

Execute-o de forma agendada com o cron

Agende o sync, não o push. O push recusa um destino que já existe, então um push noturno para o mesmo diretório dá certo uma vez e é recusado em todas as noites seguintes. O sync é o modo feito para uma execução repetida: pula os arquivos cujo tamanho e data de modificação não mudaram, envia só o que mudou e continua um arquivo parcial deixado por uma execução interrompida. É um único comando não interativo que usa suas chaves SSH, então entra direto no cron. Aponte-o para uma chave sem frase-senha (ou para um agente) e registre a saída para conseguir ver as falhas:

# backup toda noite às 2h — adicione ao seu crontab (crontab -e)
0 2 * * * relayium sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

Um sync noturno que é interrompido simplesmente continua na noite seguinte: o que já corresponde é pulado, e um arquivo parcial é continuado em vez de recomeçado.
O comando encerra com código diferente de zero se algum arquivo falhar na verificação de integridade, então o e-mail de falha do cron detecta os problemas.

Quando um backup não chega

Um backup agendado falha em silêncio por natureza: ninguém está olhando o terminal. Estes quatro casos cobrem quase tudo, e cada um é decidido por um comando que você pode rodar agora.

Sintoma, verificação, correção

A tarefa do cron trava, ou o log termina num pedido de senha.

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

BatchMode=yes se recusa a perguntar e falha, o que transforma um travamento mudo nesta linha. Acrescente a parte pública dessa chave ao ~/.ssh/authorized_keys do servidor, ou aponte a tarefa para uma chave que o agente já carregou.

A linha do crontab roda, mas o log continua vazio.

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

O cron roda com um PATH mínimo que normalmente não tem /usr/local/bin, então a linha falha antes de o relayium começar. Escreva na entrada do crontab o caminho absoluto que a verificação acabou de imprimir, e mantenha o redirecionamento >> ~/relayium-backup.log 2>&1 para que a próxima falha apareça.

Um sync noturno interrompido recomeça do zero na execução seguinte.

ssh user@your-server command -v relayium
# (não imprime nada)

Falta o relayium no remoto. O sync não tem alternativa nenhuma e por isso nem chega a rodar, e o push cai no fluxo tar, que não verifica nada e sempre reenvia cada arquivo inteiro. Instale-o no servidor. Só o sync continua um arquivo parcial na execução seguinte: nem o push nem o pull retoma, em nenhum dos dois protocolos. Se você já usa o sync, confira também que não está passando --no-resume, que desliga de propósito essa retomada no processo à escuta.

“N file(s) failed integrity check” e uma saída diferente de zero.

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

O SHA-256 calculado na chegada não bateu com o enviado, e o protocolo nativo põe cada arquivo numa área temporária e só o instala quando o hash confere — então aquele caminho nunca foi escrito no servidor, e não há nada para remover lá. Rodar o lote inteiro de novo continua sendo recusado pela verificação de colisões, porque os outros arquivos daquele lote já estão no lugar, então rode o push de novo só naquele caminho. Se falhar outra vez, não é um erro de trânsito pontual: olhe o arquivo de origem (se algo escreve nele enquanto é lido) e o armazenamento dos dois lados.

Perguntas frequentes

Os arquivos passam pelos servidores do Relayium?

Não. O push e o pull rodam inteiramente sobre a sua própria conexão SSH. Os servidores do Relayium nunca são envolvidos e você não precisa de conta alguma.

O servidor precisa ter o relayium instalado?

Depende da direção. Para o push é opcional: com o relayium no remoto você obtém o protocolo nativo — uma checagem de colisão antecipada e verificações SHA-256 por arquivo em tudo o que ele transfere — e sem ele, o push recorre a um simples fluxo tar sobre SSH, que ainda funciona, mas não verifica nada arquivo por arquivo. Para o pull é obrigatório: o pull sempre precisa do relayium no remoto (ele não tem alternativa com tar), então instale-o lá primeiro.

Como ele escolhe qual chave SSH e qual porta usar?

Ele lê o seu ~/.ssh/config como o ssh faz, então os apelidos de host, as chaves e as portas são identificados automaticamente. Você também pode sobrescrevê-los por comando com -i para o arquivo de identidade e -p para a porta.

Isso é mais rápido que o rsync?

Para enviar ao seu próprio servidor, fica na mesma ordem de grandeza que o rsync sobre SSH; o objetivo não é vencer o rsync, mas dar a você uma única ferramenta que também faz transferências entre redes e de servidor para servidor com a mesma verificação de integridade por arquivo.

Faça o backup do seu próximo diretório da forma direta — pelo seu próprio SSH, com verificação de integridade por arquivo e gratuito.

Obter a CLI