Seberapa andalkah Unison? Apakah itu pernah merusak data Anda? [Tutup]


17

Saya tertarik pada fakta, ketika menggunakan serempak ( http://www.cis.upenn.edu/~bcpierce/unison/ ) merusak data Anda? Saya ingin mencari tahu tentang keandalannya.

Jawaban:


4

Saya berhenti menggunakan Unison karena:

  • itu tidak dapat menangani karakter khusus dan internasional dalam nama file dengan benar. Saya pikir file-file ini tidak disalin (tapi saya tidak yakin tentang itu).
  • Pada Mac, GUI (opsional) sering crash, jadi saya harus memulai kembali proses sinkronisasi setelah setiap crash.

3
Saya tidak pernah memiliki masalah dengan karakter internasional dalam nama file dengan Unison, baik pada Windows, Linux atau Mac, atau bahkan dalam sinkronisasi lintas platform melalui ssh. Sebenarnya saya mulai menggunakannya karena bisa menyinkronkan host Win dan Linux dengan benar, ketika rsync masih tidak bisa.
ttarchala

3
Ada masalah yang diketahui dengan nama file Cygwin dan non-ASCII. Ini bukan bug dengan serempak.
JeffP

Saya menggunakan Unison dengan banyak arsip Jepang. Saya tidak memiliki masalah meskipun saya memiliki masalah bertahun-tahun yang lalu. Saya menggunakan 2.48.3 yang sudah berumur beberapa tahun dan sepenuhnya mendukung Unicode.
edwinbradford

23

Saya telah menggunakan dan menonaktifkan Unison sejak sekitar 2004. Dalam jawaban untuk pertanyaan lain, saya memberikan anggukan pada rsync sebagai alat untuk mencadangkan / menyinkronkan data Anda di antara mesin.

Selama ini Unison tidak pernah merusak data saya dalam arti merobek-robek isi file. Ini ditampilkan, bagaimanapun, beberapa sensitivitas terhadap kondisi tepi seperti file yang digunakan, izin, atau masalah lintas platform. Anda harus berhati-hati untuk meneliti ini jika Anda menemukan kesalahan ketika menyinkronkan file Anda dengan Unison. Simpan log Anda.

Beberapa minggu yang lalu saya memutuskan untuk berhenti menggunakan Unison dan kembali ke rsync. Alasan utama:

  • Serentak tidak lagi dikembangkan secara aktif, sedangkan rsync adalah
  • Unison lebih lambat daripada rsync dalam penggunaan di dunia nyata, di mana saya memiliki ratusan ribu file dengan total lebih dari 150 GB di direktori rumah saya; cadangan pekerjaan sehari ke drive USB membutuhkan waktu sekitar 10 menit dengan Unison tetapi hanya 1-2 menit dengan rsync terbaru.
  • Database Unison perlu dibangun kembali setiap beberapa bulan karena kasus tepi yang disebutkan di atas, seperti pemutusan tiba-tiba dari sistem file penerima; ketika mereka rusak, file Anda TIDAK akan dihancurkan tetapi mereka mungkin tetap tidak disinkronkan dan akan memberi Anda kesalahan aneh. Bangun kembali basis data ini, terutama dengan volume jarak jauh, dapat berlangsung berjam-jam atau bahkan berhari-hari.

14
Perhatikan, btw, bahwa Unison benar-benar untuk kasus penggunaan yang berbeda dari rsync. Unison adalah untuk sinkronisasi dua arah , sedangkan rsync adalah untuk sinkronisasi satu arah. Ini membuatnya lebih mampu, tetapi juga tentu lebih kompleks daripada rsync. Jadi, alat yang tepat untuk pekerjaan itu, dll.
sleske

Bagaimana Anda "membangun kembali" database? Cukup hapus folder .unison?
russellpierce

Pertimbangkan Crashplan.com alih-alih rsync untuk cadangan.
Chloe

9

Saya belum pernah menggunakannya selama ttarchala, tetapi ini bekerja dengan baik untuk fileset yang lebih kecil dan saya belum kehilangan data apa pun.

Meskipun tidak dalam pengembangan aktif, ia dipertahankan sampai tingkat tertentu. Ada pembaruan / perbaikan bug yang dilakukan pada pohon sumber dalam beberapa bulan terakhir, dan Anda bisa mendapatkan binari saat ini di sini (misalnya).

Perhatikan juga bahwa Anda dapat meningkatkan kinerja dengan menetapkan centang cepat / pretendwin yang mendeteksi perubahan file berdasarkan ukuran & tanggal, daripada memeriksa seluruh file.


8

Saya menggunakannya cukup lama (untuk sinkronisasi antara desktop dan laptop). Seperti yang lainnya tulis, cukup hati-hati saat sinkronisasi, dan saya tidak pernah kehilangan file. Jika terjadi masalah, mungkin diperlukan sinkronisasi ulang (yang menghabiskan waktu), tetapi pada akhirnya semua akan beres sendiri.

Dalam operasi reguler, ini cepat dan aman.


7

Saya telah menggunakan Unison di Mac saya selama minimal 8 tahun. Saya tidak pernah memiliki Unison yang korup atau kehilangan file. Awalnya, saya memiliki beberapa masalah dengan Unison yang tidak memahami garpu sumber daya, yang menyebabkan kegagalan sinkronisasi.

Saya mulai menggunakan Unison setelah saya menemukan bahwa Finder di Mac B&W G3 saya secara diam-diam merusak file yang disalin dengan secara acak mengubah satu atau dua byte setiap megabyte. (Disebabkan oleh masalah perangkat keras dengan Firewire di papan logika Rev 1.) Sejak masalah itu, saya benar-benar sangat paranoid tentang membandingkan salinan cadangan, dan Unison melakukannya dengan baik untuk saya.


3

Ini adalah kegagalan Unison:

Saat menyinkronkan dua direktori Cygwin di Windows, itu merusak tautan simbolik yang digunakan Cygwin, dan merusak konten:

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

Perhatikan perubahan ukuran, dan izin? Di mesin tujuan, ketika mencoba menjalankan perintah, gagal:

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

Saya harus menggunakan rsync untuk menyalin tautan simbolik dengan benar.

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

Kegagalan lain adalah Unison TIDAK menjaga waktu yang dimodifikasi secara default (namun dimungkinkan untuk menggunakan -timesopsi untuk menyatukan waktu modifikasi file secara bersamaan)! Jika Anda menyinkronkan, waktu yang diubah diatur ke waktu pembuatan file di tujuan:

$ 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

Secara teoritis, Anda berpotensi kehilangan data jika Anda

  1. Memiliki 2 lokasi file yang disinkronkan, Location1, Location2,
  2. Ubah salinan file yang disinkronkan di lokasi kedua,
  3. Disinkronkan dengan Serentak antara lokasi 1 dan lokasi 3,
  4. membuat file di tujuan ke-3 dengan tanggal modifikasi yang lebih baru karena Unison,
  5. menggunakan alat sinkronisasi lain seperti rsync atau SyncToy,
  6. kemudian menyinkronkan tujuan ke-3 lagi dengan lokasi ke-2, yang sebenarnya dimodifikasi lebih lambat dari sumber ke-1, tetapi sebelum waktu pembuatan file tujuan ke-3,
  7. Alat sinkronisasi lain akan melihat waktu lokasi ke-3 lebih baru, dan menimpa perubahan ke lokasi ke-2,
  8. Dengan demikian kehilangan data.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.