我们有一个小型networking，中间有一台Ubuntu服务器，周围有Ubuntu笔记本电脑。 笔记本都使用eCryptfs来encryption整个用户的主目录。 通常，每个笔记本有两个或更多的用户。 备份过程停留在networking中，所以我们可以将未encryption的文件传输到服务器上。 我们想要一个基于rsync的解决scheme，但也适用于其他人。
当我们尝试备份笔记本的主目录时遇到了困难，这给我们带来了很大的麻烦。 这归结于：
如果用户Alogin，则主目录被解密，并且/home/.ecryptfs/A中的encryption文件被locking而不能读取其他进程（这是一件好事）
如果用户B 没有login，他的主目录不被解密，只有/home/.ecryptfs/B的encryption文件。
我们需要有一个备份脚本，可以运行，而用户Alogin（因为她在我们的情况下手动启动），用户B可能会或可能不会login（通常不）。
现在的问题是： 我们应该备份什么？ 如果我们去encryption的数据，用户A的东西不能备份。 解密的数据意味着另一方面，用户B也必须login。 并且把这两种线索混合在一起，这是一个有趣的时刻，当谈到恢复的时候。
这个问题可能还有别的解决办法，我们错过了吗？
你确定/home/.ecryptfs/A被locking阅读吗？ 我使用ecryptfs，而我login后，可以浏览和读取/home/.ecryptfs/myusername/.Private的文件。 我只是试图进入该目录（和子目录），并打开文件（使用vim -b ），我可以读取它们的罚款。 我当然希望他们locking写作，但我不明白为什么他们会被locking阅读。 你使用的是什么操作系统版本？ （我在Ubuntu Lucid 10.04上）。 也许问一个关于你得到的错误的单独的问题，因为也许别的东西导致了这个问题。
要直接回答你的问题 – 备份/home/.ecryptfs/的内容。 这将为所有用户备份（encryption的）所有文件。
另外，如果需要的话，你应该能够解密文件。 因此，您应该将解开的密码存储在安全的地方，以防用户忘记密码，离开…要获得密码，请让用户运行
ecryptfs-unwrap-passphrase
同时login，并在某处存储结果。 它足够小，你可以把它写下来（ 双重三重检查），并将其存储在一个安全的，或有两个人保持一半，每个或这样，取决于你需要多less安全。
否则，你需要/home/.ecryptfs/*/.ecryptfs/wrapped-passphrase和用户的密码。
你还应该注意到，在同步encryption数据时，rsync将无法加速文件传输。 未encryption文件中的任何更改将完全更改encryption文件。 压缩不会真正与encryption数据一起工作。 对于你的情况，这不应该是一个大问题，同步是通过一个局域网，但是对于读这个问题的其他人可能是重要的。 虽然rsync仍然可以检查encryption文件是否保持不变，所以它不必重新传输未更改的文件。
这个问题的读者也可能对这个指南感兴趣， 由ecryptfs的维护者进行备份 。
据推测，用户不存在的口令是解密所必需的。 因此，您唯一的select是寻找备份encryption文件的解决scheme，并将其用于两个用户。 这样做的好处是，明显的机密信息也会在备份媒体上encryption – 如果您要在场外传输（非现场），这可能很重要。
我不熟悉ecryptfs，但是当底层文件系统查看文件时，这听起来像是标准文件（猜测是ext3）。
所以，1）包含encryption数据的“原始”目录实际上是在其他地方，然后安装，以便未encryption的版本出现在您提供的位置 – 在这种情况下，您可以从原始位置。 一些Ubuntu的文档build议，未encryption的私人文件是你在/home/.ecryptfs/A/Private中看到的，他们的encryption对应文件实际上存在于/home/.ecryptfs/A/.Private中。 如果是这样，并且您使用rsync，则无论如何您都将拥有两个用户的encryption.Private目录，为了清楚起见，您可以使用rsync的排除选项来防止未encryption的私人目录的备份。
2）或者，你的问题读取有点像整个文件夹A（或B）被encryption，并且可能的encryption和encryption版本安装在相同的位置。 如果是这样的话，你可以尝试一下类似于mount -o ro -bind /home/.ecryptfs/A/mnt/ encryptedA的方法，它会通过/ mnt / encryptedA提供另一个接入点到A的目录。 如果这是在用户login之前完成的，那么甚至当/home/.ecryptda/A允许访问未encryption的版本时，可能仍然通过/ mnt / encryptedA保留对encryption版本的访问。 我不知道这是否会起作用 – 你只能尝试一下，看看。
为什么不“只”同步他们的文件注销共享。 这样，而不必手动开始你的工作，它会“自动运行”（克朗，行动事件…）将未encryption的文件复制到共享（可能或不可能被encryption），然后再次encryption自己的FS出。
我可以看到这不是最终的解决scheme，但这意味着用户将始终有一个最新的备份，因为他的文件在服务器上同步。 如果用户B还没有login一段时间，那么不支持他，因为他的文件不会改变开始。
这是沿着你所寻找的东西，还是你想要更多…精简，一个一个的解决scheme？
理想的情况是，尽pipe将encryption转移为备份将会更好，因为您现在可以将重要数据留给中间人和/或嗅探企图。