Sincronização de Arquivos · 10 min read · Feb 09, 2026
Configurando a Sincronização de Arquivos Unison entre dois Servidores no Debian 8 (Jessie)
Este tutorial mostra como configurar a sincronização de arquivos entre dois servidores Debian 8 com Unison. Unison é uma ferramenta de sincronização de arquivos semelhante ao rsync, a grande diferença é que ele rastreia/sincroniza alterações em ambas as direções, ou seja, arquivos alterados no server1 serão replicados para o server2 e vice-versa.
1 Nota Preliminar
Neste tutorial, usarei os seguintes dois servidores Debian:
- server1.example.com com o endereço IP 192.168.1.101
- server2.example.com com o endereço IP 192.168.1.102
Quero sincronizar o diretório /var/www entre os dois servidores. Executarei o Unison como usuário root neste tutorial para que o Unison tenha permissões suficientes para sincronizar permissões de usuário e grupo.
Todos os comandos neste tutorial são executados como usuário root. Faça login em ambos os servidores no shell como root e comece com o passo 2 “ Instalando o Unison “.
2 Instalando o Unison
server1/server2:
O Unison deve ser instalado no server1 e no server2; como nos conectamos do server1 ao server2 usando SSH, também precisamos dos pacotes SSH e vou instalar o editor nano para edição de arquivos no shell. Isso pode ser feito da seguinte forma:
apt-get -y install unison openssh-server ssh nano3 Criando um Par de Chaves Privada/Pública no server1
server1:
Agora criamos um par de chaves privada/pública no server1.example.com:
ssh-keygen -t dsaroot@server1:~# ssh-keygen -t dsa
Gerando par de chaves dsa pública/privada.
Digite o arquivo no qual salvar a chave (/root/.ssh/id_dsa): <– ENTER
Diretório criado ‘/root/.ssh’.
Digite a frase secreta (vazia para nenhuma frase secreta): <– ENTER
Digite a mesma frase secreta novamente: <– ENTER
Sua identificação foi salva em /root/.ssh/id_dsa.
Sua chave pública foi salva em /root/.ssh/id_dsa.pub.
A impressão digital da chave é:
ba:82:e1:a1:42:9b:d4:c8:99:c8:bd:8b:7d:4d:d4:66 root@server1
A imagem randomart da chave é:
+—[DSA 1024]—-+
| |
| |
| . |
| . E |
|+ * . S |
|.Ooo o |
|ooo+. + |
|oo=… o |
|.. oo.. |
+—————–+
root@server1:~#
É importante que você não insira uma frase secreta, caso contrário, a replicação não funcionará sem interação humana, então simplesmente pressione ENTER!
Em seguida, copiamos nossa chave pública para server2.example.com:
ssh-copy-id -i $HOME/.ssh/id_dsa.pub [email protected]# ssh-copy-id -i $HOME/.ssh/id_dsa.pub [email protected]A autenticidade do host '192.168.1.102 (192.168.1.102)' não pode ser estabelecida.
A impressão digital da chave ECDSA é 51:7f:b4:ed:bd:e3:fc:16:2f:55:5c:e1:2c:d7:3d:a9.
Você tem certeza de que deseja continuar conectando (sim/não)? <-- sim (você verá isso apenas se esta for a primeira vez que se conecta ao server2)
/usr/bin/ssh-copy-id: INFO: tentando fazer login com a(s) nova(s) chave(s), para filtrar qualquer uma que já esteja instalada
/usr/bin/ssh-copy-id: INFO: 1 chave(s) permanecem para serem instaladas -- se você for solicitado agora, é para instalar as novas chaves
[email protected]'s password: <-- senha root do server2Número de chave(s) adicionada(s): 1Agora tente fazer login na máquina, com: "ssh '[email protected]'"
e verifique se apenas a(s) chave(s) que você queria foram adicionadas.Agora verifique no server2 se a chave pública do server1 foi transferida corretamente:
server2:
cat $HOME/.ssh/authorized_keysroot@server2:/home/administrator# cat $HOME/.ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBAKHLdAztIr8muZIlQYuE/4f75kmgTwWqJRZJ1dTqHDnHWsy48emDU8v85hxAPg43k9aF7/zAwpA0MNNNk5T9Tx/DyUkK/KcyVP2f4p8tvovrkUvoxsZACkTUmFqKdq2x6/AGfjsCRmkpLhZuad7r5rKEXHRh8KYGHqD1Id8wcpy5AAAAFQCww3OekKcKMshMAwBK3XQmmYEGUwAAAIEAgjztlwh8OFYxwQve/RrhI2sceCXwS/yjQyH7q0zdWB9Fr4s/16T2PLBT+7M3vb+JlPDO3JRqgaYbel1kS2F2iKrY0EX0FI3/9fVDfWoz3mhCscPLriqy5AcsHitxQNfiZgA5wDiSjWpk1v+FbIC+VuqbKdQuE4MBKj19N9YALIUAAACABQ4NDsa2UBc8jsxvghjoLhUWF7HChaCksXQcL6i98VNRcemtPC6wpIri75iR4Uhv1666bDOBAdmIBX9Qf7A/+czPKPaj4CGI1hVy1pgYMa3btnEvoSnH/ONtjpOz9q+3up1OOOn+5fud7xjJn+Fq8WoGROgarBpCbQU3w2GUUnM= root@server14 Executando o Unison
server1:
Agora podemos executar o Unison pela primeira vez para sincronizar o diretório /var/www em ambos os servidores. No server1, execute:
unison /var/www ssh://192.168.1.102//var/wwwA saída será semelhante a esta - você pode ter que responder a algumas perguntas, pois esta é a primeira vez que o Unison está sendo executado:
root@server1:/var/www# unison /var/www ssh://192.168.1.102//var/www
Contatando o servidor...
Conectado [//server1//var/www -> //server2//var/www]
Procurando mudanças
Aviso: Nenhum arquivo de arquivo foi encontrado para essas raízes, cujos nomes canônicos são:
/var/www
//server2//var/www
Isso pode acontecer porque esta é a primeira vez que você sincronizou essas raízes,
ou porque você atualizou o Unison para uma nova versão com um formato de arquivo diferente.A detecção de atualizações pode levar um tempo nesta execução se os réplicas forem
grande.O Unison assumirá que o 'último estado sincronizado' de ambas as réplicas oi completamente vazio. Isso significa que quaisquer arquivos que sejam diferentes
serão relatados como conflitos, e quaisquer arquivos que existam apenas em uma
replica serão considerados novos e propagados para a outra replica.
Se as duas réplicas forem idênticas, então nenhuma mudança será relatada.Se você ver esta mensagem repetidamente, pode ser porque uma de suas máquinas
está obtendo seu endereço do DHCP, o que está causando a mudança de seu nome de host
entre as sincronizações. Veja a documentação para a variável de ambiente UNISONLOCALHOSTNAME
para obter conselhos sobre como corrigir isso.Doações para o projeto Unison são aceitas com gratidão:
http://www.cis.upenn.edu/~bcpierce/unisonPressione return para continuar.[] <-- Pressione Enter Aguardando mudanças do servidor
Reconciliando mudançasservidor local2
dir ----> example.com [f] <-- Pressione Enter
dir ----> example.de [f] <-- Pressione EnterProsseguir com a propagação de atualizações? [] <-- Digite "y"
Propagando atualizações
UNISON 2.40.102 começou a propagar mudanças às 10:17:17.94 em 25 de set de 2015
[BGN] Copiando example.com de /var/www para //server2//var/www
[BGN] Copiando example.de de /var/www para //server2//var/www
Atalho: copiado /var/www/example.de/web/index.html do arquivo local /var/www/.unison.example.com.d3783bddaaf59b9ba4d2ed0433f9db63.unison.tmp/web/index.html
[FIM] Copiando example.de
[FIM] Copiando example.com
UNISON 2.40.102 terminou de propagar mudanças às 10:17:17.94 em 25 de set de 2015
Salvando estado do sincronizador
Sincronização completa às 10:17:17 (2 itens transferidos, 0 ignorados, 0 falhados)Verifique o diretório /var/www no server1 e no server2 agora, e você deve encontrar que eles estão sincronizados agora.
Claro, não queremos executar o Unison interativamente, portanto, podemos criar um arquivo de preferências (/root/.unison/default.prf) que contém todas as configurações que teríamos que especificar na linha de comando:
nano /root/.unison/default.prf# Raízes da sincronização
root = /var/www
root = ssh://192.168.1.102//var/www
# Caminhos a sincronizar
#path = current
#path = common
#path = .netscape/bookmarks.html
# Algumas regexps especificando nomes e caminhos a ignorar
#ignore = Path stats ## ignora /var/www/stats
#ignore = Path stats/* ## ignora /var/www/stats/*
#ignore = Path */stats ## ignora /var/www/somedir/stats, mas não /var/www/a/b/c/stats
#ignore = Name *stats ## ignora todos os arquivos/diretórios que terminam com "stats"
#ignore = Name stats* ## ignora todos os arquivos/diretórios que começam com "stats"
#ignore = Name *.tmp ## ignora todos os arquivos com a extensão .tmp
# Quando definido como verdadeiro, esta flag faz com que a interface do usuário ignore
# perguntas de confirmação em mudanças não conflitantes. (Mais
# precisamente, quando a interface do usuário termina de definir a
# direção de propagação para uma entrada e está prestes a passar para a
# próxima, ela ignorará todas as entradas não conflitantes e irá
# diretamente para o próximo conflito.)
auto=true
# Quando isso é definido como verdadeiro, a interface do usuário não fará
# perguntas. Mudanças não conflitantes serão propagadas;
# conflitos serão ignorados.
batch=true
# !Quando isso é definido como verdadeiro, o Unison solicitará uma confirmação extra
# se parecer que toda a réplica foi deletada, antes de propagar a mudança. Se a flag de batch
# também estiver definida, a sincronização será abortada. Quando a preferência de caminho
# é usada, a mesma confirmação será solicitada para caminhos de nível superior. (No momento, esta flag
# afeta apenas a interface de usuário de texto.) Veja também a preferência de ponto de montagem.
confirmbigdel=true
# Quando esta preferência é definida como verdadeira, o Unison usará o
# tempo de modificação e o comprimento de um arquivo como um `número de inode pseudo`
# ao escanear réplicas em busca de atualizações, em vez de ler
# o conteúdo completo de cada arquivo. No Windows, isso pode fazer com que
# o Unison perca a propagação de uma atualização se o tempo de modificação
# e o comprimento do arquivo não forem alterados pela atualização.
# No entanto, o Unison nunca sobrescreverá tal atualização com uma
# mudança da outra réplica, pois sempre faz uma verificação segura
# para atualizações logo antes de propagar uma mudança. Assim, é
# razoável usar esta opção no Windows na maior parte do tempo
# e ocasionalmente executar o Unison uma vez com fastcheck definido como falso,
# se você estiver preocupado que o Unison possa ter ignorado uma atualização.
# O valor padrão da preferência é auto, que faz
# o Unison usar verificação rápida em réplicas Unix (onde é seguro)
# e verificação lenta em réplicas Windows. Para compatibilidade
# retroativa, sim, não e padrão podem ser usados no lugar de
# verdadeiro, falso e auto. Veja a seção "Verificação Rápida" para mais
# informações.
fastcheck=true
# Quando esta flag é definida como verdadeira, os atributos de grupo dos
# arquivos são sincronizados. Se os nomes de grupo ou os identificadores de grupo
# são sincronizados depende da preferência numerids.
group=true
# Quando esta flag é definida como verdadeira, os atributos de proprietário dos
# arquivos são sincronizados. Se os nomes de proprietário ou os identificadores de proprietário
# são sincronizados depende da preferência extttnumerids.
owner=true
# Incluir a preferência -prefer root faz com que o Unison sempre
# resolva conflitos a favor do root, em vez de pedir orientação ao
# usuário. (A sintaxe de root é a mesma que para a preferência de root, além dos valores especiais
# newer e older.) Esta preferência é substituída pela preferência preferpartial.
# Esta preferência deve ser usada apenas se você tiver certeza de que sabe
# o que está fazendo!
prefer=newer
# Quando esta preferência é definida como verdadeira, a interface de usuário
# de texto não imprimirá nada, exceto em caso de erros.
# Definir silent como verdadeiro automaticamente define a preferência de batch
# como verdadeira.
silent=true
# Quando esta flag é definida como verdadeira, os tempos de modificação de arquivos (mas não
# os modtimes de diretórios) são propagados.
times=trueOs comentários devem tornar o arquivo autoexplicativo, exceto para as diretivas de caminho. Se você não especificar diretivas de caminho, então os diretórios nas diretivas de raiz serão sincronizados. Se você especificar diretivas de caminho, então os caminhos são relativos ao caminho raiz (por exemplo, root = /var/www e path = current traduz para /var/www/current), e apenas esses subdiretórios serão sincronizados, não o diretório inteiro especificado na diretiva de raiz.
Você pode descobrir mais sobre as opções disponíveis dando uma olhada na página de manual do Unison:
man unisonAgora que colocamos todas as configurações em um arquivo de preferências (especialmente as diretivas de raiz (e opcionalmente o caminho)), podemos executar o Unison sem argumentos:
unison5 Criando um Job Cron para o Unison
server1:
Queremos automatizar a sincronização, por isso criamos um job cron para isso no server1.example.com:
crontab -e*/5 * * * * /usr/bin/unison &> /dev/nullIsso executaria o Unison a cada 5 minutos; ajuste conforme suas necessidades (veja
man 5 crontab). Eu uso o caminho completo para o unison aqui (/usr/bin/unison) apenas para garantir que o cron saiba onde encontrar o unison. Sua localização do unison pode diferir. Execute
which unisonpara descobrir onde está o seu.
6 Testando o Unison
Agora vou testar a sincronização bidirecional do Unison para ver se a configuração está totalmente funcionando.
Execute o seguinte comando no server1 para criar um arquivo de teste com o conteúdo “Teste 1”:
Server1
echo "Teste 1" > /var/www/test.txtAgora aguarde pelo menos 5 minutos (já que criamos um job cron que roda uma vez a cada 5 minutos). Em seguida, execute no server2:
cat /var/www/test.txtpara mostrar o conteúdo do arquivo test.txt na tela. A saída deve ser semelhante a esta captura de tela.

Agora execute este comando no server2 que atualiza o conteúdo do nosso arquivo de teste para “Teste 2”:
Server2
echo "Teste 2" > /var/www/test.txtE aguarde pelo menos 5 minutos. Em seguida, execute o comando cat no server1:
Server1
cat /var/www/test.txtA saída deve ser como mostrado na captura de tela.

7 Links
- Unison: http://www.cis.upenn.edu/~bcpierce/unison/
- Debian: http://www.debian.org/
Receba novas postagens na sua caixa de entrada
Sem spam. Cancele a assinatura a qualquer momento.