Синхронизация с удаленным зашифрованным хранилищем

959
Matei David

Я пытаюсь синхронизировать дерево папок между несколькими компьютерами. В настоящее время я использую unisonтопологию типа «звезда» с центральным удаленным сервером. Я хочу, чтобы данные на сервере были зашифрованы, поэтому на сервере unisonдерево (включая .unisonпапку) хранится внутри encfsдерева. Для выполнения синхронизации каждый клиент:

  • монтирует хранилище сервера с sshfs
  • монтирует encfsхранилище sshfsлокально
  • выполняет unisonмежду локальной копией документов и смонтированной.

Установка имеет много преимуществ:

  • инструменты с открытым исходным кодом
  • скриптовое решение для командной строки
  • безопасное общение через ssh
  • конфиденциальность от сервера, потому что encfsдерево папок там никогда не расшифровывается
  • способность различать модификации во время синхронизации, потому что unisonработает над открытым текстом

Одна вещь, которая не работает так хорошо, это скорость синхронизации. Поскольку encfsпапка с сервера монтируется на клиенте, каждый stat()вызов клиента должен быть перенаправлен sshна сервер. Дерево документов уже содержит тысячи файлов, и unisonсинхронизация должна выполняться как минимум по одному stat()вызову для каждого файла (чтобы исключить изменения в состоянии, хранящемся в .unisonпапке). Есть ли более быстрая альтернатива, которая поддерживает преимущества, перечисленные выше?

Примечание. Если бы мне пришлось удалить последнее условие, я мог бы использовать unisonзашифрованный текст и монтировать encfsдерево только локально. Затем unisonбудет выполняться локально на клиенте и на сервере, поэтому stat()вызовы будут быстрыми. Но приятно иметь возможность посмотреть хотя бы, какие файлы синхронизируются; с unisonболее чем encfsзашифрованный текст, имена файлов будут зашифрованы.

Я понимаю, что для решения этой проблемы необходимо эффективно передавать метаданные файла с сервера на клиент во время синхронизации. Мне интересно, есть ли способ (т. Е. Комбинация существующих инструментов), например, хранить метаданные в одном месте, чтобы все они передавались путем отправки только одного (или нескольких) блока (ов) данных вместо отправки тысяч блоков (что делает переадресация stat()вызовов).

Что, если бы я должен был заменить encfs, скажем, разделом ext4over, dm-cryptхранящимся внутри большого файла на сервере и смонтированным на клиенте через losetupover sshfs? Будет ли ext4файловая система хранить метаданные файла вместе, чтобы они передавались только путем отправки нескольких блоков? sshfsЗнаете ли вы, чтобы отправить только несколько блоков во время обновления, вместо перезаписи всего зашифрованного файла?

0

1 ответ на вопрос

0
Matei David

I have had success with ext4 over luks over sshfs. I find that running unison on a mount of this type is much, much faster than over encfs over sshfs. So it must be that those thousands of stat() structs are somehow bundled together in the ext4 fs, so that they require less network traffic during a sync.

One thing which is slightly annoying is that the ext4 filesystem needs a user id for every file, and this user id is used for computing access permissions when the ext4 fs is mounted locally on a client. In my case, I chose to change my local user id to a specific number on all the clients I'm sync-ing from. The alternative would be to store the files in the ext4 fs with uid 0, then use bindfs to mount the ext4 fs with non-root uid.

Похожие вопросы