Administrar uma VPS não significa apenas manter a aplicação funcionando. Também é necessário pensar em backup, redundância e na forma mais segura de enviar arquivos para outro servidor ou serviço de armazenamento.

É nesse cenário que o rclone se destaca.

O rclone é uma ferramenta de linha de comando para gerenciamento de arquivos em armazenamento local e em dezenas de serviços de nuvem. Atualmente, sua documentação informa suporte a mais de 70 produtos de armazenamento, incluindo serviços compatíveis com S3, Google Drive, Dropbox, OneDrive, WebDAV, SFTP e diversos outros backends.

Neste artigo vamos partir do zero e montar uma solução prática para uma VPS Linux:

instalar o rclone;
configurar um armazenamento remoto;
testar a sincronização;
criar um serviço systemd;
agendar sua execução com systemd timer;
consultar os logs;
validar se os arquivos realmente chegaram ao destino.

O que é o rclone?

O rclone é um utilitário de linha de comando para copiar, sincronizar, mover, listar e gerenciar arquivos entre diferentes sistemas de armazenamento.

A sintaxe é intencionalmente parecida com ferramentas tradicionais do Linux, como cp, mv, ls e rsync, mas com foco especial em serviços de armazenamento remoto.

Um exemplo simples:

bash

rclone copy /var/backups remote:backups

Nesse exemplo:

/var/backups é a origem local;
remote: é o armazenamento remoto configurado;
backups é o diretório de destino.

O conceito de remote é importante. Em vez de criar um comando completamente diferente para cada provedor, configuramos o serviço uma vez e depois utilizamos uma interface consistente:

text

remote:path

Por exemplo:

text

gdrive:server-backups
s3:my-bucket
b2:backups
onedrive:servers

O nome remote é apenas um exemplo. Você pode escolher o nome que quiser durante a configuração.

Rclone é uma ferramenta de backup?

Essa é uma distinção importante.

O rclone é excelente para copiar e sincronizar arquivos, mas isso não significa que toda utilização do rclone seja automaticamente um sistema completo de backup.

Por exemplo:

bash

rclone copy /srv/app/backups remote:backups

copia arquivos para outro armazenamento.

Já:

bash

rclone sync /srv/app/backups remote:backups

faz com que o destino reflita a origem e pode remover arquivos que não existem mais na origem. A própria documentação alerta que sync pode causar perda de dados e recomenda testar com --dry-run ou --interactive.

Para uma rotina de backup, normalmente começo com:

bash

rclone copy

em vez de:

bash

rclone sync

Isso reduz o risco de que uma exclusão acidental na origem também provoque uma exclusão no destino.

Se a necessidade for manter histórico, snapshots, deduplicação e um repositório de backup versionado, ferramentas como o restic são mais apropriadas. O restic trabalha explicitamente com snapshots, deduplicação e criptografia do repositório.

Uma arquitetura bastante interessante é inclusive combinar as duas ferramentas: o restic cuida da estratégia de backup e o rclone fornece o armazenamento remoto.

Principais vantagens do rclone

1. Uma interface para vários provedores

Uma das maiores vantagens do rclone é evitar que cada serviço tenha uma ferramenta ou procedimento completamente diferente.

Você pode ter:

text

Google Drive
Amazon S3
Cloudflare R2
Backblaze B2
Dropbox
OneDrive
SFTP
WebDAV

e trabalhar com todos usando comandos do próprio rclone. A lista oficial de backends é extensa e continua incluindo novos provedores e protocolos.

2. Excelente para automação

Como tudo funciona pela linha de comando, o rclone se encaixa naturalmente em:

text

bash
systemd
cron
CI/CD
scripts
rotinas de backup
jobs de manutenção

Isso é especialmente útil em servidores Linux, onde queremos que uma tarefa possa ser executada sem interface gráfica.

3. Transferências entre armazenamentos

O rclone não precisa necessariamente trabalhar apenas entre “VPS → nuvem”.

Dependendo do backend, ele também pode realizar transferências entre armazenamentos remotos, reduzindo a necessidade de trazer os arquivos primeiro para o disco local. A documentação destaca justamente essa capacidade de trabalhar com transferências entre diferentes provedores quando suportado pelo backend.

Isso pode ser bastante útil em migrações.

