Меня интересуют факты, когда использование unison ( http://www.cis.upenn.edu/~bcpierce/unison/ ) разрушило ваши данные? Я хочу узнать о его надежности.
6 ответов
22
Я использую и отключаю Unison с 2004 года. В ответе на другой вопрос я дал ему указание на rsync как инструмент для резервного копирования / синхронизации ваших данных между компьютерами.
За все это время Unison никогда не разрушал мои данные в смысле уничтожения содержимого файлов. Однако он отображал некоторую чувствительность к граничным условиям, таким как используемые файлы, разрешения или кросс-платформенные проблемы. Вам нужно будет внимательно изучить это, если у вас возникнут какие-либо ошибки при синхронизации ваших файлов с Unison. Сохраните ваши логи.
Пару недель назад я решил прекратить использование Unison и вернулся к rsync. Основные причины:
- Унисон больше не активно развивается, в то время как rsync
- Unison работает медленнее, чем rsync, в реальном мире, где у меня есть сотни тысяч файлов общим объемом более 150 ГБ в моем домашнем каталоге; Резервное копирование рабочего дня на USB-накопитель с Unison занимает около 10 минут, а с последним rsync - всего 1-2 минуты.
- Базы данных Unison необходимо перестраивать каждые несколько месяцев из-за вышеупомянутых крайних случаев, таких как внезапное отключение принимающей файловой системы; когда они повреждены, ваши файлы НЕ будут уничтожены, но они могут остаться несинхронизированными и приведут к странным ошибкам. Эта перестройка базы данных, особенно с удаленными томами, может занять часы или даже дни.
9
Я не использовал его так долго, как ttarchala, но он хорошо работает для небольших наборов файлов, и я не потерял никаких данных.
Хотя он не находится в стадии активной разработки, он поддерживается в некоторой степени. За последние несколько месяцев в дерево исходных текстов были внесены обновления / исправления, и вы можете получить текущие двоичные файлы здесь (например).
Также обратите внимание, что вы можете улучшить производительность, установив fastcheck/pretendwin, который определяет изменения файла по размеру и дате, а не контрольную сумму всего файла.
8
Я использовал его довольно долго (для синхронизации между настольным компьютером и ноутбуком). Как пишут другие, во время синхронизации это делается довольно аккуратно, и я никогда не терял никаких файлов. В случае возникновения проблем может потребоваться (отнимающая много времени) повторная синхронизация, но в конце концов все уладится.
В обычной работе это быстро и безопасно.
7
Я использовал Unison на своих Mac по крайней мере 8 лет. У меня никогда не было Unison поврежден или потерял файл. Вначале у меня были некоторые проблемы с Unison, не понимающими разветвления ресурсов, что привело к сбоям синхронизации.
Я начал использовать Unison после того, как выяснил, что Finder на моем Mac B & W G3 молча повреждает скопированные файлы, случайным образом меняя один или два байта на каждый мегабайт. (Вызвано аппаратной проблемой Firewire на платах логики Rev. 1) С тех пор, как я столкнулся с этой проблемой, я очень, очень параноидально сравнивал резервные копии, и Unison делает это хорошо для меня.
4
Я перестал использовать Unison, потому что:
- он не может правильно обрабатывать специальные и международные символы в имени файла. Я думаю, что эти файлы не были скопированы (но я не уверен в этом).
- На Mac (необязательный) графический интерфейс часто зависал, поэтому мне приходилось перезапускать процесс синхронизации после каждого сбоя.
3
Это недостатки 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 синхронизировать времена изменения файлов)! Если вы синхронизируете, измененное время будет установлено на время создания файла в месте назначения:
$ 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
Теоретически, вы можете потерять данные, если вы
- Имейте 2 синхронизированных местоположения файла, Location1, Location2,
- Изменить синхронизированную копию файла во втором месте,
- Синхронизировано с Unison между 1-м местоположением и 3-м местоположением,
- создал файл в 3-м месте назначения с более новой датой изменения из-за Unison,
- использовал другой инструмент синхронизации, такой как rsync или SyncToy,
- затем снова синхронизировал 3-е место назначения со 2-м местоположением, которое было фактически изменено позже, чем 1-й источник, но до времени создания 3-го места назначения,
- Другой инструмент синхронизации заметит, что время 3-го местоположения новее, и перезапишет изменения во втором местоположении,
- Тем самым теряя данные.