Backup na nuvem com rclone: envie vzdump, .bak e dumps de banco para Backblaze B2, Wasabi ou Amazon S3 com criptografia, limite de banda e retenção.

Para que serve

Muitos clientes já geram arquivos de backup no próprio servidor: os .vma.zst do vzdump no Proxmox, os .bak do SQL Server, os dumps do MySQL. O problema é que eles ficam no mesmo hardware que deveriam proteger. O rclone copia esses arquivos para um armazenamento de objetos (Backblaze B2, Wasabi, Amazon S3 e dezenas de outros), opcionalmente criptografando antes de enviar. Diferente do restic, ele não faz deduplicação: copia arquivos como estão. Por isso é ideal para arquivos de backup que já vêm prontos e compactados. Este artigo mostra como montar o backup na nuvem com rclone, do remoto criptografado à retenção.

Pré-requisitos

  • Linux (Debian 12/13, Ubuntu 24.04, Proxmox VE 8/9) ou Windows Server 2022/2025.
  • Bucket privado e chave de acesso restrita a esse bucket no provedor escolhido.
  • Uma pasta local onde os backups já são gerados (ex.: /var/lib/vz/dump ou D:\Backup).

Como configurar o backup na nuvem com rclone

  1. Instale o rclone. O pacote do Debian costuma estar algumas versões atrás; o script oficial instala a versão atual:

    apt install -y curl unzip
curl -fsSL https://rclone.org/install.sh | bash
rclone version

    No Windows, baixe o zip de rclone.org/downloads, extraia em C:\rclone e use o rclone.exe pelo PowerShell.

  2. Crie o remoto do armazenamento. Rode rclone config, escolha n (novo remoto) e responda o assistente. Também dá para criar direto pela linha de comando:

    # Backblaze B2 (backend nativo)
rclone config create b2 b2 account=SEU_KEY_ID key=SUA_APPLICATION_KEY hard_delete=true

# Wasabi
rclone config create wasabi s3 provider=Wasabi \
  access_key_id=SUA_ACCESS_KEY secret_access_key=SUA_SECRET_KEY \
  endpoint=s3.us-east-1.wasabisys.com

# Amazon S3 (região São Paulo)
rclone config create aws s3 provider=AWS env_auth=false \
  access_key_id=SUA_ACCESS_KEY secret_access_key=SUA_SECRET_KEY region=sa-east-1

    No B2, a opção hard_delete=true faz o rclone apagar de verdade em vez de apenas ocultar o arquivo (versões ocultas continuam sendo cobradas). Comandos digitados ficam no histórico do shell: se preferir, use o assistente interativo e depois limpe o histórico com history -c.

  3. (Recomendado) Crie uma camada de criptografia. O remoto crypt envolve outro remoto e cifra conteúdo e nomes de arquivos antes do upload:

    rclone config
# n  → nome: cofre
# Storage: crypt
# remote: b2:meu-bucket/srv01
# filename_encryption: standard
# directory_name_encryption: true
# password: gere uma senha forte (opção g)
# password2 (salt): gere também
    Guarde as duas senhas do crypt fora do servidor. O arquivo ~/.config/rclone/rclone.conf guarda as senhas apenas ofuscadas, não protegidas. Faça uma cópia desse arquivo no cofre de senhas da equipe: sem ele (ou sem as senhas), os arquivos no bucket são ilegíveis.

    Para proteger o próprio rclone.conf, deixe-o com chmod 600, ou use rclone config → s (set configuration password) para criptografá-lo.

  4. Teste com dry-run.

    rclone copy /var/lib/vz/dump cofre:vzdump --dry-run -v

  5. Envie os backups. Para arquivos de backup que são criados e depois apagados pela retenção local, use copy (nunca apaga nada no destino):

    rclone copy /var/lib/vz/dump cofre:vzdump \
  --min-age 30m --transfers 4 --checkers 8 \
  --bwlimit "08:00,30M 20:00,off" \
  --log-file /var/log/rclone-backup.log --log-level INFO
    • --min-age 30m evita enviar um arquivo que o vzdump ainda está escrevendo.
    • --bwlimit limita o upload a 30 MB/s no horário comercial e libera à noite, para não disputar o uplink de 1 Gbps com a produção.

  6. Para pastas de arquivos vivos, use sync com --backup-dir. O sync deixa o destino idêntico à origem e apaga no destino o que sumiu da origem. Com --backup-dir, em vez de apagar, o rclone move o arquivo antigo para uma pasta datada:

    rclone sync /srv/arquivos cofre:arquivos/atual \
  --backup-dir cofre:arquivos/historico/$(date +%F) \
  --log-file /var/log/rclone-arquivos.log --log-level INFO

  7. Aplique retenção no destino. Como o copy não apaga nada, limpe os arquivos antigos de tempos em tempos:

    rclone delete cofre:vzdump --min-age 35d
