Quelle est la fiabilité d'Unison? Cela a-t-il déjà ruiné vos données? [fermé]

Je m'intéresse aux faits, lorsque l'utilisation de l'unisson ( http://www.cis.upenn.edu/~bcpierce/unison/ ) a ruiné vos données? Je veux en savoir plus sur sa fiabilité.

J'ai arrêté d'utiliser Unison car:

• il ne peut pas gérer correctement les caractères spéciaux et internationaux dans un nom de fichier. Je pense que ces fichiers n'ont pas été copiés (mais je n'en suis pas sûr).
• Sur un Mac, l'interface graphique (facultative) s'est souvent bloquée, j'ai donc dû redémarrer le processus de synchronisation après chaque crash.

J'utilise et désactive Unison depuis quelque chose comme 2004. En réponse à une autre question, je lui ai fait un signe de tête sur rsync comme outil de sauvegarde / synchronisation de vos données entre machines.

Pendant tout ce temps, Unison n'a jamais ruiné mes données dans le sens de déchiqueter le contenu des fichiers. Il a toutefois montré une certaine sensibilité aux conditions de périphérie telles que les fichiers en cours d'utilisation, les autorisations ou les problèmes multiplateformes. Vous devrez être prudent dans votre recherche si vous rencontrez des erreurs lors de la synchronisation de vos fichiers avec Unison. Sauvegardez vos journaux.

Il y a quelques semaines, j'ai décidé d'arrêter d'utiliser Unison et je suis retourné à rsync. Raisons principales:

• Unison n'est plus développé activement, tandis que rsync est
• Unison est plus lent que rsync en utilisation réelle, où j'ai des centaines de milliers de fichiers totalisant plus de 150 Go dans mon répertoire personnel; la sauvegarde d'une journée de travail sur une clé USB prend environ 10 minutes avec Unison mais seulement 1-2 minutes avec la dernière rsync.
• Les bases de données d'Unison doivent être reconstruites tous les deux mois en raison des cas marginaux susmentionnés, tels que la déconnexion soudaine du système de fichiers de réception; lorsqu'ils sont corrompus, vos fichiers ne seront PAS détruits mais ils peuvent rester non synchronisés et vous donneront des erreurs étranges. Cette reconstruction de base de données, en particulier avec des volumes distants, peut prendre des heures, voire des jours.

Je ne l'utilise pas depuis aussi longtemps que ttarchala, mais cela fonctionne bien pour les petits ensembles de fichiers et je n'ai perdu aucune donnée.

Bien qu'il ne soit pas en cours de développement actif, il est maintenu dans une certaine mesure. Il y a eu des mises à jour / corrections de bogues validées dans l'arborescence source au cours des derniers mois, et vous pouvez obtenir les binaires actuels ici (par exemple).

Notez également que vous pouvez améliorer les performances en définissant fastcheck / pretendwin qui détecte les modifications de fichier par taille et date, plutôt que de vérifier la totalité du fichier.

Je l'ai utilisé pendant un bon moment (pour synchroniser entre ordinateur de bureau et ordinateur portable). Comme les autres l'écrivent, il est très prudent lors de la synchronisation et je n'ai jamais perdu de fichiers. En cas de problème, cela peut nécessiter une resynchronisation (longue), mais tout se résout finalement.

En fonctionnement régulier, il est à la fois rapide et sécurisé.

J'utilise Unison sur mes Mac depuis au moins 8 ans. Je n'ai jamais eu corrompu Unison ou perdu un fichier. Au début, j'ai eu quelques problèmes avec Unison qui ne comprenait pas les fourches de ressources, ce qui a entraîné des échecs de synchronisation.

J'ai commencé à utiliser Unison après avoir compris que Finder sur mon Mac B&W G3 corrompait silencieusement les fichiers copiés en changeant au hasard un octet ou deux chaque mégaoctet. (Causé par un problème matériel avec Firewire sur les cartes logiques Rev 1.) Depuis ce problème, je suis vraiment, vraiment paranoïaque à propos de la comparaison des copies de sauvegarde, et Unison le fait bien pour moi.

Ce sont les échecs d'Unison:

Lors de la synchronisation de deux répertoires Cygwin sous Windows, il corrompt les liens symboliques utilisés par Cygwin et corrompt le contenu:

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

Remarquez le changement de taille et les autorisations? Sur la machine de destination, lors de la tentative d'exécution de la commande, elle échoue:

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

Je dois utiliser rsync pour copier correctement les liens symboliques.

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

Un autre échec est que Unison ne conserve pas les heures modifiées par défaut (il est cependant possible d'utiliser l' -timesoption pour faire synchroniser les heures de modification des fichiers à l'unisson)! Si vous synchronisez, les heures modifiées sont définies sur l'heure de création du fichier sur la destination:

$ 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

En théorie, vous pourriez potentiellement perdre des données si vous

1. Avoir 2 emplacements de fichiers synchronisés, Location1, Location2,
2. Modifier une copie synchronisée d'un fichier au 2ème emplacement,
3. Synchronisé avec Unison entre le 1er emplacement et un 3e emplacement,
4. créé un fichier à la 3e destination avec une date de modification plus récente en raison de l'unisson,
5. utilisé un autre outil de synchronisation tel que rsync ou SyncToy,
6. puis à nouveau synchronisé la 3e destination avec le 2e emplacement, qui a en fait été modifié plus tard que la 1ère source, mais avant l'heure de création du 3ème destination,
7. L'autre outil de synchronisation remarquera que l'heure du 3e emplacement est plus récente et écrasera les modifications apportées au 2e emplacement,
8. Perdant ainsi des données.