Насколько надежен Унисон? Это когда-нибудь испортило ваши данные?

Я использую и выключаю Unison с 2004 года. В ответ на другой вопрос я дал ему кавычку на rsync как инструмент для резервного копирования / синхронизации ваших данных между компьютерами.

За все это время Unison никогда не разрушал мои данные в смысле уничтожения содержимого файлов. Однако он отображал некоторую чувствительность к граничным условиям, таким как используемые файлы, разрешения или кросс-платформенные проблемы. Вам нужно будет внимательно изучить это, если у вас возникнут какие-либо ошибки при синхронизации ваших файлов с Unison. Сохраните ваши логи.

Пару недель назад я решил прекратить использование Unison и вернулся к rsync. Основные причины:

• Унисон больше не активно развивается, в то время как rsync
• Унисон медленнее, чем rsync, в реальном мире, где у меня есть сотни тысяч файлов общим объемом более 150 ГБ в моем домашнем каталоге; Резервное копирование рабочего дня на USB-накопитель с Unison занимает около 10 минут, а с последним rsync - всего 1-2 минуты.
• Базы данных Unison необходимо перестраивать каждые несколько месяцев из-за вышеупомянутых крайних случаев, таких как внезапное отключение принимающей файловой системы; когда они повреждены, ваши файлы НЕ будут уничтожены, но они могут остаться несинхронизированными и приведут к странным ошибкам. Эта перестройка базы данных, особенно с удаленными томами, может занять часы или даже дни.

Я не использовал его так долго, как ttarchala, но он хорошо работает для небольших наборов файлов, и я не потерял никаких данных.

Хотя он не находится в стадии активной разработки, он поддерживается в некоторой степени. За последние несколько месяцев были обновлены / исправлены ошибки в исходном дереве, и вы можете получить текущие двоичные файлы здесь (например).

Также обратите внимание, что вы можете улучшить производительность, установив fastcheck / pretendwin, который определяет изменения файла по размеру и дате, а не контрольную сумму всего файла.

Я использовал его довольно долго (для синхронизации между настольным компьютером и ноутбуком). Как пишут другие, во время синхронизации это делается довольно аккуратно, и я никогда не терял никаких файлов. В случае возникновения проблем может потребоваться (трудоемкая) повторная синхронизация, но в конце концов все уладится.

В обычной работе это быстро и безопасно.

Я использовал Unison на своих Mac по крайней мере 8 лет. У меня никогда не было Unison поврежден или потерял файл. Вначале у меня были некоторые проблемы с Unison, не понимающими вилки ресурсов, что привело к сбоям синхронизации.

Я начал использовать Unison после того, как выяснил, что Finder на моем Mac B & W G3 молча повреждает скопированные файлы, случайным образом меняя один или два байта на каждый мегабайт. (Из-за аппаратной проблемы с Firewire на платах логики Rev. 1). С тех пор я очень, очень параноидально сравнивал резервные копии, и Unison делает это хорошо для меня.

Я перестал использовать Unison, потому что:

• он не может правильно обрабатывать специальные и международные символы в имени файла. Я думаю, что эти файлы не были скопированы (но я не уверен в этом).
• На Mac (необязательный) графический интерфейс часто зависал, поэтому мне приходилось перезапускать процесс синхронизации после каждого сбоя.

Это недостатки Unison:

При синхронизации двух каталогов Cygwin в Windows он повреждает символические ссылки, которые использует Cygwin, и портит содержимое:

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 

Обратите внимание на изменение размера и разрешений? На целевом компьютере при попытке выполнить команду происходит сбой:

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

Я должен использовать rsync для правильного копирования символических ссылок.

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

Еще одним недостатком является то, что Unison НЕ сохраняет измененное время по умолчанию (однако можно использовать -timesопцию, чтобы настроить синхронизацию времени изменения файла в унисон)! Если вы синхронизируете, измененное время будет установлено на время создания файла в месте назначения:

$ 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 

Теоретически, вы можете потерять данные, если вы

1. Имейте 2 синхронизированных местоположения файла, Location1, Location2,
2. Изменить синхронизированную копию файла во втором месте,
3. Синхронизировано с Unison между 1-м местоположением и 3-м местоположением,
4. создал файл в 3-м месте назначения с более новой датой изменения из-за Unison,
5. использовал другой инструмент синхронизации, такой как rsync или SyncToy,
6. затем снова синхронизировал 3-е место назначения со 2-м местоположением, которое было фактически изменено позже, чем 1-й источник, но до времени создания файла 3-го места назначения,
7. Другой инструмент синхронизации заметит, что время 3-го местоположения новее, и перезапишет изменения во втором местоположении,
8. Тем самым теряя данные.