Backup na nuvem com rclone e S3: configure em 6 passos

Um servidor Linux sem cópia fora do datacenter local está a um incêndio, um ransomware ou uma falha de disco de perder tudo. O rclone resolve isso sem custo de licença: é um binário único, open source, que sincroniza pastas para qualquer armazenamento compatível com a API S3 — AWS S3, Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO on-premise ou o Object Storage da própria hospedagem — e roda via cron sem intervenção manual depois de configurado.

Por que rclone e não um script de rsync manual

Dá para escrever um script com curl e a API do provedor, mas o rclone já resolve os três pontos que mais dão problema em backup caseiro:

• Sincronização incremental real — o rclone compara tamanho e hash antes de transferir, então o segundo backup só envia o que mudou, não o volume inteiro de novo.
• Criptografia do lado do cliente — o remote crypt cifra nome de arquivo e conteúdo antes de sair do servidor. Mesmo que o bucket seja invadido ou o provedor tenha acesso à conta, os dados continuam ilegíveis sem a senha.
• Portabilidade entre provedores — a configuração usa endpoint genérico S3, então trocar de AWS para Backblaze ou para o Object Storage da hospedagem é editar duas linhas do arquivo de config, não reescrever o script.

Pré-requisitos

• Acesso root (ou sudo) ao servidor Linux que será copiado.
• Um bucket já criado em qualquer provedor compatível com S3, com access key e secret key gerados.
• O endpoint da API do provedor (ex.: s3.sa-east-1.amazonaws.com para AWS, ou o endpoint informado pelo painel do provedor escolhido).

Passo a passo

1. Instalar o rclone

O script oficial detecta a arquitetura e instala a versão mais recente:

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

2. Criar o remote S3

Editar o arquivo de configuração direto é mais rápido que o assistente interativo e fica documentado — importante se outra pessoa precisar reproduzir o setup depois:

mkdir -p ~/.config/rclone
cat >> ~/.config/rclone/rclone.conf << 'EOF'
[s3backup]
type = s3
provider = Other
env_auth = false
access_key_id = SUA_ACCESS_KEY
secret_access_key = SUA_SECRET_KEY
endpoint = https://s3.sa-east-1.amazonaws.com
region = sa-east-1
acl = private
EOF

provider = Other é o que permite apontar para qualquer serviço S3-compatível através do endpoint, em vez de travar no formato específico da AWS.

3. Testar a conexão antes de confiar nela

rclone lsd s3backup:
rclone mkdir s3backup:meu-bucket-backup
rclone ls s3backup:meu-bucket-backup

Se lsd listar os buckets existentes, a credencial e o endpoint estão corretos. Resolver erro de autenticação agora custa dois minutos — descobrir só na hora de restaurar custa o backup inteiro.

4. Criar o remote criptografado

Recomendado sempre que o bucket está sob controle de terceiro. O crypt se encaixa por cima do remote S3 e cifra tudo antes de enviar:

rclone config create s3backup-crypt crypt remote s3backup:meu-bucket-backup password $(rclone obscure 'SuaSenhaForteAqui123!') filename_encryption standard directory_name_encryption true

Guarde a senha em um cofre de credenciais separado do servidor. Sem ela, os arquivos no bucket não têm como ser recuperados — nem pelo próprio rclone.

5. Rodar o primeiro sync em modo simulação

rclone sync /var/www s3backup-crypt:www --dry-run -v

O --dry-run mostra exatamente o que seria enviado ou apagado, sem tocar em nada. É o passo que evita descobrir, na primeira execução real, que o caminho de origem estava errado e o rclone ia apagar tudo do destino.

6. Configurar retenção antes do sync real

rclone sync espelha a origem: arquivo removido localmente some do destino na próxima execução. O --backup-dir evita perda por engano — em vez de apagar, o rclone move a versão antiga para uma pasta datada:

rclone sync /var/www s3backup-crypt:www \
  --backup-dir=s3backup-crypt:www-versoes/$(date +%Y-%m-%d) \
  --log-file=/var/log/rclone-backup.log --log-level INFO

7. Agendar via cron

sudo crontab -e

Adicione a linha abaixo para rodar todo dia às 3h, fora do horário de pico:

0 3 * * * /usr/bin/rclone sync /var/www s3backup-crypt:www --backup-dir=s3backup-crypt:www-versoes/$(date +\%Y-\%m-\%d) --min-age 1m --log-file=/var/log/rclone-backup.log --log-level INFO >> /var/log/rclone-cron.log 2>&1

O --min-age 1m ignora arquivos modificados no último minuto — evita capturar um arquivo no meio de uma escrita e subir uma cópia corrompida.

Como restaurar um backup

rclone copy s3backup-crypt:www /var/www-restaurado -v

Use copy, não sync, na restauração: sync apagaria do bucket qualquer arquivo que já exista localmente e não esteja no backup, o que é o oposto do que se quer ao restaurar.

Boas práticas de retenção e monitoramento

1. Rotacione as pastas de versão antigas — sem isso, o --backup-dir acumula indefinidamente e a conta de armazenamento cresce sem controle. Um segundo job semanal com rclone delete --min-age 90d na pasta de versões resolve.
2. Monitore o exit code, não só o log — o rclone retorna código diferente de zero em falha. Um script simples após o comando de sync que dispara webhook para Slack ou Telegram quando o código não é 0 pega falha silenciosa que ninguém vai notar lendo log manualmente.
3. Teste a restauração de tempos em tempos — backup que nunca foi restaurado em teste é uma hipótese, não uma garantia.

Perguntas frequentes

O rclone sync apaga arquivos que não existem mais localmente?
Sim — sync espelha a origem. Por isso o --backup-dir do passo 6 é essencial: em vez de apagar de vez no bucket, o rclone move a versão antiga para uma pasta de histórico antes de sincronizar.

Preciso criptografar antes de mandar para o S3?
Não é obrigatório, mas é recomendado sempre que o bucket está fora do seu controle direto. O remote crypt cifra nome e conteúdo do lado do cliente — nem o provedor de nuvem consegue ler os dados.

O rclone funciona com qualquer provedor de object storage?
Funciona com qualquer serviço que ofereça API compatível com S3: AWS S3, Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO on-premise e a maioria dos provedores de hospedagem com Object Storage.

Como saber se o backup rodou certo sem entrar no servidor todo dia?
Redirecione a saída do cron para um log (como no passo 7) e adicione uma checagem de exit code que dispara alerta quando o comando retorna erro — não confie em “achar que rodou”.

rsync não resolveria o mesmo problema?
Rsync fala o protocolo dele mesmo ou SSH, não a API S3. Para mandar dados a um bucket de object storage, o rclone (ou uma ferramenta equivalente que fale S3) é necessário — rsync não conversa nativamente com esse tipo de armazenamento.

Conclusão

Com o remote configurado, a criptografia ativa e o cron rodando, o backup deixa de depender de alguém lembrar de rodar um script manualmente. O próximo passo é documentar esse setup — endpoint, nome dos remotes, horário do cron — em algum lugar que sobreviva à saída da pessoa que configurou, e testar a restauração pelo menos uma vez antes de precisar dela de verdade.