Syncthing vs rsync vs Unison: comparativo para sincronização bidirecional entre servidores VPS
Por Kevin Marcondes · Publicado em · 9 min de leitura
Comparativo: Syncthing vs rsync vs Unison para sincronização bidirecional entre servidores VPS. Aqui você vê quando cada ferramenta é melhor, como lidam com conflitos, desempenho, segurança e automação. Trazemos critérios objetivos por cenário e um roteiro simples para validar no seu ambiente antes de padronizar a solução.
Quando sincronização bidirecional entre VPS é necessária
Sincronização bidirecional é útil quando dois servidores podem receber alterações e você quer convergência automática sem sobrescrever dados. Exemplos típicos: edição colaborativa de arquivos, nós ativos com conteúdo compartilhado ou ambientes de staging e produção que trocam dados controlados.
Se você só precisa de cópia de um lado para outro (backup, mirror), sincronização unidirecional costuma ser mais simples e segura. Para bidirecional, conflitos e exclusões exigem regras claras e ferramentas que detectem mudanças corretamente.
Uma política de exclusão e retenção bem definida diminui o risco. Combine com verificações periódicas por amostragem para detectar divergências cedo.
- Ambiente ativo-ativo com conteúdo mutável em ambos os lados
- Sincronização contínua de diretórios de trabalho entre VPS
- Migração gradual entre servidores com ida e volta temporária
- Clusters sem storage compartilhado, com dados eventualmente consistentes
Visão geral: Syncthing, rsync e Unison em 1 minuto
Syncthing é P2P, bidirecional por padrão, com descoberta, criptografia de ponta a ponta e detecção de renomeações e blocos alterados. Trabalha continuamente e lida bem com NAT usando relays e introducers.
rsync é unidirecional. Para bidirecional, exige orquestração em dois sentidos e lógica extra para conflitos. Brilha em mirrors e jobs agendados, com filtros potentes e transferência delta.
Unison oferece sincronização verdadeira de dois caminhos sobre SSH, com perfis declarativos, detecção de conflitos e renomeações. Opera em lotes ou interativo, útil quando você quer controle explícito do que converge.
Tabela comparativa de recursos e limitações
Compare rapidamente critérios que costumam pesar na escolha. Use como checklist para o seu caso. Ajuste filtros/ignores e topologia antes de medir desempenho.
| Critério | Syncthing | rsync | Unison |
|---|---|---|---|
| Modelo de sincronização | Bidirecional contínuo (near real-time) | Unidirecional por execução; bidirecional só com orquestração | Bidirecional por design (lotes) |
| Transporte | Conexão direta, relays; TLS E2E | Geralmente sobre SSH (ou daemon rsyncd) | SSH nativo (ou socket local) |
| Detecção de mudanças | Inotify + varredura periódica | Stat/mtime + checksums sob demanda | Registro de estado + varredura eficiente |
| Renomeações/moves | Detecta e reaproveita blocos | Trata como delete+add na maioria dos casos | Detecta moves/renames |
| Conflitos | Versões/arquivos conflitantes opcionais | Sem resolução nativa (última gravação pode vencer) | Marca conflitos e pede/ou aplica regras |
| Criptografia em trânsito | TLS com device IDs | Via SSH (quando usado) | Via SSH |
| Trabalho atrás de NAT | Funciona com relays/UPnP | Depende de acesso SSH/porta exposta | Depende de acesso SSH/porta exposta |
| Agendamento | Contínuo por padrão | Agendado via cron/systemd timers | Execução sob demanda ou agendada |
| Granularidade delta | Blocos (streaming) | Blocos delta eficientes | Blocos delta entre réplicas |
| Escalabilidade (n nós) | Vários pares; topologia P2P | Um-para-muitos com scripts | Pares definidos; pode escalar com perfis |
| Visibilidade/GUI | GUI e API nativas | Linha de comando; wrappers existem | Linha de comando; interfaces de terceiros |
| Filtro/ignore | Padrões .stignore por pasta | Include/exclude poderosos | Patterns em perfis |
| Uso típico | Sync contínuo com mudanças em ambos os lados | Deploys, mirrors, backups incrementais | Bidirecional controlado e declarativo |
Desempenho e consumo: o que realmente pesa
O desempenho depende mais do padrão de mudanças e da rede do que da ferramenta. Muitos arquivos pequenos penalizam varredura e latência. Arquivos grandes favorecem protocolos com delta por bloco.
CPU e disco entram no jogo ao calcular checksums e ler blocos. Em redes com alta latência, compressão e pipeline de blocos ajudam. Em links limitados, limitar banda evita disputar com tráfego de produção.
rsync permite ajustes finos (compressão, delta, inplace, partial). Syncthing equilibra varredura contínua e hashing para minimizar reenvio de blocos. Unison trabalha por perfis, útil para isolar subárvores ruidosas.
Para cargas pesadas, considere também o agendamento em janelas fora do horário crítico e monitore I/O de disco para não interferir com bancos e filas.
- Otimize diretórios ruidosos com ignores para reduzir varredura
- Agrupe pequenas alterações em janelas curtas quando possível
- Evite sync de arquivos temporários e caches (node_modules, .cache, tmp)
- Acompanhe CPU/IO para não competir com workloads críticos
Segurança e conectividade entre servidores
Para tráfego seguro, rsync e Unison costumam usar SSH, herdando chaves, políticas e logs. Syncthing cifra ponta a ponta e autentica por IDs de dispositivo, sem exigir SSH.
Atrás de firewalls, acesso SSH simplifica rsync/Unison. Syncthing conecta via relays quando não há rota direta. Controle portas e políticas com firewall e registro de acessos. Veja um guia prático de firewall em como configurar firewall no Ubuntu com UFW.
Se você precisa acesso seguro entre redes, uma VPN site‑to‑site evita expor portas publicamente e estabiliza latência. Há um passo a passo em Como configurar WireGuard site-to-site entre duas VPS Debian.
Para administração centralizada de conexões SSH, um jump host ajuda a padronizar políticas e auditoria. Veja Como configurar bastion SSH no Ubuntu 22.04.
- Restrinja portas com regras claras de entrada e saída
- Exija chaves SSH e rotação periódica quando aplicável
- Avalie VPN site‑to‑site para tráfego interno de sincronização
Automação, observabilidade e operações
Em operações, previsibilidade importa. rsync brilha com agendamento via timers, logs e códigos de saída simples de integrar. Unison também pode rodar em jobs e registrar conflitos para revisão.
Syncthing expõe GUI e API para observar pares, filas e eventos. Monitore consumo e falhas, e trate conflitos com versionamento quando há edições simultâneas.
Centralize logs e métricas para detectar quedas de conexão, diretórios fora do padrão e crescimento anômalo de filas. Uma stack de logs ajuda, como em Fluentd + Elasticsearch: logs PHP em VPS (guia), e métricas/alertas com Guia prático: configurar Prometheus e Grafana com Docker Compose em VPS.
- Use systemd timers para janelas de sincronização controladas
- Monitore latência, throughput e backlog de arquivos
- Versione conflitos em diretórios separados para auditoria
Escolha por cenário: recomendações práticas
Escolhas dependem de quem altera, quando altera e dos requisitos de operação. Use estes critérios para reduzir risco e esforço. Se houver forte exigência de auditoria e janelas definidas, prefira modos em lote; para colaboração contínua, favoreça P2P.
- Near real-time, dois lados editando e NAT no caminho: Syncthing
- Mirror controlado com filtros fortes e auditoria por job: rsync (unidirecional)
- Bidirecional sob controle, com revisão de conflitos: Unison
- Deploys e distribuição de artefatos: rsync
- Ambientes com muitos renames/moves: Syncthing ou Unison (detecção nativa)
- Links instáveis com retomada e delta: qualquer um com delta por bloco; valide no seu tráfego
Como testar no seu ambiente (sem suposições)
Antes de padronizar, faça um teste curto e representativo. Monte um dataset realista, execute uma primeira sincronização, depois aplique: poucos renomes, edições pequenas em arquivos grandes e criação/remoção de muitos arquivos pequenos. Meça tempo total, uso de CPU/IO e trate um conflito proposital.
Evite números absolutos e foque comparativos no mesmo host/link. Documente flags, filtros e janelas usadas para repetir o teste depois de alterações de infraestrutura. Se possível, rode sob limitação de banda para observar retentativas e comportamento de delta.
Este roteiro confirma, de forma objetiva, o que este comparativo: Syncthing vs rsync vs Unison para sincronização bidirecional entre servidores VPS antecipa — mas sempre valide com seus dados e padrões de mudança.
- Crie perfis/filtros para excluir temporários e caches
- Mensure três rodadas: inicial, incremental leve e incremental pesada
- Simule conflito com edição simultânea do mesmo arquivo
- Teste sob limitação de banda para observar comportamento
Perguntas frequentes
Dá para fazer sincronização bidirecional só com rsync?
Tecnicamente é possível orquestrar dois fluxos rsync e lógica extra para resolver conflitos, mas é arriscado. rsync não detecta renomeações nativamente e a “última gravação vence” pode causar perda de dados. Para bidirecional real, avalie Syncthing ou Unison.
Syncthing é adequado para servidores críticos em produção?
Pode ser, desde que você trate governança: versionamento de conflitos, diretórios bem filtrados e observabilidade. Rode como serviço, limite recursos e valide impacto de varredura em horários de pico. Em ambientes regulados, documente políticas de exclusão e retenção.
Unison ainda é uma opção viável hoje?
Sim, para sincronização bidirecional declarativa e controlada. Ele detecta conflitos e renomeações, funciona bem sobre SSH e permite perfis reprodutíveis. É prático quando você prefere rodadas de sincronização com revisão ao invés de fluxo contínuo.
Como evitar perder dados em conflitos de sincronização?
Defina regras: versionamento de conflitos em diretório separado, janelas de atualização, bloqueio de tipos de arquivo sensíveis e exclusões protegidas. Em bidirecional, teste cenários de edição simultânea e documente o procedimento de resolução antes de ir a produção.
Como monitorar se a sincronização está funcionando?
Colete logs e códigos de saída de jobs (rsync/Unison) e métricas/estado da fila (Syncthing). Centralize em uma stack de observabilidade e configure alertas para falhas repetidas, backlog crescente e quedas de conexão. Auditorias por amostragem ajudam a detectar drift.
Quer decidir com segurança?
Se você precisa desenhar, validar e automatizar sincronização entre VPS com baixo risco de conflitos, podemos conversar sobre cenários e testes práticos.
Falar sobre seu casoVeja também
- Comparativo: ZFS vs LVM+LUKS em VPS com bancos de dados — snapshots, desempenho e recuperação após falha
- Análise prática — comparativo: Nginx Unit vs PHP‑FPM vs RoadRunner para executar monólitos PHP em containers — latência, throughput e consumo de memória
- Comparativo: Flyway vs Liquibase vs Sqitch para versionamento de banco de dados em projetos PHP/Laravel
- nftables vs iptables no Ubuntu 22.04: qual usar e exemplos práticos