Unison ne kadar güvenilir? Verilerinizi hiç mahvetti mi? [kapalı]

Unison kullanırken ( http://www.cis.upenn.edu/~bcpierce/unison/ ) verilerinizi mahvettiğinde gerçeklerle ilgileniyorum ? Güvenilirliğini öğrenmek istiyorum.

Unison kullanmayı bıraktım çünkü:

• dosya adındaki özel ve uluslararası karakterleri doğru şekilde işleyemez. Bu dosyaların kopyalanmadığını düşünüyorum (ama bundan emin değilim).
• Mac'te (isteğe bağlı) GUI sık sık çöktü, bu yüzden her kilitlemeden sonra senkronizasyon işlemini yeniden başlatmak zorunda kaldım.

2004 gibi bir şey beri Unison açma ve kapatma kullanıyorum. Başka bir soruya cevap olarak ben rsync bir veri olarak yedekleme / veri makineleri arasında senkronize etmek için bir araç verdi.

Tüm bu zaman zarfında Unison, dosya içeriğini parçalama anlamında verilerimi hiçbir zaman mahvetmedi. Ancak, kullanılan dosyalar, izinler veya platformlar arası sorunlar gibi uç koşullara karşı bir miktar hassasiyet gösterdi. Dosyalarınızı Unison ile senkronize ederken herhangi bir hatayla karşılaşırsanız, bunu araştırmaya dikkat etmeniz gerekir. Günlüklerinizi kaydedin.

Birkaç hafta önce Unison'u kullanmayı bırakmaya karar verdim ve rsync'e geri döndüm. Ana sebepler:

• Unison artık aktif olarak geliştirilmiyor, rsync ise
• Unison, ana dizinde toplam 150 GB'tan fazla yüz binlerce dosyam olduğu gerçek dünya kullanımında rsync'den daha yavaş; bir günlük işin bir USB sürücüsüne yedeklenmesi Unison ile yaklaşık 10 dakika, en son rsync ile ise sadece 1-2 dakika sürer.
• Unison veritabanlarının, dosya sisteminin aniden kesilmesi gibi yukarıda belirtilen son durumlar nedeniyle her iki ayda bir yeniden oluşturulması gerekir; bozulduğunda, dosyalarınız SİLİNMEZ, ancak senkronize edilmemiş olarak kalabilir ve size garip hatalar verir. Bu veritabanı yeniden oluşturma, özellikle uzak birimlerle, saatler hatta günler sürebilir.

Ttarchala kadar uzun süredir kullanmıyorum, ancak daha küçük dosya kümeleri için güzel çalışıyor ve herhangi bir veri kaybetmedim.

Aktif gelişme altında olmasa da, bir dereceye kadar sürdürülmektedir. Son birkaç ay içinde kaynak ağacına kaydedilen güncellemeler / hata düzeltmeleri yapıldı ve burada geçerli ikili dosyaları alabilirsiniz (örneğin).

Ayrıca, dosyanın tamamını denetlemek yerine boyut ve tarihe göre dosya değişikliklerini algılayan fastcheck / pretendwin'i ayarlayarak performansı artırabileceğinizi de unutmayın.

Bir süre kullandım (masaüstü ve dizüstü bilgisayar arasında senkronize etmek için). Diğerlerinin yazdığı gibi, senkronizasyon sırasında oldukça dikkatli ve hiç dosya kaybetmedim. Sorun olması durumunda (zaman alıcı) bir yeniden senkronizasyon gerektirebilir, ancak her şey sonunda kendini sıralar.

Düzenli kullanımda, hem hızlı hem de güvenlidir.

Mac'lerimde Unison'u en az 8 yıldır kullandım. Unison'u hiç bozmadım ya da bir dosyayı kaybetmedim. Başlangıçta, Unison ile kaynak çatallarını anlamayan bazı sorunlar yaşadım, bu da senkronizasyon başarısızlıklarına yol açtı.

Mac B&W G3'ümdeki Finder'ın, her megabaytta bir veya iki bayt rastgele değiştirerek kopyalanan dosyaları sessizce bozduğunu anladıktan sonra Unison kullanmaya başladım. (Rev 1 mantık kartlarında Firewire ile ilgili bir donanım sorunu nedeniyle.) Bu sorundan beri, yedek kopyaları karşılaştırma konusunda gerçekten, gerçekten paranoyak oldum ve Unison bunu benim için iyi yapıyor.

Bunlar Unison'un başarısızlıkları:

Windows'ta iki Cygwin dizinini senkronize ederken, Cygwin'in kullandığı sembolik bağlantıları bozar ve içeriği bozar:

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

Boyut değişikliği ve izinleri fark ettiniz mi? Hedef makinede, komutu çalıştırmaya çalışırken, başarısız olur:

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

Sembolik bağlantıları doğru şekilde kopyalamak için rsync kullanmalıyım.

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

Bir başka başarısızlık Unison varsayılan olarak değiştirilen süreleri DEĞİLDİR (ancak -timesunison senkronizasyon dosya değiştirme sürelerini senkronize etme seçeneğini kullanmak mümkündür )! Senkronize ederseniz, değiştirilen süreler hedefte dosya oluşturma süresine ayarlanır:

$ 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

Teorik olarak, potansiyel olarak veri kaybedebilirsiniz

1. 2 senkronize dosya konumuna sahip, Konum1, Konum2,
2. 2. konumda bir dosyanın senkronize edilmiş bir kopyasını değiştirmek,
3. 1. konum ile 3. konum arasında Unison ile senkronize edildi,
4. Unison nedeniyle 3. hedefte daha yeni bir değiştirilme tarihi olan bir dosya oluşturdu,
5. rsync veya SyncToy gibi farklı bir senkronizasyon aracı kullandık,
6. daha sonra 3. hedefi yine 1. kaynaktan daha sonra değiştirilen 2. konumla senkronize etti, ancak 3. hedef dosya oluşturma süresinden önce,
7. Diğer senkronizasyon aracı 3. konum zamanının daha yeni olduğunu fark edecek ve 2. konumdaki değişikliklerin üzerine yazacak,
8. Böylece veri kaybı olur.