- 在正在备份的机器上：
在生产 Linux VM 上创建具有要备份内容的有限权限帐户。- 帐户将有权访问单个直接 [例如 /home/backup]，并且仅允许通过密钥进行 ssh。
- 帐户将被 chroot 到 /home/backup 目录。
- 账户将被限制 shell [ rssh ]
- 帐户将通过 AllowUsers backup@[备份虚拟机 ip 地址] 进行限制
- 在正在备份的机器上
root生成备份 时，将它们放在有限权限帐户可以访问的地方，并将chown它们放在有限权限帐户中。- 根帐户将有权访问加密密码/密钥。此密钥的副本将存在于开发人员/系统管理员计算机和/或 USB 密钥驱动器上。假设系统管理员/开发计算机被攻陷 = 被搞砸了。他们将能够记录密钥密码的输入并获取密钥的副本。
- Root 帐户生成备份 -> 压缩备份 -> 加密备份 -> 将备份移动到 /home/backup/current.tar.bz2 -> chown backup:backup
- 在收集备份的机器上
所有生产机器上都有备份账户的 SSH 密钥，然后/home/backup/current.zip从源机器复制到本地机器。- 没有加密/解密信息。
- 备份虚拟机访问仅限于其机器上的 sysadmin/dev ssh 密钥。
要备份的信息不是特别敏感的信息（公共/私人对话、要备份的服务的账户密码等）。不是任何类似信用卡、健康信息等的信息
我相信其余的备份过程（恢复、备份频率等）能够令我满意。
答案1
你应该使用公钥在这种情况下，当您的异地备份由第三方存储时，需要加密。
这样，被备份的机器就只有自己的公钥，因此只能创建备份。你存储私人的密钥脱机，并且仅用于恢复。
Bareos 等备份解决方案已经支持公钥加密，或者您可以相当容易地将其集成到使用 GPG 的现有设置中。
答案2
您的设置看起来非常可靠 - 尽管我确实是备份软件进行备份的坚定支持者。
我将根据 Bacula（和/或 BaReOS）为您提供以下概述：
在正在备份的机器上
安装 Bacula 代理，并配置特定于计算机的加密证书。
（解密密钥不需要存储在这些计算机上，因为它仅在恢复时才需要。）
您的备份将以与任何“正常”Bacula 备份相同的方式启动，并使用指定的证书进行加密。关于 Bacula 导演（请求备份的机器）
根据您的组织配置适当的备份计划（完整和增量）。在 Bacula 存储服务器上（写入备份的机器）
您不需要做任何特别的事情，但通常最好将存储服务器放在异地，或者使用rsync或等效方式同步异地备份。
这实际上等同于您上面的概述，只是不需要 SSH 访问和 cron 作业。此外，您还可以获得其他一些好处：
攻击者很难破坏备份。
访问正在备份的其中一台机器不允许您删除/覆盖备份 - 这一切都由 Director 控制。攻击者很难破坏正在备份的机器。
由于解密密钥离线存储，攻击者无法将数据恢复到正在备份的机器上（备份不会解密），因此即使他们有权访问 Director，他们也无法命令恢复。您的备份非常安全。
由于它们在离开源计算机之前已加密（并且仅在恢复期间在目标计算机上解密），因此获取您备份副本的人将获得无法使用的（加密）数据。如果您的数据敏感，这更令人担忧，但这也意味着您的备份无法被篡改（因此如果有人访问存储服务器，则无法将其用于将损坏/恶意数据恢复到您的服务器）。您正在使用“真正的备份软件”
当您需要“恢复我周四处理的那个文档”时这很有用 - 您可以恢复该文件而不必提取（或复制）整个档案。
缺点是什么？备份代理需要以 root 身份运行（或者至少以可以读取您要备份的所有数据的用户身份运行）。代理非常安全，但总有可能存在未发现的漏洞，从而可能成为攻击途径。不过，只要
及时打上补丁，您就应该没问题。