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

Я пытаюсь синхронизировать дерево папок между несколькими компьютерами. В настоящее время я использую 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.

Другие вопросы по тегам