4. Verificação e retomada

O rclone utiliza mecanismos de verificação baseados em metadados e hashes quando disponíveis, e possui comandos específicos para validar se origem e destino correspondem.

Também é possível executar novamente uma transferência interrompida sem necessariamente recomeçar tudo do zero.

5. Recursos além de cópia

O rclone não se limita a copiar arquivos.

Ele também possui recursos como:

bash

rclone mount
rclone check
rclone cryptcheck
rclone bisync
rclone serve

Além disso, existem backends virtuais para recursos como criptografia, compressão, união de storage e outros.

Rclone x rsync x restic

As ferramentas podem parecer semelhantes, mas atendem a objetivos diferentes.

Ferramenta	Principal objetivo	Armazenamento em nuvem	Snapshots	Deduplicação
Rclone	Copiar e sincronizar arquivos	Excelente	Não por padrão	Não
Rsync	Sincronização entre sistemas de arquivos	Indireto	Não	Não
Restic	Backup versionado	Excelente	Sim	Sim

O rsync continua sendo extremamente útil para sincronização de arquivos entre máquinas Linux e pode utilizar SSH como transporte.

O restic, por outro lado, foi projetado especificamente como ferramenta de backup e trabalha com snapshots, criptografia e deduplicação.

Já o rclone fica em uma posição interessante quando o problema é:

“Preciso enviar e gerenciar arquivos em um storage remoto de forma simples e automatizável.”

Instalando o rclone em uma VPS

A documentação oficial disponibiliza instalador para Linux e também binários pré-compilados.

Uma opção simples:

bash

sudo -v
curl https://rclone.org/install.sh | sudo bash

Depois:

bash

rclone version

O comando deve retornar a versão instalada.

Para ambientes em que prefiro controlar mais explicitamente o processo de instalação, também é possível baixar o binário oficial e instalá-lo manualmente. A documentação oficial detalha esse procedimento.

Configurando um remote

O próximo passo é criar a conexão com o serviço de armazenamento.

Execute:

bash

rclone config

O rclone abrirá um assistente interativo para criação do remote.

Depois de configurar:

bash

rclone listremotes

Podemos testar:

bash

rclone lsd remote:

ou:

bash

rclone ls remote:

Também podemos verificar onde está o arquivo de configuração:

bash

rclone config file

Em Linux, o caminho padrão normalmente fica em:

text

~/.config/rclone/rclone.conf

mas o caminho pode variar conforme a configuração do ambiente.

Configuração em uma VPS sem interface gráfica

Esse ponto aparece bastante quando usamos serviços que exigem autenticação via navegador.

Uma possibilidade é configurar o remote em outra máquina e depois transferir o arquivo de configuração para a VPS. O próprio rclone documenta esse procedimento.

Por exemplo:

bash

rclone config file

na máquina onde o remote foi configurado.

Depois podemos copiar o arquivo para o servidor:

bash

scp ~/.config/rclone/rclone.conf user@server:/tmp/rclone.conf

Na VPS:

bash

sudo install -d -m 700 /home/rclone/.config/rclone
sudo install -m 600 /tmp/rclone.conf /home/rclone/.config/rclone/rclone.conf
sudo chown -R rclone:rclone /home/rclone/.config

O importante é que o usuário que executará o serviço tenha acesso ao arquivo.

Criando um usuário específico para o backup

Eu prefiro não executar rotinas de backup automaticamente como root quando isso não é necessário.

Podemos criar um usuário dedicado:

bash

sudo useradd \
    --system \
    --create-home \
    --home-dir /home/rclone \
    --shell /usr/sbin/nologin \
    rclone

Depois:

bash

sudo install -d -m 700 /home/rclone/.config/rclone
sudo chown -R rclone:rclone /home/rclone

A ideia é simples:

text

root
  └── administra o servidor

rclone
  └── executa a rotina de backup

Isso reduz o impacto caso a rotina seja comprometida ou configurada incorretamente.

Primeiro teste manual

Antes de envolver systemd, devemos provar que o comando funciona.

Imagine que os backups da aplicação estejam em:

text

/var/backups/myapp

e que o remote seja:

text

remote:

Podemos começar com:

bash

sudo -u rclone rclone copy \
    /var/backups/myapp \
    remote:myapp

Para enxergar mais detalhes:

