Transferência Synology NAS para Mac: o rsync cria pastas idênticas no mesmo disco (NAS rsync e Mac rsync produzem hexdumps diferentes)

Question

Resumo:

Eu uso a seguinte configuração para fazer backup de dados em um Synology NAS para um disco remoto via rsync.

• Primeiro backup local: rsync inicializado no Synology NAS para o disco (montado no NAS).
• Backups remotos futuros: rsync inicializado em um Mac no disco, agora montado no Mac em um local remoto.

Problema: recebo duas cópias de todos os dados (arquivos ou pastas) com caracteres especiais.

Pergunta: Existe uma maneira de usar o mesmo processo básico (primeiro backup local via NAS, descanso via Mac, usando rsync) sem o problema acima?

Situação: O que se segue abaixo é bastante longo e inclui duas edições, mas embora o problema seja analisado mais detalhadamente, ainda não foi resolvido.

Descrição completa:

Eu tenho uma configuração que já existe há muito tempo. Na verdade, desde que consegui resolver um problema inicial de caracteres especiais (detalhado aqui), após o qual uso a opção "--iconv=utf-8-mac,utf-8" para o rsync no mac. A configuração é esta:

Local 1: Synology NAS

Localização 2 (em uma galáxia muito distante): Mac com disco externo (Mac OS Journaled)

Tarefa: trabalho rsync no Mac puxando pastas para o disco externo (local 2) do NAS (local 1).

Agora pretendo configurar um novo disco (também Mac OS Journaled) no local 2. Como há cerca de 2 TB de dados para transferir, fiz o seguinte:

1. Localização 1: Conectei o novo disco ao NAS graças às maravilhas do USB.

2. Local 1: enviou os dados para o novo disco com um trabalho rsync no NAS

3. Viajei para a galáxia distante que aqui chamamos de Localização 2

4. Local 2: inicializou um trabalho pull rsync limitado do Mac, agora com o novo disco conectado.

Problema: Por algum motivo, a etapa (4) não terminou em 2 segundos sem nenhuma alteração, mas começou a reclamar que “o arquivo desapareceu:…[local do arquivo especificado]” para uma grande quantidade de arquivos. Depois começou a copiar pastas e arquivos para o disco — mesmo que eles já estivessem lá! 70 GB depois, pelo que pude perceber, ele fez uma cópia completamente redundante de todas as pastas que tinham caracteres especiais em seus nomes (e uma cópia redundante de todos os arquivos com caracteres especiais em seus nomes em pastas que não tinham caracteres especiais em seus nomes). o nome deles). Por exemplo:

drwxrwxrwx   5 _unknown  _unknown      170 Aug  7  2013 Pippi Långstrump-Pippi i Söderhavet
drwxrwxrwx   5 _unknown  _unknown      170 Aug  7  2013 Pippi Långstrump-Pippi i Söderhavet

Essas duas pastas parecem completamente idênticas, mas estão listadas lado a lado como duas pastas distintas. Se eu usar a GUI do Mac, posso entrar em cada uma delas e ver que elas contêm as mesmas três faixas (qualitativamente idênticas) (nem sei como separá-las usando a linha de comando, mas com a GUI posso ver visualmente isso Eu 'entro' em pastas diferentes). E não são meramente virtuais, já que o tamanho total do subconjunto de dados passou de 64 GB para 82 GB.

O que aconteceu? Para meus olhos destreinados, parece que o processo rsync inicializado no Mac não consegue 'ver' que os arquivos de origem no NAS já estão presentes no disco de destino e colocá-los lá novamente. Quando o terminal mac exibe os nomes dos arquivos e pastas, ele evidentemente usa os mesmos símbolos, mas ainda deve interpretá-los como diferentes 'embaixo', caso contrário o sistema de arquivos não permitiria isso.

Agora, isso não é tudo. Quando tento fazer com que o sistema mantenha apenas uma das pastas/arquivos de caracteres especiais com a opção --delete, tudo simplesmente acontece. As pastas são realmente excluídas, mas as novas são cópias e, no final, ainda estou com duplicatas e 82 GB no subconjunto em vez de 64 GB como resultado.

