How reliable is Unison? Did it ever ruin your data?

Question

I am interested in facts, when using unison ( http://www.cis.upenn.edu/~bcpierce/unison/ ) ruined your data? I want to find out about its reliability.

Answer 1

I have been using Unison on and off since something like 2004. In an answer to another question I gave it a nod over rsync as a tool for backing up/synchronizing your data between machines.

In all this time Unison never ruined my data in the sense of shredding file contents. It displayed, however, some sensitivity to edge conditions such as files in use, permissions, or cross-platform issues. You will need to be careful to research this if you encounter any errors when synchronizing your files with Unison. Save your logs.

A couple of weeks ago I decided to stop using Unison and went back to rsync. Main reasons:

• Unison is no longer actively developed, while rsync is
• Unison is slower than rsync in real-world usage, where I have hundreds of thousands of files totaling more than 150 GB in my home directory; a day's work's backup to an USB drive takes about 10 minutes with Unison but only 1-2 minutes with latest rsync.
• Unison's databases need rebuilding every couple of months due to aforementioned edge cases, such as sudden disconnection of receiving file system; when they are corrupted, your files will NOT be destroyed but they may remain unsynchronized and will give you weird errors. This database rebuild, especially with remote volumes, can take hours or even days.

Answer 2

I haven't been using it as long as ttarchala, but it does work nicely for smaller filesets and I have not lost any data.

While it is not under active development, it is being maintained to some degree. There have been updates/bugfixes committed to the source tree in the last few months, and you can get current binaries here (for example).

Also note that you can improve performance by setting fastcheck/pretendwin which detects file changes by size & date, rather than checksumming the entire file.

Answer 3

I used it for quite a while (to synch between desktop and laptop). As the others write, it is quite careful during synch, and I never lost any files. In case of problems it may require a (time-consuming) resynch, but everything sorts itself out in the end.

In regular operation, it is both fast and secure.

Answer 4

I've used Unison on my Macs for at least 8 years. I've never had Unison corrupt or lose a file. Early on, I had some issues with Unison not understanding resource forks, which led to failures to synchronize.

I started using Unison after I figured out that Finder on my Mac B&W G3 was silently corrupting copied files by randomly changing a byte or two every megabyte. (Caused by a hardware issue with Firewire on Rev 1 logic boards.) Since that problem, I've been really, really paranoid about comparing backup copies, and Unison does that well for me.

Answer 5

I stopped using Unison because:

• it can't handle special and international characters in a file name correctly. I think that these files were not copied over (but I am not sure about that).
• On a Mac, the (optional) GUI crashed often, so I had to restart the syncing process after each crash.

Answer 6

These are the failings of Unison:

When synchronizing two Cygwin directories on Windows, it corrupts the symbolic links that Cygwin uses, and corrupts the contents:

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

Notice the change in size, and the permissions? On the destination machine, when trying to run the command, it fails:

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

I have to use rsync to copy the symbolic links correctly.

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

Another failing is Unison does NOT keep the modified times by default (it is however possible to use the -times option to make unison synchronize file modification times)! If you synchronize, the modified times are set to the file creation time on the destination:

$ 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

Theoretically, you could potentially lose data if you

1. Have 2 synchronized file locations, Location1, Location2,
2. Modify a synchronized copy of a file in 2nd location,
3. Synced with Unison between 1st location and a 3rd location,
4. created a file at the 3rd destination with a newer modified date due to Unison,
5. used a different sync tool such as rsync or SyncToy,
6. then synced the 3rd destination again with 2nd location, which was actually modified later than the 1st source, but before the 3nd destination file creation time,
7. The other sync tool will notice the 3rd location time is newer, and overwrite the changes to the 2nd location,
8. Thereby losing data.