问NextCloud加密密钥备份

EN

您的问题的回答在技术上是“是的”，但是对于备份的用例，有一些值得注意的建议需要考虑。

Nextcloud中有两种主要的服务器端加密方案。Nextcloud的最新版本默认使用“主钥匙”，它可以解密所有内容。

还有一种基于每个用户密钥的加密的替代实现，它适用于较早的设置，或手动禁用主密钥加密的人。

如果您看到这样的东西，它使用的是每个用户(旧的)样式：

下面是Nextcloud默认加密模块插件的作者之一的描述：

一般来说，Nextcloud提供给可能的设置：

1. 每个用户都有自己的私钥/公钥，管理员还可以提供每个用户需要接受的恢复密钥(Opt)。为了用occ解密用户文件，您需要用户密码，在这种情况下，用户私钥+文件密钥+数据库检查签名或恢复密钥密码(如果用户启用了恢复密钥)。在恢复密钥的情况下，您需要私有恢复密钥、恢复密钥的密码、文件密钥和数据库。这是默认设置，直到Nextcloud 13，您可以使用occ加密启用主密钥:启用-主密钥，在本例中使用安装程序2。
2. 使用主键。如果第一次使用Nextcloud 13或更高版本启用了加密，或者使用occ命令occ加密: enabled key启用了管理员，则这是默认的。在这种情况下，只有一个密钥用于所有用户的所有文件，私钥由实例密码加密。为了用occ命令解密所有文件，您只需要私有主密钥、文件密钥和数据库。

对于每个用户的加密方法(旧风格)，密钥由Nextcloud用户的登录密码保护：

Nextcloud的服务器端加密生成一个强加密密钥，该密钥由用户的密码解锁。您的用户不需要跟踪额外的密码，只需像他们通常那样登录即可。它只加密文件的内容，而不加密文件名和目录结构。

(见加密配置- Nextcloud最新管理手册最新文档)。

对于主密钥实现(这是当前的默认情况，也很可能是您将要使用的)，解密数据所需的绝对最小值是( 1)主密钥对，2)来自config.php的秘密。要遵循官方进程(即确保成功)，您还需要在文件加密后转储数据库。您可以尝试在不使用禁用文件签名检查数据库的情况下破坏加密，但是您的里程会有所不同。

因此，您可以将密钥以纯文本形式与加密备份放在类似Dropbox这样的相对安全的地方。如果没有来自config.php的秘密，攻击者就不太可能解密这些数据。这也意味着你不能。如果您拥有密钥和config.php秘密，但数据库是加密的，则您将继续试图通过禁用签名检查来破坏加密。为了顺利恢复，您需要主键、config.php文件和最新的数据库快照，所有这些都安全地保存在其他地方。

此时，我认为保留密钥和备份的方便性被否定了。另一个烦恼是恢复过程。您仍然需要生成一个新的Nextcloud实例来解密数据。然后解密的数据将是Nextcloud实例的完整备份，Nextcloud实例本身需要导入/还原到Nextcloud实例。

使用另一种方法(如这种方法)可能会在完全丢失后需要从备份恢复的情况下使您的生活更轻松：

https://kevq.uk/how-to-backup-nextcloud/

有很多类似的例子，像这样的备份张贴在网上。要点是：

• 获取完整备份，这是一个可用于在正式文档之后轻松重新生成的单个快照。
• 备份被压缩成一个文件，更易于传输和加密。
• 加密问题与Nextcloud本身是解耦的。您可以使用标准工具(如GPG )选择任何适合您需要的方法。
• 加密备份存储在支持API通过CLI (如S3或B2 )进行API交互的远程目标上。
• 整个过程只是一个脚本--使用cron自动化它，并在您需要的时候手动运行它。
• 添加另一个备份源是很低的摩擦--只需在脚本中编写另一步就可以将文件复制到其他地方。
• 要恢复，您所需要做的就是获取最新的备份，解密它(使用您选择的标准工具)，将它复制到新实例的正确位置，并遵循官方指南 (止动安装更容易)。

希望这能有所帮助！Nextcloud中的加密看起来很容易设置，但它肯定伴随着风险和权衡。使用Nextcloud加密技术丢失数据的故事并不缺乏论坛帖子和GitHub问题。

几年来，我一直使用Nextcloud作为“我不需要谷歌”的主要驱动程序。这是令人震惊的低维护，非常可靠，并奖励定制。我希望你试一试！