Estou tentando manter uma árvore de pastas sincronizada entre vários computadores. Atualmente, estou usando unison em uma topologia em estrela, com um servidor remoto central. Eu quero que os dados no servidor sejam criptografados, portanto, no servidor, a árvore unison (incluindo a pasta .unison ) é mantida dentro de uma árvore encfs . Para realizar uma sincronização, cada cliente:
- monta o armazenamento do servidor com
sshfs
- monta o
encfs storage sobre sshfs localmente
- realiza
unison entre a cópia local dos documentos e a montada.
A configuração tem muitas vantagens:
- ferramentas de código aberto
- solução de linha de comando compatível com scripts
- comunicação segura sobre
ssh
- privacidade do servidor porque a árvore de pastas
encfs nunca é descriptografada
- capacidade de diferenciar modificações durante a sincronização, porque
unison é executado em texto simples
Uma coisa que não funciona tão bem é a velocidade da sincronização. Como a pasta encfs do servidor está montada no cliente, cada stat() de chamada do cliente precisa ser encaminhada sobre ssh para o servidor. A árvore de documentos já possui milhares de arquivos, e uma unison sync deve executar no mínimo uma stat() de chamada para cada arquivo (para descartar modificações feitas no estado armazenado na pasta .unison ). Existe uma alternativa mais rápida que mantenha as vantagens listadas acima?
Observação: se eu removesse a última condição, poderia executar unison sobre cyphertext e montar apenas a árvore encfs localmente. Então, unison seria executado localmente no cliente e no servidor, portanto, stat() seria rápido. Mas é legal ter a opção de ver pelo menos quais arquivos estão sendo sincronizados; com unison over encfs cyphertext, os nomes dos arquivos seriam criptografados.
Entendo que, para resolver esse problema, é preciso transferir com eficiência os metadados do arquivo do servidor para o cliente durante a sincronização. Eu estou querendo saber se existe uma maneira (ou seja, uma combinação de ferramentas existentes) para, por exemplo, armazenar os metadados em um lugar, de modo que tudo é transferido enviando apenas um (ou alguns) bloco (s) de dados , em vez de enviar milhares de blocos (que é o encaminhamento que stat() está fazendo).
E se eu fosse substituir encfs por, digamos, uma partição ext4 over dm-crypt armazenada em um arquivo grande no servidor e montada no cliente por meio de losetup over sshfs ? O sistema de arquivos ext4 manterá os metadados do arquivo juntos, para que seja transferido enviando apenas alguns blocos? O sshfs saberia enviar apenas alguns blocos durante uma atualização, em vez de reescrever todo o arquivo criptografado?