Наскільки надійний Unison? Чи це коли-небудь руйнувало ваші дані? [зачинено]

Мене цікавлять факти, коли використання unison ( http://www.cis.upenn.edu/~bcpierce/unison/ ) зіпсувало ваші дані? Хочу дізнатися про його надійність.

Я перестав використовувати Unison через:

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

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

За весь цей час Unison ніколи не руйнував мої дані в сенсі подрібнення вмісту файлів. Однак він виявляв деяку чутливість до крайових умов, таких як файли, які використовуються, дозволи або проблеми з платформою. Вам потрібно буде уважно вивчити це, якщо у вас виникнуть помилки під час синхронізації файлів із Unison. Збережіть свої журнали.

Пару тижнів тому я вирішив припинити використання Unison і повернувся до rsync. Основні причини:

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

Я не використовую його так довго, як ttarchala, але він добре працює для менших наборів файлів, і я не втратив жодних даних.

Хоча він не перебуває в активному розвитку, він певною мірою підтримується. Останні кілька місяців були оновлені / виправлені помилки, пов’язані з деревом-джерелом, і ви можете отримати поточні бінарні файли тут (наприклад).

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

Я використовував його досить довго (для синхронізації між настільним та ноутбуком). Як пишуть інші, це дуже обережно під час синхронізації, і я ніколи не втрачав жодного файлу. У разі виникнення проблем може знадобитися (трудомісткий) пересинхронізація, але все врешті-решт вирішується.

При регулярній експлуатації він одночасно швидкий і надійний.

Я використовував Unison на своїх Mac, принаймні, 8 років. У мене ніколи не було корумпованих або втрачених файлів Unison. На початку у мене виникли проблеми з тим, що Unison не розумів вилки ресурсів, що призвело до помилок синхронізації.

Я почав використовувати Unison після того, як я зрозумів, що Finder на моєму Mac B&W G3 мовчки псує скопійовані файли, випадковим чином змінюючи байт-два на кожен мегабайт. (Викликана технічною проблемою з Firewire на логічних платах Rev 1.) З цієї проблеми я справді дуже насправді параноював порівняння резервних копій, і Unison це добре для мене.

Це недоліки 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. створив файл у третьому пункті з новою зміненою датою завдяки Unison,
5. використовували інший інструмент синхронізації, такий як rsync або SyncToy,
6. потім знову синхронізували 3-е місце призначення з 2-м місцем, яке фактично було змінено пізніше 1-го джерела, але до часу створення 3-го файлу призначення,
7. Інший інструмент синхронізації помітить, що час 3-го розташування стає новішим і замінить зміни на 2-е місце,
8. Тим самим втрачаються дані.