¿Qué tan confiable es Unison? ¿Alguna vez arruinó sus datos? [cerrado]

Estoy interesado en los hechos, cuando uso unísono ( http://www.cis.upenn.edu/~bcpierce/unison/ ) arruinó sus datos? Quiero saber sobre su fiabilidad.

Dejé de usar Unison porque:

• no puede manejar caracteres especiales e internacionales en un nombre de archivo correctamente. Creo que estos archivos no se copiaron (pero no estoy seguro de eso).
• En una Mac, la GUI (opcional) se bloqueaba con frecuencia, por lo que tuve que reiniciar el proceso de sincronización después de cada bloqueo.

He estado usando Unison de forma intermitente desde algo así como 2004. En una respuesta a otra pregunta, le di un guiño a rsync como una herramienta para realizar copias de seguridad / sincronizar sus datos entre máquinas.

En todo este tiempo, Unison nunca arruinó mis datos en el sentido de triturar el contenido del archivo. Sin embargo, mostró cierta sensibilidad a las condiciones de borde, como los archivos en uso, los permisos o los problemas multiplataforma. Deberá tener cuidado al investigar esto si encuentra algún error al sincronizar sus archivos con Unison. Guarda tus registros.

Hace un par de semanas decidí dejar de usar Unison y volví a rsync. Razones principales:

• Unison ya no se desarrolla activamente, mientras que rsync es
• Unison es más lento que rsync en el uso en el mundo real, donde tengo cientos de miles de archivos con un total de más de 150 GB en mi directorio de inicio; La copia de seguridad de un día de trabajo en una unidad USB tarda unos 10 minutos con Unison, pero solo 1-2 minutos con la última rsync.
• Las bases de datos de Unison deben reconstruirse cada dos meses debido a los casos límite mencionados anteriormente, como la desconexión repentina del sistema de archivos de recepción; cuando están dañados, sus archivos NO serán destruidos, pero pueden permanecer sin sincronizar y le darán errores extraños. Esta reconstrucción de la base de datos, especialmente con volúmenes remotos, puede llevar horas o incluso días.

No lo he usado durante tanto tiempo como ttarchala, pero funciona muy bien para conjuntos de archivos más pequeños y no he perdido ningún dato.

Si bien no está en desarrollo activo, se mantiene hasta cierto punto. Se han realizado actualizaciones / correcciones de errores en el árbol de origen en los últimos meses, y puede obtener los binarios actuales aquí (por ejemplo).

También tenga en cuenta que puede mejorar el rendimiento configurando fastcheck / pretendwin que detecta los cambios de archivo por tamaño y fecha, en lugar de sumar la suma de verificación de todo el archivo.

Lo usé durante bastante tiempo (para sincronizar entre computadora de escritorio y computadora portátil). Como escriben los demás, es bastante cuidadoso durante la sincronización, y nunca perdí ningún archivo. En caso de problemas, puede requerir una resincronización (que requiere mucho tiempo), pero al final todo se soluciona.

En funcionamiento regular, es rápido y seguro.

He usado Unison en mis Mac durante al menos 8 años. Nunca tuve unison corrupto o perder un archivo. Al principio, tuve algunos problemas con Unison que no entendía las bifurcaciones de recursos, lo que provocó fallas en la sincronización.

Comencé a usar Unison después de descubrir que Finder en mi Mac B&W G3 estaba corrompiendo silenciosamente los archivos copiados al cambiar aleatoriamente uno o dos bytes por megabyte. (Causado por un problema de hardware con Firewire en las placas lógicas Rev. 1). Desde ese problema, he estado realmente, muy paranoico sobre comparar copias de seguridad, y Unison lo hace bien por mí.

Estas son las fallas de Unison:

Al sincronizar dos directorios de Cygwin en Windows, corrompe los enlaces simbólicos que usa Cygwin y corrompe el contenido:

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

¿Observe el cambio de tamaño y los permisos? En la máquina de destino, cuando intenta ejecutar el comando, falla:

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

Tengo que usar rsync para copiar los enlaces simbólicos correctamente.

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

Otro error es que Unison NO mantiene los tiempos modificados de forma predeterminada (sin embargo, es posible utilizar la -timesopción para sincronizar los tiempos de modificación del archivo al unísono). Si sincroniza, los tiempos modificados se establecen en el tiempo de creación del archivo en el destino:

$ 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

Teóricamente, podría perder datos potencialmente si

1. Tener 2 ubicaciones de archivos sincronizados, Ubicación1, Ubicación2,
2. Modificar una copia sincronizada de un archivo en la segunda ubicación,
3. Sincronizado con Unison entre la primera ubicación y la tercera ubicación,
4. creó un archivo en el tercer destino con una fecha de modificación más reciente debido a Unison,
5. usó una herramienta de sincronización diferente como rsync o SyncToy,
6. luego sincronizó el tercer destino nuevamente con la segunda ubicación, que en realidad se modificó más tarde que la primera fuente, pero antes del tercer tiempo de creación del archivo de destino,
7. La otra herramienta de sincronización notará que la hora de la tercera ubicación es más nueva y sobrescribirá los cambios en la segunda ubicación,
8. Por lo tanto, perder datos.