Wie zuverlässig ist Unison? Hat es jemals deine Daten ruiniert?

Ich habe Unison seit 2004 so oder so verwendet. In einer Antwort auf eine andere Frage gab ich ihm gegenüber rsync ein Nicken als Werkzeug zum Sichern / Synchronisieren Ihrer Daten zwischen Maschinen.

In all dieser Zeit hat Unison meine Daten nie im Sinne von Aktenvernichtung ruiniert. Es zeigte jedoch eine gewisse Sensibilität für Randbedingungen wie verwendete Dateien, Berechtigungen oder plattformübergreifende Probleme. Sie müssen dies sorgfältig untersuchen, wenn beim Synchronisieren Ihrer Dateien mit Unison Fehler auftreten. Speichern Sie Ihre Protokolle.

Vor ein paar Wochen entschied ich mich, Unison nicht mehr zu verwenden und ging zurück zu rsync. Hauptgründe:

• Unison ist nicht mehr aktiv entwickelt, während Rsync dies tut
• Unison ist im realen Einsatz langsamer als rsync. Ich habe Hunderttausende von Dateien mit mehr als 150 GB in meinem Heimatverzeichnis. Die Sicherung eines Arbeitstages auf einem USB-Laufwerk dauert bei Unison etwa 10 Minuten, bei der neuesten Version von Rsync jedoch nur 1-2 Minuten.
• Die Datenbanken von Unison müssen alle paar Monate aufgrund der oben genannten Randfälle neu aufgebaut werden, beispielsweise durch plötzliches Trennen des empfangenden Dateisystems. Wenn sie beschädigt sind, werden Ihre Dateien NICHT zerstört, aber sie werden möglicherweise nicht synchronisiert und geben Ihnen seltsame Fehler. Diese Neuerstellung der Datenbank kann, insbesondere bei Remote-Volumes, Stunden oder sogar Tage dauern.

Ich habe es nicht so lange wie ttarchala verwendet, aber es funktioniert gut für kleinere Dateisätze und ich habe keine Daten verloren.

Obwohl es sich nicht in aktiver Entwicklung befindet, wird es bis zu einem gewissen Grad beibehalten. Es wurden in den letzten Monaten Updates / Bugfixes für den Quelltextbaum bereitgestellt, und Sie können hier beispielsweise aktuelle Binärdateien herunterladen .

Beachten Sie auch, dass Sie die Leistung verbessern können, indem Sie fastcheck / pretendwin festlegen, bei dem Änderungen an Dateien nach Größe und Datum erkannt werden, anstatt die gesamte Datei zu prüfen.

Ich habe es eine ganze Weile benutzt (um zwischen Desktop und Laptop zu synchronisieren). Während die anderen schreiben, ist die Synchronisierung sehr vorsichtig, und ich habe nie irgendwelche Dateien verloren. Bei Problemen kann eine (zeitraubende) Neusynchronisierung erforderlich sein, aber am Ende sortiert sich alles aus.

Im regulären Betrieb ist es schnell und sicher.

Ich habe Unison seit mindestens 8 Jahren auf meinen Macs verwendet. Ich habe noch nie Unison beschädigt oder habe eine Datei verloren. Zu Beginn hatte ich einige Probleme mit Unison, die Ressource-Gabeln nicht verstanden, was zu Synchronisierungsfehlern führte.

Ich fing an, Unison zu verwenden, nachdem ich herausgefunden hatte, dass der Finder auf meinem Mac B & W G3 kopierte Dateien unbemerkt beschädigt hatte, indem er zufällig ein oder zwei Bytes je Megabyte geändert hatte. (Ursache ist ein Hardwareproblem mit Firewire auf Rev. 1-Logikplatinen.) Seit diesem Problem war ich wirklich sehr paranoid beim Vergleich von Sicherungskopien, und Unison tut das gut für mich.

Ich habe aufgehört, Unison zu verwenden, weil:

• Sonderzeichen und internationale Zeichen in einem Dateinamen können nicht korrekt verarbeitet werden. Ich denke, dass diese Dateien nicht kopiert wurden (aber ich bin mir nicht sicher).
• Auf einem Mac stürzte die (optionale) GUI häufig ab, sodass ich den Synchronisierungsvorgang nach jedem Absturz neu starten musste.

