您好，
我目前正在将我们的服务器从现有的基于 Bitnami 的部署（一个相当旧的版本）迁移到 AWS 中使用最新 Discourse 版本的官方支持的安装。这个新的安装有一个外部的 Elasticache 和 RDS 实例，并且还将使用 S3 进行备份和上传。
我有两个问题：
./launcher rebuild app 时，会使用我的新的 S3 值。如果我的假设是正确的，那么在执行恢复之前，我是否应该将旧 S3 存储桶的内容复制到新的存储桶中？
进行此类带有备份的迁移还有其他需要注意的地方吗？
提前感谢。
也许我遗漏了什么，但您为什么要创建新的存储桶？设置具有适当生命周期规则的新备份存储桶似乎可以，但如果现有的 Discourse 实例正在使用 S3 上传存储桶，您将会遇到一些问题。
我们需要新存储桶的 2 个原因：
我最担心的是第 1 点，所以只是格外小心。
您对新的上传存储桶有什么顾虑？旧的 Discourse 服务器将被设置为只读模式。计划是，一旦新服务器启动并经过验证，我们将停止旧服务器，将 DNS 更改为新服务器，然后清除 CDN（Cloudfront）中的缓存，然后向公众开放。
我没注意到你要把数据从旧的存储桶复制过来。看了看 AWS，看起来很直接。如果是我，我不会在迁移到 AWS 或其他新服务器之前乱动更改存储桶。
官方支持？？我不太确定。
强烈建议你在迁移到新服务器之前先更新 Discourse。
在旧实例上，建议你在迁移之前将 S3 配置移动到 app.yml（如果尚未在那里）。
这是你可以轻松测试而不会影响生产环境的事情。
我个人会尽一切努力避免在同一时间做这两件事。
我对这种安装方式的附加价值主张非常好奇。
从关于不受支持的安装的大量帖子来看，除非人们是为了学习/实验，否则它带来的麻烦多于益处。
从 Discourse 的角度来看，这种设置可能是不受支持的安装，但从企业 IT 组织的观点来看，RDS 和 Elasticache 可能是标准的，而 Discourse 标准安装则会显得格格不入。
谢谢你的信息。所以是熟悉度和可能现有的基础设施。
感谢您对这个问题的输入。
正如@RGJ 所提到的，我们的企业基础设施使用外部服务来处理缓存、数据库等事务，因此才有了 Elasticache 和 RDS。这意味着我们可以为这些服务提供完整的备份和冗余，也有助于安全控制。从 Discourse 的角度来看，这是官方/支持的安装——只是使用了不同的一组模板——我们使用的是 https://github.com/discourse/discourse_docker/blob/main/samples/web_only.yml（也许使用“标准”一词有点误导，抱歉）。
所以，听起来我们应该先更新现有安装的存储桶名称，然后再迁移到新服务器。将现有安装更新到最新版本是不可行的——我们之前在 Bitnami 升级中遇到过问题，因此才转向官方安装方法。
不过，我想问一下，如果我们使用现有的存储桶执行恢复，然后再更新 app.yml 以引用新的存储桶，可能会发生什么问题——难道所有 DISCOURSE_ 环境变量不会优先于数据库中的任何配置（如果适用）吗？或者还有其他可能导致问题的原因吗？
我不建议这样做
因为如果你在迁移之前就做了，万一出现问题，问题会出现在旧的 Bitnami 实例上，而不是你新安装的标准实例上。而且，除了旧版本之外，即使提到 Bitnami 这个词，你在这里（meta）得到的支持也会少得多，少得多。
是的，它们是。
啊，抱歉，理查德，我误读了你关于 S3 名称更改的要点 
所以，更好的计划是备份现有的存储桶，进行迁移，然后更改存储桶名称。
感谢您到目前为止提供的所有帮助。
是的，“B”这个词确实会让人们闭嘴，所以很高兴能远离它 
是的，并且在更改存储桶名称之前等待几天，以避免一次性做太多事情。
好的。
如果我没记错的话，还有一个问题——当我在 Discourse 容器内部从命令行运行恢复时，它会使用现有的 /var/www/discourse/config/discourse.conf 配置中关于数据库连接、Redis 连接等的详细信息，还是会用备份文件中的内容覆盖该配置？
再次感谢！
discourse.conf 是从 app.yml 生成的，它不包含在备份文件中。
通常，discourse.conf 中的内容会覆盖站点设置。
因此，如果您在数据库中有 setting_foo，您可以通过在 app.yml 中定义 DISCOURSE_SETTING_FOO 来覆盖它，这会生成 discourse.conf 中的 setting_foo。
太棒了。非常感谢 @RGJ 提供的所有帮助。迁移完成后我会回来告知您进展情况。
使用我们的工具链将 Discourse 容器指向外部 postgresql 和 redis 服务器是一种受支持的安装。
RDS[1] 是 Postgresql，Elasticache 是 Redis，这没问题。
这应该没问题，我们为迁移到我们托管服务的人员就是这样做的。
我倾向于让过程尽可能简单，所以如果你能在旧服务器上运行完整的备份（包括上传文件）并将其恢复到新服务器上，这样你就可以在不影响旧服务器的情况下完全测试新设置。
ok, Postgresql RDS ↩︎
非常感谢 @supermathie
我将按照 @RGJ 的建议，在不更改存储桶名称的情况下进行备份/恢复。正如我所说，我的顾虑是不以任何方式影响现有的服务器数据，但如果我先备份现有的存储桶，并确保在迁移过程中现有服务器处于只读模式，我认为上传数据的完整性在存储桶中得到了很好的保护。
谢谢你的信息！我讨厌自己大胆地暴露我的无知。