bash

sudo -u rclone rclone copy \
    /var/backups/myapp \
    remote:myapp \
    --progress \
    --log-level INFO

Antes de usar sync, uma boa prática é testar com:

bash

rclone sync \
    /var/backups/myapp \
    remote:myapp \
    --dry-run

O --dry-run permite observar o que seria alterado sem executar as mudanças.

`copy` ou `sync`?

Esse é provavelmente o detalhe mais importante de todo o artigo.

`copy`

bash

rclone copy origem destino

Copia arquivos novos ou alterados e não transforma o destino em um espelho exato da origem.

Para uma rotina simples de envio de backups, costuma ser uma opção mais conservadora.

`sync`

bash

rclone sync origem destino

Faz o destino corresponder à origem, incluindo exclusões quando aplicável.

Imagine:

text

ORIGEM
backup-01.sql
backup-02.sql

DESTINO
backup-01.sql
backup-02.sql
backup-03.sql

Com sync, o arquivo:

text

backup-03.sql

poderá ser removido do destino.

Por isso, sync deve ser usado conscientemente. A documentação oficial trata explicitamente essa operação como potencialmente destrutiva.

Usando `--backup-dir`

Quando realmente precisamos de sync, existe um recurso interessante:

bash

--backup-dir

Ele permite mover arquivos que seriam substituídos ou removidos para outro diretório de backup.

Por exemplo:

bash

rclone sync \
    /var/backups/myapp \
    remote:myapp \
    --backup-dir remote:myapp-old

Isso cria uma camada adicional de proteção para alterações e exclusões.

Ainda assim, eu não trataria isso como substituto de uma estratégia de retenção de backups.

Automatizando com systemd

Depois de validar o comando manualmente, podemos automatizá-lo.

Crie:

bash

sudo nano /etc/systemd/system/rclone-backup.service

Conteúdo:

ini

[Unit]
Description=Backup da VPS via rclone
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=rclone
Group=rclone
UMask=0077

ExecStart=/usr/bin/rclone copy \
    /var/backups/myapp \
    remote:myapp \
    --log-level INFO \
    --stats 1m

StandardOutput=journal
StandardError=journal

Aqui existem alguns detalhes importantes.

Type=oneshot significa que o serviço executa uma tarefa e termina.

Não precisamos manter um processo rodando continuamente.

Também estamos enviando a saída para o journal do systemd, o que elimina a necessidade de criar imediatamente um arquivo de log separado.

Criando o timer

Agora criamos o agendamento:

bash

sudo nano /etc/systemd/system/rclone-backup.timer

Conteúdo:

ini

[Unit]
Description=Agendamento do backup via rclone

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=5m

[Install]
WantedBy=timers.target

Nesse exemplo, o backup será executado diariamente aproximadamente às:

text

02:30

OnCalendar permite definir o horário usando uma expressão de calendário do systemd.

Já:

ini

Persistent=true

faz com que o systemd registre quando o timer deveria ter disparado e execute o serviço após a inicialização caso o servidor tenha ficado desligado durante o período.

ini

RandomizedDelaySec=5m

adiciona uma pequena variação no horário real de execução, útil quando vários servidores possuem tarefas semelhantes.

Habilitando o timer

Depois de criar os dois arquivos:

bash

sudo systemctl daemon-reload

Habilite o timer:

bash

sudo systemctl enable --now rclone-backup.timer

Verifique:

bash

systemctl status rclone-backup.timer

E liste os timers:

bash

systemctl list-timers

Devemos encontrar algo semelhante a:

text

rclone-backup.timer

com a próxima execução programada.

Testando o serviço imediatamente

Não precisamos esperar até 02:30 para descobrir se funciona.

Podemos executar diretamente:

bash

sudo systemctl start rclone-backup.service

Depois:

bash

systemctl status rclone-backup.service

Como é um serviço oneshot, é normal que ele apareça como:

text

inactive (dead)

depois de uma execução bem-sucedida.

O que importa é o resultado da execução.

Consultando os logs

Essa é uma das melhores partes de usar systemd.

Para visualizar os logs:

bash

journalctl -u rclone-backup.service

Para mostrar somente a execução mais recente:

bash

journalctl -u rclone-backup.service -n 100

Para acompanhar em tempo real:

bash

