我有一些（虚拟）服务器。它们使用应用程序密钥在 Backblaze B2 上进行自我备份。
我想雇用一个人来帮助我管理这些服务器。
当该人获得服务器的 root 访问权限（我想要的）时，他也可以访问 B2 应用程序密钥。这意味着他可以删除服务器和備份。
我可以使用什么程序/设置来防范这种极端情况？我确实有离线备份，但这些是每月一次，而 B2 备份是每日一次。
答案1
在某些情况下，您只需将工作分成两个团队 - 一个团队运行/守卫服务器，另一个团队运行/守卫备份。
另一部分，在我看来更为重要：如果备份是可写的，特别是从正在备份的系统写入，那么它就不是一个好的备份。
许多工具（如 borg）中都存在系统性问题。最好是（在云世界中）将备份推送到 AWS glacier，同时使用只能创建它们的角色将它们存储到 S3 中。有删除计划，没有人需要能够“快速”地做到这一点。
另外，不要忘记还有关于这些内容的书籍。
答案2
操作方法如下：
在 Backblaze B2 上，创建一个不能删除文件的应用程序密钥：
b2 create-key --bucket MyBucket MyKeyName listBuckets,listFiles,readFiles,writeFiles设置备份，使其使用该密钥并且不会尝试删除旧备份文件。例如，在 中
duplicity，请勿使用remove-older-than、remove-all-but-n-full或remove-all-inc-of-but-n-full；在 中duply，请勿使用purge或purgeIncr。要删除旧备份，请在存储桶上设置自定义生命周期设置；例如，将以 开头的行设置为在360 天后隐藏，并在再过 360 天后删除；对于以和
duplicity-full开头的文件，依此类推。duplicity-incduplicity-new
更新：
B2 实际上不提供任何“删除文件”的功能。每次替换同一个文件时，它都会保留其历史记录，因此文件可以有“版本”——最新的版本通常是您需要的版本。B2 提供的是“隐藏”文件的功能。当您隐藏文件时，实际上是在文件历史记录中记录该文件已被“删除”，您添加的是隐藏或已删除文件的新文件版本。
除此之外，B2还提供了实际删除文件版本的功能。没有deleteFiles权限的用户实际上有隐藏文件的权限，但没有删除文件版本的权限。
在我看来，duplicity 的remove-...功能应该通过隐藏文件来实现。（然后由 bucket 的配置决定是否在一段时间后真正删除这些隐藏的文件版本。）但是 duplicity 的 B2 后端不会这样做；它所做的是真正删除文件版本。
答案3
在大多数公共云中，通过 ssh 访问服务器并不意味着您可以删除服务器。在服务器上和在云帐户中进行管理是有区别的。因此，您可以将两者分开。您还可以将权限分开很多，尤其是在 Amazon AWS 上。例如，您可以授予某人重新启动服务器的权限，但不能删除它。而且 AWS 在虚拟机上有删除保护选项。
目前的最佳做法是使用 Chef/Puppet/Salt/Ansible 等配置管理对服务器进行任何更改，而不是实际登录服务器。
此外，对于 AWS，您可以根据需要频繁地对服务器进行快照，这是备份的最有效方法。