Синхронизация с удаленным зашифрованным хранилищем
Я пытаюсь синхронизировать дерево папок между несколькими компьютерами. В настоящее время я использую 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
скажем, ext4
над dm-crypt
раздел хранится внутри большого файла на сервере и монтируется на клиенте через losetup
над sshfs
? Будет ли ext4
файловая система хранит метаданные файла вместе, чтобы они передавались только при отправке нескольких блоков? Было бы sshfs
знаете, отправлять только несколько блоков во время обновления, вместо перезаписи всего зашифрованного файла?
1 ответ
Я имел успех с ext4
над luks
над sshfs
, Я считаю, что работает unison
на горе такого типа намного, намного быстрее чем над encfs
над sshfs
, Так должно быть, что эти тысячи stat()
структуры как-то связаны вместе в ext4
fs, так что они требуют меньше сетевого трафика во время синхронизации.
Немного раздражает то, что ext4
файловой системе нужен идентификатор пользователя для каждого файла, и этот идентификатор пользователя используется для вычисления прав доступа, когда ext4
ФС монтируется локально на клиенте. В моем случае я решил изменить свой локальный идентификатор пользователя на определенный номер на всех клиентах, с которых я синхронизируюсь. Альтернативой было бы хранить файлы в ext4
fs с uid 0, затем используйте bindfs
смонтировать ext4
фс с некорневым uid.