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

Question

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

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

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

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

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

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

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

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

Answer 1

У меня был успех с ext4over luksover sshfs. Я обнаружил, что запуск unisonна монтируемом устройстве такого типа намного, намного быстрее, чем over encfsover sshfs. Так что, должно быть, эти тысячи stat()структур каким-то образом объединены в ext4fs, так что им требуется меньше сетевого трафика во время синхронизации.

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