我被要求创建服务器的备份。该服务器是 Linux Ubuntu 22.04.2，其中运行核心应用程序 (nodejs) + 管理软件 (nodejs / bash 脚本) + 监控 (nodejs / net-snmp)。第二台服务器将随时准备接管（团队中的其他人仍在设计中）。
由于最终客户施加的限制，备份是一个单独的 .zip 文件，其中包括所有内容（文件和文件夹），必须通过 sftp 上传到客户网络中某处的备份服务器。
备份必须包含：配置文件/运行软件的文件夹（核心应用程序/管理/监控）+数据库转储。必须在服务器（或其孪生服务器）中恢复备份，以便在发生某些事情时使其再次运行。我猜备份过程和恢复过程将以 root 用户身份执行。
一些配置文件包含使用对称密钥算法加密的密码。这些密码与服务器必须连接的外部服务有关。密钥是一个随机字符串，称为“secret”，存储在位于所有正在运行的软件之外的特定路径中的单个文件中（例如：/etc/secret）。包含机密的文件归 root 用户所有，并且是只读的。文件机密可由多个软件访问。
我的困惑在于，包含机密的文件是否必须包含在备份中。我面临两个选择/考虑：
- 如果备份中不包含包含机密的文件，则只能在生成备份的同一台服务器上恢复备份。此外，如果服务器不再工作，则根本无法恢复备份。
- 如果备份中包含包含机密的文件，则可以将备份还原到不同的服务器，但备份包含加密密码和解密密钥。 （所以我想从网络安全的角度来看它不太安全）
有人能给我一些建议/最佳实践吗？或者给我一些文档？保存机密的文件必须包含在备份中（与所有其他文件一起）还是不包含？
谢谢！！
答案1
关于备份和恢复过程，没有其他黄金法则，但以下几点除外：
没有人真正关心备份。唯一真正重要的是能够成功恢复应用程序和数据需要的时候。
这就是人们测试备份的原因；以确保恢复过程完整，并可以在规定的时间内将系统恢复到完整功能，以确保业务连续性。
如果您无法恢复系统，或者无法在规定的时间内完成恢复，则您的备份和恢复程序已损坏。请重新考虑并重写该程序，然后重试。
如果您的恢复过程包含多个步骤，并且包括重新创建/恢复某些内容的特殊指令（例如/etc/secret当该文件（或任何其他数据）未包含在数据备份中时），这并不不正确。
如果这样的指令不会/不能成为恢复过程的一部分，那么它/etc/secret应该成为数据备份的一部分。就这么简单。
（很多人的恢复策略是恢复原始服务器的完整映像，其中包括操作系统、所有应用程序、设置和配置以及所有数据和机密。其他人则重新部署而不是恢复，并将部署空白操作系统，使用其配置管理工具重新应用所有设置，重新部署其应用程序并使用其配置管理工具中的机密对其进行配置，并且仅当应用程序无法通过复制恢复所需数据时才将备份数据恢复到应用程序。）
请注意，当需要进行真正的灾难恢复时，团队通常会感到紧张和高压，并且每个无法自动恢复的系统和应用程序、每个需要特殊手动操作的应用程序都会花费额外的时间，并且有人员犯错的风险。
当一个团队只管理一个应用程序时，这不是什么大问题，但当一个团队需要恢复几十个或更多的应用程序和系统时，往往变得无法管理。
您的备份与其中包含的数据具有同等的价值，并且备份需要与原始数据相同级别的数据保护。
如果您无法控制对备份的访问，例如当您将备份作为 zip 文件复制到第三方时，即使您这样做了，一种常见的保护机制是对备份进行加密。
（这会导致不同的问题，例如密钥管理。）
答案2
由于最终客户施加的限制，备份是一个 .zip 文件
如果这里有一条黄金法则，那就是不要使用 ZIP 文件复制到故障转移。从您的问题中无法清楚看出这是部署、备份还是故障转移复制。但是，根据实际情况，不良程度会有所不同。
实现机密管理的方法有很多种。但是，大多数实现方式已经到位（并且可能很难改变）。但是，从您的帖子中无法清楚看出这里到底发生了什么。您是否向所有客户提供相同的机密？您是否期望您的客户能够在不知道这些机密是什么的情况下使用这些机密？同样，这真的是备份吗？
最简单的解决方案是使用对称密钥加密 SECRETS 文件，并在两端保留一份副本。稍微复杂一点的解决方案是使用密钥对，并将该对拆分为源/目标。