journalctl -u rclone-backup.service -f

Para ver as mensagens da execução de hoje:

bash

journalctl -u rclone-backup.service --since today

O journalctl permite filtrar o journal por unidade systemd e por vários outros critérios.

Logs mais detalhados

Durante um diagnóstico, podemos aumentar o nível de log.

Por exemplo:

bash

rclone copy \
    /var/backups/myapp \
    remote:myapp \
    --log-level DEBUG

Os níveis de log disponíveis incluem ERROR, NOTICE, INFO e DEBUG.

Para uma rotina normal de produção, INFO costuma ser suficiente. DEBUG é mais indicado para investigação de problemas.

Também podemos gravar diretamente em um arquivo usando:

bash

--log-file=/var/log/rclone-backup.log

A documentação do rclone disponibiliza --log-file e --log-level como opções globais.

Mesmo assim, quando já usamos systemd, prefiro começar pelo journal:

bash

journalctl -u rclone-backup.service

porque o próprio sistema operacional já centraliza os logs.

Verificando se o backup realmente aconteceu

Um job terminar sem erro não significa que devemos deixar de verificar o resultado.

Podemos listar o destino:

bash

rclone ls remote:myapp

ou:

bash

rclone lsf remote:myapp

Também podemos consultar o tamanho:

bash

rclone size remote:myapp

Validando origem e destino

O rclone possui um comando específico para comparar os arquivos:

bash

rclone check \
    /var/backups/myapp \
    remote:myapp

Esse comando compara os arquivos da origem e do destino usando tamanho e hashes quando disponíveis e não modifica os dados.

Em uma rotina de manutenção podemos executar, por exemplo:

bash

rclone check \
    /var/backups/myapp \
    remote:myapp \
    --one-way

O --one-way verifica que os arquivos da origem existem corretamente no destino sem considerar arquivos extras no destino como erro.

Para backups importantes, essa validação periódica pode ser tão importante quanto a própria cópia.

Protegendo as credenciais

O arquivo de configuração do rclone contém informações sensíveis relacionadas aos remotes.

Por isso, não devemos deixá-lo disponível para qualquer usuário.

Um exemplo:

bash

chmod 700 /home/rclone/.config/rclone
chmod 600 /home/rclone/.config/rclone/rclone.conf

bash

chown -R rclone:rclone /home/rclone/.config/rclone

O rclone também oferece proteção adicional para o arquivo de configuração por meio de senha.

Existe, porém, uma diferença importante entre obfuscar e proteger criptograficamente uma informação.

O comando:

bash

rclone obscure

não deve ser interpretado como um mecanismo de segurança forte. A própria documentação descreve obscure como uma forma de evitar que uma senha fique imediatamente legível no arquivo de configuração, enquanto a proteção do arquivo de configuração deve ser tratada separadamente.

Criptografando os arquivos antes de enviá-los

Outro recurso interessante do rclone é o backend crypt.

Ele permite criar um remote criptografado sobre outro remote. Assim:

text

VPS
 |
 v
rclone crypt
 |
 v
Google Drive / S3 / B2 / etc.

O conteúdo armazenado no destino fica criptografado e o rclone realiza a criptografia e descriptografia de forma transparente durante o acesso.

Por exemplo:

text

backup:
    ↓
crypt:
    ↓
remote:

Dessa forma, mesmo que o storage remoto não ofereça criptografia do conteúdo da maneira desejada, podemos adicioná-la na camada do rclone.

Cuidados importantes em uma VPS

Uma rotina de backup automatizada parece simples, mas existem alguns erros comuns.

Não testar somente o upload

Não basta verificar:

text

"o comando terminou"

É importante confirmar:

text

arquivo existe no destino
arquivo pode ser lido
arquivo corresponde à origem
restauração é possível

Não usar `sync` sem entender as exclusões

Um comando como:

bash

rclone sync /var/backups remote:backups

pode ser correto em determinado cenário.

Mas também pode transformar uma exclusão local em uma exclusão remota.

Antes de usar:

bash

sync

eu sempre testaria com:

bash

--dry-run

e avaliaria cuidadosamente a saída.

Não executar tudo como root

Quando a aplicação não precisa de privilégios administrativos para realizar o backup, vale utilizar um usuário dedicado.

