Rsync é uma daquelas ferramentas que todo técnico de Linux usa há anos, mas raramente configura de um jeito que realmente protege em caso de desastre. Já vi gente rodando rsync manualmente “quando lembra” e descobrir, na hora que o servidor caiu de vez, que o último backup válido tinha três semanas. Vou mostrar aqui a configuração que uso em produção, incluindo os detalhes que só aparecem depois que alguma coisa dá errado uma vez.
Por que rsync e não só cp ou tar
A diferença que importa na prática é a transferência incremental: rsync compara os arquivos de origem e destino e só transfere o que mudou, usando um algoritmo de delta que reduz muito o tráfego de rede e o tempo de execução. Num servidor com centenas de gigabytes, isso é a diferença entre um backup que roda em minutos e um que trava a madrugada inteira.
Comando básico que funciona bem
O ponto de partida costuma ser algo assim:
rsync -avz --delete /caminho/origem/ usuario@servidor-backup:/caminho/destino/
Cada flag importa: -a preserva permissões, dono e timestamps (arquivístico); -v mostra o que está sendo transferido, útil pra debug; -z comprime dados durante a transferência, o que ajuda bastante em link mais lento. O –delete é o mais perigoso e o mais esquecido: ele remove no destino os arquivos que não existem mais na origem, mantendo o backup espelhado. Sem essa flag, seu backup só cresce e nunca reflete exclusões — o que parece seguro, mas enche o disco de destino com lixo com o tempo.
O detalhe que quase ninguém configura: SSH sem senha
Pra automatizar de verdade (via cron), você precisa de autenticação SSH por chave, sem senha digitada manualmente. Gere o par de chaves no servidor de origem com ssh-keygen -t ed25519 e copie a chave pública pro servidor de destino com ssh-copy-id usuario@servidor-backup. Um erro comum aqui: gente que gera a chave como root, mas o cron roda com outro usuário — e o backup falha silenciosamente porque a permissão da chave não bate com o processo que está tentando usá-la.
Agendando com cron sem dor de cabeça depois
Um cron básico ficaria assim, rodando todo dia às 2h da manhã:
0 2 * * * rsync -avz --delete /var/www/ usuario@servidor-backup:/backups/site/ >> /var/log/rsync-backup.log 2>&1
Repare no redirecionamento pro arquivo de log no final. Sem isso, se o rsync falhar por qualquer motivo — servidor de destino fora do ar, disco cheio, chave SSH expirada — você só vai descobrir quando precisar do backup e ele não existir. Eu recomendo configurar também um alerta simples (um script que checa se o log do dia teve erro e manda e-mail) porque cron falho e silencioso é a causa mais comum de “backup fantasma” que gente relata depois de perder dado de verdade.
Backup incremental com –link-dest
Pra quem quer manter histórico de várias versões sem gastar espaço em disco duplicando tudo, a flag --link-dest permite criar backups incrementais que usam hard links pros arquivos que não mudaram entre execuções. Isso significa ter backup de “ontem”, “anteontem” e “semana passada” ocupando bem menos espaço do que pareceria à primeira vista, porque só o que realmente mudou consome espaço novo.
Testando a restauração — a parte que todo mundo pula
Configurar backup é metade do trabalho. A outra metade, que 90% das empresas pequenas ignoram, é testar a restauração antes de precisar dela de verdade. Pelo menos uma vez por trimestre, restaure o backup num ambiente separado e confirme que os arquivos abrem, que o banco de dados (se for o caso) sobe sem erro, e que as permissões vieram corretas. Backup que nunca foi restaurado é uma aposta, não uma garantia.
Erros comuns que eu já vi (e cometi)
Esquecer o --delete e o disco de destino encher em poucos meses é o mais frequente. Depois vem confundir barra final no caminho de origem — com barra no final, o rsync copia o conteúdo da pasta; sem barra, copia a pasta inteira dentro do destino, criando uma estrutura de diretório diferente da esperada. Parece bobagem, mas já vi restauração falhar por causa dessa única barra faltando ou sobrando.
Perguntas frequentes
Rsync sozinho é backup suficiente ou preciso de outra ferramenta junto?
Pra servidor pequeno ou médio, rsync bem configurado com –link-dest e testes de restauração periódicos já cobre bem. Pra ambiente corporativo maior, geralmente combina-se com ferramentas de snapshot do storage ou soluções como Bacula e Borg pra criptografia e deduplicação mais avançada.
Rsync funciona para backup de banco de dados?
Funciona pros arquivos físicos, mas banco de dados em uso (MySQL, PostgreSQL) precisa de dump consistente antes — copiar arquivo de banco aberto com rsync pode gerar backup corrompido. Rode mysqldump ou pg_dump antes e sincronize o arquivo de dump gerado.
Como sei se meu backup via rsync está realmente funcionando?
Verifique o log de cada execução, confira o tamanho do backup ao longo do tempo (queda brusca de tamanho é sinal de problema) e, o mais importante, restaure de verdade periodicamente pra confirmar integridade.
Rsync via SSH é seguro pela internet pública?
Sim, o tráfego vai criptografado pelo túnel SSH. O cuidado real está em restringir a chave SSH usada só pro comando de rsync (usando command= no authorized_keys) pra limitar o que aquela chave pode fazer caso vaze.
Se você administra servidor Linux no dia a dia, também vale conferir nosso guia sobre backup de WordPress e o texto sobre o que é Kubernetes e quando você realmente precisa dele pra continuar organizando sua infraestrutura.
