Sincronize com armazenamento remoto criptografado

Question

Estou tentando manter uma árvore de pastas sincronizada entre vários computadores. Atualmente estou utilizando unisonem topologia estrela, com servidor remoto central. Quero que os dados do servidor sejam criptografados, portanto, no servidor, a unisonárvore (incluindo a .unisonpasta) é mantida dentro de uma encfsárvore. Para realizar uma sincronização, cada cliente:

• monta o armazenamento do servidor comsshfs
• monta o encfsarmazenamento sshfslocalmente
• executa unisonentre 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 programável
• comunicação segura atravésssh
• privacidade do servidor porque a encfsárvore de pastas nunca é descriptografada lá
• 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 encfspasta do servidor está montada no cliente, cada stat()chamada que o cliente faz deve ser encaminhada sshpara o servidor. A árvore de documentos já possui milhares de arquivos, e uma unisonsincronização deve realizar no mínimo uma stat()chamada para cada arquivo (para descartar modificações no estado armazenado na .unisonpasta). Existe uma alternativa mais rápida que mantenha as vantagens listadas acima?

Nota: Se eu removesse a última condição, poderia executar unisono texto cifrado e montar a encfsárvore apenas localmente. Em seguida, unisonseria executado localmente no cliente e no servidor, para que stat()as chamadas fossem rápidas. Mas é bom ter a opção de ver pelo menos quais arquivos estão sendo sincronizados; com texto unisoncifrado encfs, os nomes dos arquivos seriam criptografados.

Entendo que, para resolver esse problema, é necessário transferir com eficiência os metadados do arquivo do servidor para o cliente durante a sincronização. Estou me perguntando se existe uma maneira (ou seja, uma combinação de ferramentas existentes) de, por exemplo, armazenar os metadados em um só lugar, de modo que todos sejam transferidos enviando apenas um (ou alguns) bloco(s) de dados , em vez de enviar milhares de blocos (que é o que o encaminhamento stat()de chamadas está fazendo).

E se eu substituísse encfspor, digamos, uma partição ext4over dm-cryptarmazenada dentro de um arquivo grande no servidor e montada no cliente via losetupover sshfs? O ext4sistema de arquivos manteria os metadados dos arquivos juntos, para que fossem transferidos enviando apenas alguns blocos? Você saberia sshfsenviar apenas alguns blocos durante uma atualização, em vez de reescrever todo o arquivo criptografado?

Answer 1

Eu tive sucesso com ext4mais luksde sshfs. Acho que rodar unisonem uma montagem desse tipo é muito, muito mais rápido do que over encfsover sshfs. Portanto, deve ser que essas milhares de stat()estruturas estejam de alguma forma agrupadas no ext4fs, de modo que exijam menos tráfego de rede durante uma sincronização.

Uma coisa que é um pouco irritante é que o ext4sistema de arquivos precisa de um ID de usuário para cada arquivo, e esse ID de usuário é usado para calcular permissões de acesso quando o ext4fs é montado localmente em um cliente. No meu caso, optei por alterar meu ID de usuário local para um número específico emtodosos clientes dos quais estou sincronizando. A alternativa seria armazenar os arquivos no ext4fs com uid 0 e depois usar bindfspara montar o ext4fs com uid não root.