Isso reduz a superfície de impacto de uma falha na rotina de automação.

Não esquecer o restore

O maior erro em qualquer estratégia de backup é descobrir no dia do desastre que o restore não funciona.

Devemos testar periodicamente:

bash

rclone copy remote:myapp/test-backup /tmp/restore-test

e validar os arquivos restaurados.

Uma estrutura que gosto de usar

Para uma VPS simples, uma arquitetura prática pode ser:

text

/var/backups/
└── myapp/
    ├── database/
    │   ├── backup-2026-09-25.sql.gz
    │   └── backup-2026-09-26.sql.gz
    └── application/
        ├── backup-2026-09-25.tar.gz
        └── backup-2026-09-26.tar.gz

Depois:

text

                +-------------------+
                |       VPS         |
                |                   |
                | /var/backups      |
                +---------+---------+
                          |
                          | rclone
                          v
                +-------------------+
                | Cloud Storage     |
                |                   |
                | myapp/             |
                +-------------------+

E o systemd fica responsável pelo agendamento:

text

rclone-backup.timer
        |
        v
rclone-backup.service
        |
        v
      rclone
        |
        v
   Cloud Storage

Os logs:

text

rclone
   |
   v
systemd-journald
   |
   v
journalctl

Checklist rápido

Antes de considerar a automação pronta, eu verificaria:

text

[ ] rclone instalado
[ ] remote configurado
[ ] acesso ao remote testado
[ ] usuário dedicado criado
[ ] permissões da configuração revisadas
[ ] comando manual testado
[ ] --dry-run testado quando aplicável
[ ] copy/sync escolhido conscientemente
[ ] service criado
[ ] timer criado
[ ] timer habilitado
[ ] primeira execução validada
[ ] logs revisados
[ ] arquivos no destino conferidos
[ ] rclone check executado
[ ] restore testado

Conclusão

O rclone é uma ferramenta extremamente útil para quem administra VPS porque transforma diferentes serviços de armazenamento em uma interface de linha de comando consistente.

Seu principal diferencial não é apenas “copiar arquivos para a nuvem”. É poder trabalhar com diversos backends, automatizar transferências, verificar integridade, realizar migrações e integrar armazenamento remoto a scripts e serviços Linux.

Para uma rotina simples, uma combinação como:

text

VPS
+
/var/backups
+
rclone
+
systemd timer
+
journalctl

já pode criar uma solução bastante eficiente.

Mas é importante separar os conceitos: rclone é excelente como ferramenta de transferência e gerenciamento de storage; uma estratégia completa de backup também precisa pensar em retenção, histórico, isolamento, criptografia, monitoramento e restauração.

Em outras palavras:

Fazer backup é copiar os dados. Ter uma estratégia de backup é saber que eles poderão ser recuperados quando você realmente precisar deles.

Referências

Rclone documentation: https://rclone.org/docs/

Rclone installation: https://rclone.org/install/

Rclone sync: https://rclone.org/commands/rclone_sync/

Rclone check: https://rclone.org/commands/rclone_check/

Rclone crypt: https://rclone.org/crypt/

systemd timers: https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

journalctl: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html

O que é o rclone?

Rclone é uma ferramenta de backup?

Principais vantagens do rclone

1. Uma interface para vários provedores

2. Excelente para automação

3. Transferências entre armazenamentos

4. Verificação e retomada

5. Recursos além de cópia

Rclone x rsync x restic

Instalando o rclone em uma VPS

Configurando um remote

Configuração em uma VPS sem interface gráfica

Criando um usuário específico para o backup

Primeiro teste manual

copy ou sync?

copy

sync

Usando --backup-dir

Automatizando com systemd

Criando o timer

Habilitando o timer

Testando o serviço imediatamente

Consultando os logs

Logs mais detalhados

Verificando se o backup realmente aconteceu

Validando origem e destino

Protegendo as credenciais

Criptografando os arquivos antes de enviá-los

Cuidados importantes em uma VPS

Não testar somente o upload

Não usar sync sem entender as exclusões

Não executar tudo como root

Não esquecer o restore

Uma estrutura que gosto de usar

Checklist rápido

Conclusão

Referências

`copy` ou `sync`?

`copy`

`sync`

Usando `--backup-dir`

Não usar `sync` sem entender as exclusões