Sincronizzazione file · 9 min read · Feb 09, 2026
Impostare la sincronizzazione dei file Unison tra due server su Debian 8 (Jessie)
Questo tutorial mostra come impostare la sincronizzazione dei file tra due server Debian 8 con Unison. Unison è uno strumento di sincronizzazione dei file simile a rsync, la grande differenza è che tiene traccia/sincronizza le modifiche in entrambe le direzioni, cioè, i file modificati su server1 verranno replicati su server2 e viceversa.
1 Nota preliminare
In questo tutorial utilizzerò i seguenti due server Debian:
- server1.example.com con l’indirizzo IP 192.168.1.101
- server2.example.com con l’indirizzo IP 192.168.1.102
Voglio sincronizzare la directory /var/www tra i due server. Eseguirò Unison come utente root in questo tutorial in modo che Unison abbia sufficienti permessi per sincronizzare i permessi utente e di gruppo.
Tutti i comandi in questo tutorial vengono eseguiti come utente root. Accedi a entrambi i server nella shell come root e inizia con il passo 2 “ Installazione di Unison “.
2 Installazione di Unison
server1/server2:
Unison deve essere installato su server1 e server2; poiché ci connettiamo da server1 a server2 utilizzando SSH, abbiamo anche bisogno dei pacchetti SSH e installerò l’editor nano per la modifica dei file nella shell. Questo può essere ottenuto come segue:
apt-get -y install unison openssh-server ssh nano3 Creazione di una coppia di chiavi private/pubbliche su server1
server1:
Ora creiamo una coppia di chiavi private/pubbliche su server1.example.com:
ssh-keygen -t dsaroot@server1:~# ssh-keygen -t dsa
Generazione di una coppia di chiavi dsa pubblica/privata.
Inserisci il file in cui salvare la chiave (/root/.ssh/id_dsa): <– ENTER
Directory creata ‘/root/.ssh’.
Inserisci la passphrase (vuoto per nessuna passphrase): <– ENTER
Inserisci di nuovo la stessa passphrase: <– ENTER
La tua identificazione è stata salvata in /root/.ssh/id_dsa.
La tua chiave pubblica è stata salvata in /root/.ssh/id_dsa.pub.
L’impronta della chiave è:
ba:82:e1:a1:42:9b:d4:c8:99:c8:bd:8b:7d:4d:d4:66 root@server1
L’immagine randomart della chiave è:
+—[DSA 1024]—-+
| |
| |
| . |
| . E |
|+ * . S |
|.Ooo o |
|ooo+. + |
|oo=… o |
|.. oo.. |
+—————–+
root@server1:~#
È importante non inserire una passphrase altrimenti il mirroring non funzionerà senza interazione umana, quindi premi semplicemente ENTER!
Successivamente, copiamo la nostra chiave pubblica su 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]L'autenticità dell'host '192.168.1.102 (192.168.1.102)' non può essere stabilita.
L'impronta della chiave ECDSA è 51:7f:b4:ed:bd:e3:fc:16:2f:55:5c:e1:2c:d7:3d:a9.
Sei sicuro di voler continuare a connetterti (sì/no)? <-- sì (vedrai questo solo se è la prima volta che ti connetti a server2)
/usr/bin/ssh-copy-id: INFO: tentativo di accesso con la nuova chiave(i), per filtrare quelle già installate
/usr/bin/ssh-copy-id: INFO: 1 chiave(e) rimangono da installare -- se ti viene chiesto ora è per installare le nuove chiavi
La password di '[email protected]': <-- password root di server2Numero di chiave(e) aggiunte: 1Ora prova a connetterti alla macchina, con: "ssh '[email protected]'"
e controlla per assicurarti che siano state aggiunte solo le chiave(e) che volevi.Ora controlla su server2 se la chiave pubblica di server1 è stata trasferita correttamente:
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 Esecuzione di Unison
server1:
Possiamo ora eseguire Unison per la prima volta per sincronizzare la directory /var/www su entrambi i server. Su server1 esegui:
unison /var/www ssh://192.168.1.102//var/wwwL’output sarà simile a questo - potresti dover rispondere a qualche domanda poiché è la prima volta che viene eseguito Unison:
root@server1:/var/www# unison /var/www ssh://192.168.1.102//var/www
Contattando il server...
Connesso [//server1//var/www -> //server2//var/www]
Cercando modifiche
Avviso: Nessun file di archivio è stato trovato per queste radici, i cui nomi canonici sono:
/var/www
//server2//var/www
Questo può accadere o
perché è la prima volta che hai sincronizzato queste radici,
o perché hai aggiornato Unison a una nuova versione con un formato di archivio diverso.La rilevazione degli aggiornamenti potrebbe richiedere un po' di tempo in questo run se i replica sono
grandi.Unison assumerà che lo 'stato sincronizzato' finale di entrambi i replica
fosse completamente vuoto. Questo significa che qualsiasi file che è diverso
verrà segnalato come conflitto, e qualsiasi file che esiste solo su un
replica sarà giudicato come nuovo e propagato all'altro replica.
Se i due replica sono identici, allora non verranno segnalate modifiche.Se vedi questo messaggio ripetutamente, potrebbe essere perché una delle tue macchine
sta ottenendo il suo indirizzo da DHCP, il che sta causando il cambiamento del suo nome host
tra le sincronizzazioni. Vedi la documentazione per la variabile d'ambiente UNISONLOCALHOSTNAME
per consigli su come correggere questo.Le donazioni al progetto Unison sono gratefully accepted:
http://www.cis.upenn.edu/~bcpierce/unisonPremi invio per continuare.[] <-- Premi Invio In attesa di modifiche dal server
Riconciliazione delle modificheserver locale2
dir ----> example.com [f] <-- Premi Invio
dir ----> example.de [f] <-- Premi InvioProcedere con la propagazione degli aggiornamenti? [] <-- Inserisci "y"
Propagazione degli aggiornamenti
UNISON 2.40.102 ha iniziato a propagare le modifiche alle 10:17:17.94 del 25 settembre 2015
[BGN] Copiando example.com da /var/www a //server2//var/www
[BGN] Copiando example.de da /var/www a //server2//var/www
Scorciatoia: copiato /var/www/example.de/web/index.html da file locale /var/www/.unison.example.com.d3783bddaaf59b9ba4d2ed0433f9db63.unison.tmp/web/index.html
[END] Copiando example.de
[END] Copiando example.com
UNISON 2.40.102 ha terminato di propagare le modifiche alle 10:17:17.94 del 25 settembre 2015
Salvataggio dello stato del sincronizzatore
Sincronizzazione completata alle 10:17:17 (2 elementi trasferiti, 0 saltati, 0 falliti)Controlla ora la directory /var/www su server1 e server2, e dovresti trovare che sono sincronizzati ora.
Naturalmente, non vogliamo eseguire Unison in modo interattivo, quindi possiamo creare un file di preferenze ( /root/.unison/default.prf) che contiene tutte le impostazioni che altrimenti dovremmo specificare sulla riga di comando:
nano /root/.unison/default.prf# Radici della sincronizzazione
root = /var/www
root = ssh://192.168.1.102//var/www
# Percorsi da sincronizzare
#path = current
#path = common
#path = .netscape/bookmarks.html
# Alcuni regex che specificano nomi e percorsi da ignorare
#ignore = Path stats ## ignora /var/www/stats
#ignore = Path stats/* ## ignora /var/www/stats/*
#ignore = Path */stats ## ignora /var/www/somedir/stats, ma non /var/www/a/b/c/stats
#ignore = Name *stats ## ignora tutti i file/directory che terminano con "stats"
#ignore = Name stats* ## ignora tutti i file/directory che iniziano con "stats"
#ignore = Name *.tmp ## ignora tutti i file con estensione .tmp
# Quando impostato su true, questo flag causa l'interfaccia utente a saltare
# la richiesta di conferma su modifiche non conflittuali. (Più
# precisamente, quando l'interfaccia utente ha finito di impostare la
# direzione di propagazione per un'entrata e sta per passare alla
# successiva, salterà tutte le voci non conflittuali e andrà
# direttamente al prossimo conflitto.)
auto=true
# Quando questo è impostato su true, l'interfaccia utente non farà domande
# affatto. Le modifiche non conflittuali verranno propagate;
# i conflitti verranno saltati.
batch=true
# !Quando questo è impostato su true, Unison richiederà un'ulteriore
# conferma se sembra che l'intero replica sia stato
# eliminato, prima di propagare la modifica. Se il flag batch è
# impostato, la sincronizzazione verrà interrotta. Quando viene
# utilizzata la preferenza del percorso, la stessa conferma verrà
# richiesta per i percorsi di primo livello. (Al momento, questo flag influisce solo
# sull'interfaccia utente testuale.) Vedi anche la preferenza del mountpoint.
confirmbigdel=true
# Quando questa preferenza è impostata su true, Unison utilizzerà il
# tempo di modifica e la lunghezza di un file come un `numero di inode pseudo`
# quando scansiona i replica per aggiornamenti, invece di leggere
# il contenuto completo di ogni file. Sotto Windows, questo può causare
# a Unison di non propagare un aggiornamento se il tempo di modifica
# e la lunghezza del file non sono stati modificati dall'aggiornamento.
# Tuttavia, Unison non sovrascriverà mai tale aggiornamento con una
# modifica dall'altro replica, poiché esegue sempre un controllo sicuro
# per aggiornamenti appena prima di propagare una modifica. Quindi, è
# ragionevole utilizzare questo switch sotto Windows la maggior parte delle volte
# e occasionalmente eseguire Unison una volta con fastcheck impostato su false,
# se sei preoccupato che Unison possa aver trascurato un aggiornamento.
# Il valore predefinito della preferenza è auto, che causa
# Unison di utilizzare il controllo veloce sui replica Unix (dove è sicuro)
# e il controllo lento sui replica Windows. Per compatibilità
# retroattiva, sì, no e predefinito possono essere utilizzati al posto di
# true, false e auto. Vedi la sezione "Controllo veloce" per ulteriori
# informazioni.
fastcheck=true
# Quando questo flag è impostato su true, gli attributi di gruppo dei
# file vengono sincronizzati. Se i nomi di gruppo o gli identificatori di gruppo
# vengono sincronizzati dipende dalla preferenza numerids.
group=true
# Quando questo flag è impostato su true, gli attributi di proprietario dei
# file vengono sincronizzati. Se i nomi di proprietario o gli identificatori di proprietario
# vengono sincronizzati dipende dalla preferenza
# extttnumerids.
owner=true
# Includere la preferenza -prefer root causa Unison a
# risolvere sempre i conflitti a favore di root, piuttosto che chiedere
# indicazioni all'utente. (La sintassi di root è la stessa di quella per
# la preferenza root, più i valori speciali newer e older.)
# Questa preferenza è sovrascritta dalla preferenza preferpartial.
# Questa preferenza dovrebbe essere utilizzata solo se sei sicuro di sapere
# cosa stai facendo!
prefer=newer
# Quando questa preferenza è impostata su true, l'interfaccia utente testuale
# non stamperà nulla, tranne nel caso di errori.
# Impostare silent su true imposta automaticamente la preferenza batch
# su true.
silent=true
# Quando questo flag è impostato su true, i tempi di modifica dei file (ma non
# i modtimes delle directory) vengono propagati.
times=trueI commenti dovrebbero rendere il file autoesplicativo, tranne per le direttive di percorso. Se non specifichi direttive di percorso, allora le directory nelle direttive root verranno sincronizzate. Se specifichi direttive di percorso, allora i percorsi sono relativi al percorso radice (ad esempio, root = /var/www e path = current si traduce in /var/www/current), e solo queste sottodirectory verranno sincronizzate, non l’intera directory specificata nella direttiva root.
Puoi scoprire di più sulle opzioni disponibili dando un’occhiata alla pagina man di Unison:
man unisonOra che abbiamo messo tutte le impostazioni in un file di preferenze (soprattutto le direttive root (e opzionalmente il percorso)), possiamo eseguire Unison senza argomenti:
unison5 Creazione di un lavoro Cron per Unison
server1:
Vogliamo automatizzare la sincronizzazione, ecco perché creiamo un lavoro cron per essa su server1.example.com:
crontab -e*/5 * * * * /usr/bin/unison &> /dev/nullQuesto eseguirebbe Unison ogni 5 minuti; aggiustalo secondo le tue necessità (vedi
man 5 crontab). Utilizzo il percorso completo per unison qui ( /usr/bin/unison) solo per essere sicuro che cron sappia dove trovare unison. La tua posizione di unison potrebbe differire. Esegui
which unisonper scoprire dove si trova il tuo.
6 Testare Unison
Ora testerò la sincronizzazione bidirezionale di Unison per vedere se la configurazione funziona completamente.
Esegui il seguente comando su server1 per creare un file di test con il contenuto “Test 1”:
Server1
echo "Test 1" > /var/www/test.txtOra aspetta almeno 5 minuti (poiché abbiamo creato un cronjob che viene eseguito una volta ogni 5 minuti). Quindi esegui su server2:
cat /var/www/test.txtper mostrare il contenuto del file test.txt sullo schermo. L’output dovrebbe essere simile a questo screenshot.

Ora esegui questo comando su server2 che aggiorna il contenuto del nostro file di test a “Test 2”:
Server2
echo "Test 2" > /var/www/test.txtE aspetta almeno 5 minuti. Quindi esegui il comando cat su server1:
Server1
cat /var/www/test.txtL’output dovrebbe essere come mostrato nello screenshot.

7 Link
- Unison: http://www.cis.upenn.edu/~bcpierce/unison/
- Debian: http://www.debian.org/
Ricevi i nuovi post nella tua casella di posta.
Nessuno spam. Disiscriviti in qualsiasi momento.