Jak niezawodny jest Unison? Czy kiedykolwiek zrujnowało to twoje dane? [Zamknięte]

Interesują mnie fakty, kiedy użycie unison ( http://www.cis.upenn.edu/~bcpierce/unison/ ) zrujnowało twoje dane? Chcę dowiedzieć się o jego niezawodności.

Przestałem używać Unison, ponieważ:

• nie obsługuje poprawnie znaków specjalnych i międzynarodowych w nazwie pliku. Myślę, że te pliki nie zostały skopiowane (ale nie jestem tego pewien).
• Na komputerze Mac (opcjonalny) interfejs GUI często się zawieszał, więc musiałem ponownie uruchamiać proces synchronizacji po każdej awarii.

Używam Unisona z przerwami od 2004 roku. W odpowiedzi na inne pytanie skinęłam głową na rsync jako narzędzie do tworzenia kopii zapasowych / synchronizacji danych między komputerami.

Przez cały ten czas Unison nigdy nie zrujnował moich danych w sensie niszczenia zawartości plików. Wykazał jednak pewną wrażliwość na warunki brzegowe, takie jak używane pliki, uprawnienia lub problemy międzyplatformowe. Musisz zachować ostrożność, aby to sprawdzić, jeśli napotkasz jakieś błędy podczas synchronizacji plików z Unison. Zapisz swoje dzienniki.

Kilka tygodni temu postanowiłem przestać używać Unison i wróciłem do rsync. Główne powody:

• Unison nie jest już aktywnie rozwijany, podczas gdy rsync jest
• Unison działa wolniej niż rsync w rzeczywistym świecie, w którym mam setki tysięcy plików o łącznej pojemności ponad 150 GB w moim katalogu domowym; jednodniowa kopia zapasowa pracy na dysk USB zajmuje około 10 minut w Unison, ale tylko 1-2 minuty w najnowszym rsync.
• Bazy danych Unison wymagają przebudowy co kilka miesięcy z powodu wyżej wspomnianych przypadków skrajnych, takich jak nagłe odłączenie odbierającego systemu plików; gdy są uszkodzone, pliki NIE zostaną zniszczone, ale mogą pozostać niezsynchronizowane i powodować dziwne błędy. Odbudowywanie tej bazy danych, szczególnie w przypadku woluminów zdalnych, może zająć godziny, a nawet dni.

Nie używałem go tak długo, jak ttarchala, ale działa dobrze dla mniejszych zestawów plików i nie straciłem żadnych danych.

Chociaż nie jest aktywnie rozwijany, jest do pewnego stopnia utrzymywany. W ciągu ostatnich kilku miesięcy wprowadzono aktualizacje / poprawki błędów w drzewie źródłowym, a bieżące pliki binarne można pobrać tutaj (na przykład).

Pamiętaj również, że możesz poprawić wydajność, ustawiając opcję fastcheck / pretendwin, która wykrywa zmiany pliku według rozmiaru i daty, zamiast sprawdzania całego pliku.

Używałem go od dłuższego czasu (do synchronizacji między komputerem stacjonarnym a laptopem). Jak piszą inni, jest bardzo ostrożny podczas synchronizacji i nigdy nie straciłem żadnych plików. W przypadku problemów może to wymagać (czasochłonnego) ponownego zsynchronizowania, ale ostatecznie wszystko się załatwia.

Podczas normalnej pracy jest szybki i bezpieczny.

Używam Unison na moich komputerach Mac od co najmniej 8 lat. Nigdy nie miałem Unisona zepsutego ani nie straciłem pliku. Na początku miałem problemy z niezrozumieniem rozwidleń zasobów przez Unison, co doprowadziło do niepowodzenia synchronizacji.

Zacząłem używać Unison po tym, jak zorientowałem się, że Finder na moim komputerze Mac B&W G3 cicho uszkadza skopiowane pliki, zmieniając losowo bajt lub dwa co megabajt. (Przyczyną problemu sprzętowego z Firewire na kartach logicznych Rev 1). Od czasu tego problemu byłem naprawdę, bardzo paranoikiem, jeśli chodzi o porównywanie kopii zapasowych, a Unison robi to dobrze dla mnie.

Oto wady Unison:

Synchronizując dwa katalogi Cygwin w systemie Windows, psuje łącza symboliczne, których używa Cygwin, i psuje zawartość:

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

Zwróć uwagę na zmianę rozmiaru i uprawnienia? Na komputerze docelowym próba uruchomienia polecenia kończy się niepowodzeniem:

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

Muszę użyć rsync, aby poprawnie skopiować dowiązania symboliczne.

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

Kolejnym błędem jest to, że Unison NIE zachowuje domyślnie zmodyfikowanych czasów (można jednak użyć -timesopcji, aby unison synchronizował czasy modyfikacji plików)! W przypadku synchronizacji zmodyfikowane czasy są ustawiane na czas utworzenia pliku w miejscu docelowym:

$ 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

Teoretycznie możesz potencjalnie utracić dane

1. Posiadaj 2 zsynchronizowane lokalizacje plików, Lokalizacja1, Lokalizacja2,
2. Zmodyfikuj zsynchronizowaną kopię pliku w 2. lokalizacji,
3. Zsynchronizowane z Unison między 1. lokalizacją a 3. lokalizacją,
4. utworzył plik w 3. miejscu docelowym z nowszą datą modyfikacji z powodu Unison,
5. używał innego narzędzia synchronizacji, takiego jak rsync lub SyncToy,
6. następnie ponownie zsynchronizował 3. miejsce docelowe z 2. miejscem, które faktycznie zostało zmodyfikowane później niż 1. źródło, ale przed czasem utworzenia 3. pliku docelowego,
7. Drugie narzędzie synchronizacji zauważy, że czas trzeciej lokalizacji jest nowszy, i zastąpi zmiany drugiej lokalizacji,
8. W ten sposób tracisz dane.