我们在将 Discourse 论坛整体推送到生产环境之前，一直在进行构建、测试，并有意查找其中的漏洞。我刚刚将一个启用了 S3 上传功能的测试论坛从一台服务器迁移到了另一台服务器，但在恢复后，所有附件的 URL 都被重写成了论坛的 URL，而不是 S3 的 URL……
幸运的是，这只是一个测试论坛，所以我们并不太在意数据本身。不过，我希望能够：
A. 仍然修复这个问题。
B. 找到一种方法来减轻或防止这种情况在生产环境中发生。
受影响的不仅仅是帖子，还包括所有图片、媒体、内容和头像（这相当严重）……
有什么建议吗？
在恢复之前，您可以在目标站点的 app.yml 中配置 S3（而非通过管理面板）。一旦确认配置完成并能访问正确的存储桶，即可开始恢复操作，媒体文件将正确关联。
我们有一份关于以此方式配置 S3 的指南：Configure an S3 compatible object storage provider for uploads
你好，Kris
我们确实那样做了，结果就陷入了那种局面。
我将原始的 app.yml 原样复制到目标位置，然后对原始文件进行了备份。问题出在恢复环节：当我们执行恢复操作时，URL 被重写了，尽管实际上没有任何变更，而且 S3 上传功能依然处于启用状态。
我们最终通过重新构建（rebuild）解决了这个问题（我们认为如此，但 Discourse 的缓存机制非常激进，在我们尝试的众多解决方案中，我们其实并不确定具体是哪一步起了作用）。不过，关于如何以最小问题执行迁移，或者在必要时从备份恢复到生产环境，这些疑问仍未得到解答。
这听起来像是你通过站点设置配置了 S3，而不是像 Kris 建议的那样使用环境变量。恢复过程需要知道 S3 的相关信息，而通过站点设置无法实现这一点。
如果你愿意，也可以在控制台中创建不包含上传文件的备份：discourse backup --sql_only
恢复此类备份不会重写上传 URL。因此，只要你的新服务器能够访问相同的 S3 存储桶，这种方法就能奏效。
S3 配置位于 app.yml 中，而非站点设置。
编辑：
我意识到自己解释得不够详尽，也无意隐瞒细节。
我们使用的是 OVH S3，其配置在 app.yml 中。
我曾备份过不含上传内容的测试论坛，但当时 S3 仍处于启用状态。
随后，我使用完全相同的 app.yml 将其恢复到新站点，问题便由此产生。需要说明的是，目前问题已解决，但我不确定是因为我多次重新构建镜像，还是 Discourse 的缓存机制过于激进。正因如此，我需要了解正确的操作流程，确保首次操作即可成功。我担心的是，如果将来需要将备份恢复到生产环境并再次遇到此问题，我必须清楚如何立即修复，以免用户察觉。