rclone delete cofre:arquivos/historico --min-age 90d --rmdirs

    Para uma retenção GFS (manter também mensais), prefira as regras de ciclo de vida do bucket ou passe a usar restic. Na Wasabi, lembre-se de que objetos apagados antes de 90 dias são cobrados até completar o período.

  8. Agende. No Linux, coloque os comandos em /usr/local/sbin/rclone-backup.sh e agende com cron ou systemd timer, depois do horário do vzdump (veja também o artigo «Como fazer backup no Proxmox: VMs com vzdump e Proxmox Backup Server»):

    # /etc/cron.d/rclone-backup
30 4 * * * root /usr/local/sbin/rclone-backup.sh

    No Windows, crie uma tarefa no Agendador de Tarefas que rode C:\rclone\rclone.exe copy D:\Backup cofre:sql --min-age 30m --log-file C:\rclone\backup.log com uma conta que tenha leitura na pasta. O rclone.conf fica em %APPDATA%\rclone\ do usuário que executou o rclone config; se a tarefa roda com outra conta, passe --config C:\rclone\rclone.conf.

Como saber se funcionou

  • rclone ls cofre:vzdump lista os arquivos com nomes legíveis (pelo remoto crypt); no painel do provedor você verá nomes embaralhados, o que é esperado.
  • rclone cryptcheck /var/lib/vz/dump cofre:vzdump confere se o conteúdo enviado bate com o local (para remotos sem crypt, use rclone check).
  • Uma vez por mês, baixe um arquivo de volta (rclone copy cofre:vzdump/ARQUIVO /tmp/teste/) e restaure-o de verdade em uma VM de teste.

Problemas comuns

Erro de permissão ao criar o bucket

Chaves restritas a um bucket não podem listar ou criar buckets. Crie o bucket pelo painel e, em remotos S3, acrescente --s3-no-check-bucket.

O sync apagou arquivos no destino

É o comportamento esperado do sync. Sempre rode com --dry-run antes e use --backup-dir. Se a origem ficar vazia por erro (disco não montado), o sync esvazia o destino: em scripts, verifique antes se a pasta de origem tem arquivos, ou use --max-delete 50 como trava.

Upload lento de arquivos grandes

Aumente o tamanho das partes do upload em paralelo (--b2-chunk-size 96M no B2, --s3-chunk-size 64M --s3-upload-concurrency 8 no S3), observando o uso de memória.

Perguntas frequentes

Qual a diferença entre rclone copy e rclone sync?

O copy só envia arquivos e nunca apaga nada no destino. O sync deixa o destino idêntico à origem e apaga o que sumiu dela; use-o com --dry-run e --backup-dir.

O rclone criptografa os arquivos?

Sim, com um remoto do tipo crypt por cima do remoto do bucket. Conteúdo e nomes são cifrados antes do upload; guarde as duas senhas fora do servidor.

Rclone ou restic: qual usar?

O rclone copia arquivos como estão e é ideal para backups que já vêm prontos, como os do vzdump ou os .bak do SQL Server. O restic faz deduplicação e retenção GFS nativa, melhor para pastas de arquivos.

O rclone funciona no Windows Server?

Sim. Baixe o rclone.exe, configure o remoto pelo PowerShell e agende o envio no Agendador de Tarefas, apontando --config se a tarefa rodar com outra conta.

Como evitar que o backup ocupe todo o link?

Use --bwlimit com horários, por exemplo "08:00,30M 20:00,off", para limitar o upload no horário comercial e liberar à noite.

Leitura complementar

Precisa de ajuda?

Se o envio estiver falhando ou ocupando banda demais, abra um ticket na área do cliente com as últimas linhas do log do rclone.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também