Dies sind die Mängel von Unison:

Wenn Sie zwei Cygwin-Verzeichnisse unter Windows synchronisieren, werden die symbolischen Links, die Cygwin verwendet, und der Inhalt beschädigt:

C:\Program Files\Unison>"Unison-2.40.102 Text.exe" c:\cygwin socket://xps:4321/c:\cygwin -path bin UNISON 2.40.102 started propagating changes at 03:32:12.55 on 28 Feb 2013 [BGN] Updating file bin/X from C:/cygwin to //xps/C:/cygwin   $ ls -l /bin/X //xps/c/cygwin/bin/X -rwxr-xr-x+ 1 Administrators ???????? 19 Feb 28 03:32 //xps/c/cygwin/bin/X lrwxrwxrwx 1 Chloe None 8 Jan 28 18:35 /bin/X -> XWin.exe   $ stat /bin/X //xps/c/cygwin/bin/X File: `/bin/X' -> `XWin.exe' Size: 8 Blocks: 1 IO Block: 65536 symbolic link Device: f8e5edb8h/4175818168d Inode: 1125899907027010 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 1006/ Chloe) Gid: ( 513/ None) Access: 2013-01-28 18:35:38.648870400 -0500 Modify: 2013-01-28 18:35:38.648870400 -0500 Change: 2013-01-28 18:35:38.648870400 -0500 Birth: 2013-01-28 18:35:38.648870400 -0500 File: `//xps/c/cygwin/bin/X' Size: 19 Blocks: 1 IO Block: 65536 regular file Device: 808a8f0bh/2156564235d Inode: 4222124650737757 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 544/Administrators) Gid: (4294967295/????????) Access: 2013-02-28 03:32:20.619899500 -0500 Modify: 2013-02-28 03:32:20.619899500 -0500 Change: 2013-02-28 03:32:20.629884400 -0500 Birth: 2013-02-26 13:21:32.963302500 -0500 

Beachten Sie die Größenänderung und die Berechtigungen? Wenn auf dem Zielcomputer versucht wird, den Befehl auszuführen, schlägt der Befehl fehl:

Chloe@xps /usr/bin $ X bash: ./X: cannot execute binary file 

Ich muss rsync verwenden, um die symbolischen Links korrekt zu kopieren.

$ rsync -arvz /cygdrive/c/cygwin/bin/ //xps/c/cygwin/bin sending incremental file list ./ X -> XWin.exe 

Ein weiterer Fehler ist, dass Unison die geänderten Zeiten NICHT standardmäßig beibehält (es ist jedoch möglich, die -timesOption zu verwenden, um Änderungszeiten für unisonale Synchronisierung von Dateien festzulegen)! Wenn Sie synchronisieren, werden die geänderten Zeiten auf die Dateierstellungszeit am Ziel festgelegt:

$ unison 'c:\Sites' '\\xps\c\Sites' ... new file ----> ruby-env.sh ... [BGN] Copying ruby-env.sh from c:/Sites to //xps/c/Sites [END] Copying ruby-env.sh    $ ls -l ruby-env.sh //xps/c/sites/ruby-env.sh ----------+ 1 ???????? ???????? 188 Feb 28 02:48 //xps/c/sites/ruby-env.sh -rw-r--r--+ 1 Chloe None 188 Feb 27 03:06 ruby-env.sh 

Theoretisch könnten Sie möglicherweise Daten verlieren, wenn Sie

1. 2 synchronisierte Dateispeicherorte haben, Location1, Location2,
2. Eine synchronisierte Kopie einer Datei am zweiten Speicherort ändern,
3. Mit Unison zwischen dem 1. und dem 3. Standort synchronisiert,
4. am dritten Ziel eine Datei mit einem neueren Änderungsdatum aufgrund von Unison erstellt,
5. ein anderes Sync-Tool wie rsync oder SyncToy verwendet,
6. dann das 3. Ziel erneut mit dem 2. Ort synchronisiert, der tatsächlich später als die 1. Quelle geändert wurde, jedoch vor dem Zeitpunkt der Erstellung der 3. Zieldatei,
7. Das andere Synchronisierungstool stellt fest, dass der Zeitpunkt für den dritten Ort neuer ist, und überschreibt die Änderungen am zweiten Ort.
8. Dabei Daten verlieren.