Quão confiável é o Unison? Alguma vez isso arruinou seus dados? [fechadas]

Question

Estou interessado em fatos, quando usar o uníssono ( link ) arruinou seus dados? Eu quero saber mais sobre sua confiabilidade.

    

Answer 1

Eu parei de usar o Unison porque:

• ele não pode manipular corretamente caracteres especiais e internacionais em um nome de arquivo. Eu acho que esses arquivos não foram copiados (mas não tenho certeza disso).
• Em um Mac, a GUI (opcional) falhava com frequência, então tive que reiniciar o processo de sincronização após cada falha.

Answer 2

Eu uso o Unison de vez em quando desde algo como 2004. Em uma resposta a outra pergunta, dei uma olhada no rsync como uma ferramenta para fazer backup / sincronizar seus dados entre máquinas.

Em todo esse tempo, Unison nunca arruinou meus dados no sentido de fragmentar o conteúdo dos arquivos. Ele exibiu, no entanto, alguma sensibilidade às condições de borda, como arquivos em uso, permissões ou problemas de plataforma cruzada. Você precisará ter cuidado ao pesquisar isso se encontrar algum erro ao sincronizar seus arquivos com o Unison. Salve seus registros.

Algumas semanas atrás, decidi parar de usar o Unison e voltei ao rsync. Razões principais:

• O Unison não é mais desenvolvido ativamente, enquanto o rsync é
• O Unison é mais lento que o rsync em uso no mundo real, no qual tenho centenas de milhares de arquivos, totalizando mais de 150 GB no meu diretório pessoal; o backup de um dia de trabalho para uma unidade USB demora cerca de 10 minutos com o Unison, mas apenas 1-2 minutos com o rsync mais recente.
• Os bancos de dados da Unison precisam ser reconstruídos a cada dois meses devido aos casos de borda mencionados anteriormente, como a desconexão súbita do recebimento do sistema de arquivos; Quando eles estão corrompidos, seus arquivos não serão destruídos, mas eles podem permanecer não sincronizados e lhe darão erros estranhos. Essa reconstrução do banco de dados, especialmente com volumes remotos, pode levar horas ou até dias.

Answer 3

Eu não o uso desde o ttarchala, mas funciona muito bem para conjuntos de arquivos menores e não perdi nenhum dado.

Embora não esteja em desenvolvimento ativo, está sendo mantido em algum grau. Houve atualizações / correções de bugs comprometidas com a árvore fonte nos últimos meses, e você pode obter os binários atuais aqui (por exemplo).

Observe também que você pode melhorar o desempenho configurando o fastcheck / pretendwin, que detecta alterações de arquivo por tamanho & data, em vez de verificar o arquivo inteiro.

    

Answer 4

Eu usei por um bom tempo (para sincronizar entre desktop e laptop). Como os outros escrevem, é bastante cuidadoso durante a sincronização e nunca perdi nenhum arquivo. Em caso de problemas, pode exigir uma (demorada) ressinch, mas tudo se resolve no final.

Em operação regular, é rápido e seguro.

    

Answer 5

Eu usei o Unison em meus Macs por pelo menos 8 anos. Eu nunca tive uníssono corrupto ou perdi um arquivo. No início, tive alguns problemas com o Unison, não entendendo os recursos de garfos, o que levou a falhas na sincronização.

Comecei a usar o Unison depois que descobri que o Finder no meu Mac B & W G3 estava corrompendo silenciosamente os arquivos copiados, alterando aleatoriamente um byte ou dois a cada megabyte. (Causado por um problema de hardware com as placas lógicas Firewire on Rev 1.) Desde esse problema, tenho sido muito, muito paranóico em comparar cópias de backup, e o Unison faz isso bem para mim.

    

Answer 6

Estas são as falhas do Unison:

Ao sincronizar dois diretórios do Cygwin no Windows, ele corrompe os links simbólicos que o Cygwin usa e corrompe o conteúdo:

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 a mudança no tamanho e as permissões? Na máquina de destino, ao tentar executar o comando, ele falha:

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

Eu tenho que usar o rsync para copiar os links simbólicos corretamente.

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

Outra falha é que o Unison NÃO mantém os tempos modificados por padrão (no entanto, é possível usar a opção -times para sincronizar sincronicamente os tempos de modificação do arquivo)! Se você sincronizar, os horários modificados serão definidos para o horário de criação do arquivo no 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

Teoricamente, você poderia perder dados se você

1. Tem dois locais de arquivos sincronizados, Location1, Location2,
2. Modifique uma cópia sincronizada de um arquivo na segunda localização,
3. Sincronizado com o Unison entre a primeira localização e a terceira localização,
4. criou um arquivo no terceiro destino com uma data de modificação mais recente devido ao Unison,
5. usou uma ferramenta de sincronização diferente, como rsync ou SyncToy,
6. em seguida, sincronizou o terceiro destino novamente com o segundo local, que na verdade foi modificado depois da primeira origem, mas antes do terceiro horário de criação do arquivo de destino,
7. A outra ferramenta de sincronização notará que a 3ª hora da localização é mais recente e substitui as alterações na 2ª localização,
8. Por meio da perda de dados.