Стратегия резервного копирования eCryptfs

По-видимому, пароль пользователя, не присутствующего, абсолютно необходим для дешифрования. Следовательно Ваша единственная опция состоит в том, чтобы искать решение, которое создает резервную копию зашифрованных файлов, и используйте это для обоих пользователей. Это имеет преимущество, что по-видимому конфиденциальная информация также шифруется на резервных носителях - который может быть важным, если Вы передаете его вокруг места (для прилегающего объекта).

Я не знаком с ecryptfs, но он кажется, что файлы являются стандартными файлами при просмотре базовой файловой системой (в предположении ext3).

Так, 1) 'исходный' каталог, который содержит зашифрованные данные на самом деле где-то в другом месте, и затем смонтированный так, чтобы незашифрованная версия появилась в местоположении, которое Вы дали - в этом случае Вы могли просто получить зашифрованные данные от исходного местоположения. Часть документации человечности предполагает, что незашифрованные частные файлы - то, что Вы видите в/home/.ecryptfs/A/Private, и их зашифрованные дубликаты на самом деле присутствуют в/home/.ecryptfs/A/.Private. Если так, и Вы используете rsync, у Вас будет зашифрованный.Private каталог для обоих пользователей так или иначе, и для ясности Вы могли использовать исключить опции rsync предотвратить резервное копирование незашифрованного каталога Private.

2) С другой стороны, Вы подвергаете сомнению, читает немного как вся папка (или B) шифруется, и возможно unecrypted и зашифрованные версии монтируются в том же местоположении. Если так, могли Вам попробовать что-то нравится, монтируют, что-o ro - связывают/home/.ecryptfs/A/mnt/encryptedA, который предоставил бы другую точку доступа каталогу A через/mnt/encryptedA. Если бы это было сделано то перед пользовательским входом в систему затем возможно Вы сохранили бы доступ к зашифрованной версии через/mnt/encryptedA даже, в то время как/home/.ecryptda/A предоставляет доступ к незашифрованной версии. Я не знаю, будет ли это работать - необходимо было бы просто попробовать его и видеть.

Почему не "только" синхронизируются, их файлы на выходят из системы к доле. этот путь вместо того, чтобы иметь необходимость вручную запустить Ваше задание, которое это "автоматически выполнит" (крон, событие действия...) копирует незашифрованные файлы в долю (который может или не может быть зашифрован), и затем зашифруйте его собственный FS снова перед тем, чтобы выходить из системы.

Я вижу это не быть окончательным решением, но это означает, что user'll всегда имеют актуальное резервное копирование, так как его файлы синхронизируются на сервере. И если пользователь B не вошел в систему некоторое время, то нет никакого вреда в не резервном копировании его, потому что его файлы не будут изменяться для начала.

Это - что-то вроде того, к чему Вашему поиску, или Вы стремитесь больше.... оптимизированный, все в одном решении?

Идеально, хотя зажимание партии по ЗАШИФРОВАННОЙ передаче для резервного копирования было бы лучше с тех пор прямо сейчас, Вы оставляете свое ценное право данных открытым для человека в середине и / или осуществляющие сниффинг попытки.