O que está acontecendo e o que posso fazer a respeito?

EDITAR 11 de setembro: O sábio Tomáš Pospíšek (bem familiarizado com caracteres especiais, presumo;) me aconselhou a ir “nos bastidores”, e então usei seu comando (em Ronja em vez de Pippi, já que eu tinha muitas pastas Pippi diferentes). Um simples “ls -l” me deu:

drwxrwxrwx   2 _unknown  _unknown        68 Aug  7  2013 Ronja Rövardotter
drwxrwxrwx   2 _unknown  _unknown        68 Aug  7  2013 Ronja Rövardotter

enquanto

sh-3.2# ls -l Ronja* | hexdump -C

resultou em:

00000000  52 6f 6e 6a 61 20 52 6f  cc 88 76 61 72 64 6f 74  |Ronja Ro..vardot|
00000010  74 65 72 3a 0a 0a 52 6f  6e 6a 61 20 52 c3 b6 76  |ter:..Ronja R..v|
00000020  61 72 64 6f 74 74 65 72  3a 0a                    |ardotter:.|

ou, se eu resolver um pouco:

52 6f 6e 6a 61 20 52 6f cc 88 76 61 72 64 6f 74 74 65 72 3a 0a 0a |Ronja Ro..vardotter:..
52 6f 6e 6a 61 20 52 c3 b6 76 61 72 64 6f 74 74 65 72 3a 0a       |Ronja R..vardotter:.

Em outras palavras, eles não são idênticos, apenas apresentados superficialmente como tais.

Obrigado por isso. Mas o que devo fazer sobre isso? Existe uma maneira de formatar o disco (por exemplo, Journaled com distinção entre maiúsculas e minúsculas) para que tanto o NAS quanto o meu Mac possam gravar no disco corretamente? Ou não há como evitar, ou seja, conectar o disco a um Mac local (local 1) e fazer o primeiro backup via ethernet? Isso levaria uma eternidade em comparação com a conexão USB 3, mas pelo menos o backup seria "interpretado pelo Mac" tanto local quanto remotamente. O que você sugere?

EDITAR 14 de setembro: O prestativo Tomáš sugeriu ainda (por meio do comentário abaixo) que eu deveria tentar sincronizar novamente um único arquivo com caracteres especiais no nome, para ver o que acontece então (e ele sugere uma solução alternativa). Infelizmente, o que acontece é que fico com dois arquivos no disco de destino com nomes aparentemente idênticos, mas, ao fazer hexdumping, você pode ver que eles são codificados de forma diferente. Meu problema então foi que não consegui excluir os dois arquivos corretamente. Ou seja, quando eu os excluí com “rm” para que nenhum arquivo ficasse visível (“ls -l” não os listou), ainda pude ver os arquivos (ou pastas; o mesmo aí) no Mac Finder. Isso aconteceu mesmo se eu reiniciasse o sistema, etc., então, de alguma forma, as informações do arquivo estavam lá para serem exibidas pelo Mac Finder, mesmo que elas não aparecessem em uma lista de comandos.

Nesse ponto, meio que joguei a toalha e optei pela solução covarde de simplesmente apagar o disco e voltar a extrair os dados do site inicial (local 1) por meio de um mac e o mesmo comando rsync. Isso levou muito mais tempo, em termos de transferência, mas “resolveu” diretamente o problema. Agora tenho tudo configurado, funcionando como um relógio.

Ainda assim, o problema como tal ainda não está resolvido. Ou seja, gostaria de saber como:

• enviar dados para um disco externo (Mac OS Journaled, montado no NAS) a partir de um Synology NAS com um processo rsync inicializado no NAS
• Faça backup desses dados em um site externo usando um comando rsync em um Mac
  no qual o disco está montado.

Se alguém souber, responda à pergunta e eu o marcarei como o solucionador de problemas (e um herói) imediatamente!

NOTA: Esta questão agora é como um pequeno conto “o que eu fiz no verão passado”, então reescrevi o resumo acima para que possíveis solucionadores de problemas tenham a oportunidade de saber qual é a questão central.