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

Question

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

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

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

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

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

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

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

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

Answer 1

У меня был успех с ext4 через luks над sshfs . Я обнаружил, что запуск unison на монтировании этого типа намного, намного быстрее, чем через encfs через sshfs . Поэтому должно быть так, что эти тысячи структур stat() как-то связаны вместе в ext4 fs, так что им требуется меньше сетевого трафика во время синхронизации.

Немного раздражает то, что файловой системе ext4 нужен идентификатор пользователя для каждого файла, и этот идентификатор пользователя используется для вычисления прав доступа, когда ext4 fs монтируется локально на клиенте. В моем случае я решил изменить свой локальный идентификатор пользователя на конкретный номер на всех клиентах, с которых я синхронизируюсь. Альтернативой может быть сохранение файлов в файлах ext4 с uid 0, а затем использование bindfs для монтирования файловых систем ext4 с некорневым uid.