我更改了名称，因为我无法在数小时内关闭原始服务器，直到我测试确认一切正常并交换服务器。
您不需要这样做。如果您拥有通配符证书，只需通过 Hosts 文件进行本地 DNS 更改来配置所有内容并恢复备份即可。
之后，您只需将 DNS 公开切换过来。
我不明白你的意思。
我需要在进行测试时保持 a.domain.com 正常运行。
同时，我需要访问正在恢复的副本的 Discourse 界面，以确认一切是否正常。
因此，我需要另一个 URL 来访问另一台服务器上的副本。
所以，我在恢复后只需更改 Discourse 和 Nginx 中的主机名。
一切正常后，我将新服务器上的名称更改为 a.domain.com，关闭旧服务器，并将 DNS 记录 a.domain.com 指向新服务器。
上述说法不正确。您可以通过修改本地计算机上的 HOSTS 文件，或在本地 DNS 中硬编码一条记录，强制您的本地机器使用相同的 DNS 名称连接到新服务器。
我没有本地机器。
两台服务器都在互联网上，或者是云服务器。
我从 Windows 机器使用 SSH。
也许我可以修改本地主机名来设置机器的 IP，但这比直接修改服务器上的名称更复杂。
您认为主机名的更改可能是问题所在吗？
这应该不是问题…
是的，我们再次发现了这个自定义头像问题。这发生在 sidekiq 进程本应有足够时间重建所有辅助头像和配置文件图片很久之后，但仅出现在配置为“通过 nginx 反向代理到 Unix 域套接字
以下是后续跟进：
在我们讨论的使用 Unix 套接字的反向代理配置中：
然而，当我们检查 force_https 时：
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
当然，正如预期，浏览器证书没有错误（Chrome 显示正常）：
因此，我 外行 的猜测是，在这种配置下，force_https 设置/方法缺少了这些图片；因为除了这些自定义头像（以及个人资料页面图片）之外，其他一切都很完美。
这就是我 超出我对 Discourse 的理解范围 的猜测。
更新：
经过更多研究后，我们发现所有我们的 nginx 反向代理到 Unix 套接字 配置都缺少了大部分 /shared/uploads（文件）。这一步在关于此主题的各种教程和操作指南文档中都被遗漏了，所以下次我在 meta 上看到关于此主题的 wiki 时，我会更新教程/wiki/操作指南以包含此步骤。
唯一剩下的小问题是 favicon 的问题：
如果有人有推荐的解决方法，那就太好了。谢谢！
重新上传即可，这是最快的解决方案。
人们在操作 socket 时往往会忘记已禁用 HTTPS 模板，因此除非手动启用 force_https，否则 Discourse 无法识别其位于 SSL 之后，这也是我昨天的建议。
一旦启用了 force_https，您可以重新上传资源以修正其路径。
我一直没有回复任何相关内容，因为我原以为是某种服务器数据传输失误（未使用内置备份功能）导致 /uploads/ 目录完全缺失，而我也不知道该如何用你能理解的方式解释这一点。
是的……我们按照这篇指南设置了 nginx 反向代理，但那是针对独立部署的，并未提及上传文件，因为在独立模式下不需要传输这些内容：
我们还遵循了这篇关于两个容器的指南，其中同样没有提到进行任何数据库恢复或上传目录的转移：
我想我们完全可以理解这些内容。这里是你之前遗漏的关键线索，供参考：
关于此配置的主要教程遗漏了一个重要事实：你应该要么执行数据库恢复，要么手动将上传文件转移到新容器，因为教程中并未包含这些步骤。
当然，在我们完全靠自己搞定这一切（再次！）之后，现在一切都很合理了，毕竟教程里确实没写。哈哈
一旦你明白了问题所在，一切都会变得简单。
PS：最后，感谢所有撰写各种教程的各位。它们对我们帮助很大！非常感谢。在我们这边，此配置已完成，未来我们将不再在任何 Discourse 站点上使用独立配置。我们的“默认”标准将是两个容器配合反向代理连接到 Unix 套接字。这种方式在更新和实时切换容器时几乎零停机，效果最佳。太棒了！！
Discourse 太棒了！！
做得好，Jeff @codinghorror 和 Sam @sam！太棒了！
@ariznaf……
这其实很容易配置成功，但正如我之前提到的，我们不使用 S3 或其他云存储服务；我们更喜欢保持“简单”，因此我们的备份只是通过 rsync 同步到异地存储。我们更喜欢这种方式……少了一个需要调试的环节 而且我们完全可以“没有 S3 也能生活”。
我不确定这是否有用。但图像优化往往会失败，如果执行优化任务的作业无法通过其互联网域名访问您的服务器。
这可能解释了为什么在更复杂的反向代理设置中，此功能无法按预期工作。
谢谢你，Kane。
正如你可能知道的，我正在尝试 Discourse 标准 UI 备份方法之外的其他替代方案。
之所以尝试这些方法，是因为每次使用标准备份方法进行恢复时都会遇到问题，而且我们一直遵循本站官方教程中给出的说明。
无论如何，我在开头已经说明，我们使用的是通过 UI 界面创建的标准备份，并遵循标准的备份和推荐的恢复流程。
与独立安装的 Discourse 相比，唯一的区别是我们使用了 Nginx 作为反向代理，并通过 socket 连接到 Discourse。
我们发现的主要问题在于头像：它们似乎丢失了，并被默认的个人资料头像所取代。
你曾告诉我，这需要通过 Sidekiq 任务来重建。但该任务在启动后似乎会立即以成功状态（OK 状态）结束，而头像却保持不变。
备份对我们来说非常重要（谁能忽视备份呢？），因此我将进行更多测试，在遵循指示时格外小心，并尝试这里提供的其他建议。
我们对 Discourse 非常满意，非常喜欢它。我们只是想确保拥有一套稳健的恢复流程，以防万一遭受某种攻击（我们最近就遭遇过一次）或服务器故障。
如果你希望我们进行某些测试以尝试解决此问题，或提供一些信息，我很乐意尽最大努力并提供所需信息。
看起来系统确实无法访问头像缩略图。
但论坛的其他部分都正常提供服务，路由、SSL 以及所有配置看起来都是正确的。如果存在某种配置错误，您根本无法访问 Discourse 论坛并查看其他内容，而是会遇到 502 错误或其他类似问题。
@neounix
我们使用 S3 是因为从 UI 角度来看，这是将备份存储到异地最简单的方法。
也许 S3 并不是最佳选择，我也不确定。但无论如何，备份存储的位置与当前问题无关，因为问题并非无法访问备份或无法执行恢复。恢复操作已成功完成。
@stephan
在 app.yml 中，我已注释掉 SSL 模板和 Let’s Encrypt 模板，以及包含端口的 expose 部分。SSL 由 Nginx 处理，因此我不需要加密 socket，对吗？
这样做是否正确？是否仍应使用 SSL 模板？
我假设如果这是问题所在，那么恢复后我将无法看到论坛的任何部分，而不仅仅是头像。但谁知道呢……
我会进行更多测试。感谢大家提供的帮助。
@ariznaf … 嘿！
我在两台不同的服务器上解决这个问题的方法是：手动将原始配置中的 /shared/uploads 目录复制到 socket-only 配置中，之后这个问题就消失了。
我快速检查的方法是直接比较 uploads 目录的大小，方法如下（假设你当前位于 shared 目录下）：
du -sh uploads
当我比较它们时，就发现了问题所在
你也可以检查一下吗？希望这能帮助你定位问题。
附注：我对 S3 没有负面看法。俗话说，各有所好……
让我确认一下我是否正确地理解了您的意思。
当我进行备份时，我已经检查过是否保存了上传文件（不包括缩略图，但我测试过保存缩略图，现在我正在保存缩略图，因此您无需等待重新生成）。
恢复后，上传文件也会被恢复。
您的意思是恢复上传文件的过程不正确，需要手动操作吗？
您是如何手动恢复上传文件的？
您是否下载了备份，并解压了 shared/standalone/uploads 目录？
如果是这种情况（我会尝试），在我看来，这显然是恢复任务中存在某种错误。
谢谢。
我正在寻找其他备份和存储方案，但 Discourse 团队坚持认为，唯一正确的方法是使用标准备份功能。
你好 @ariznaf，
我们不会通过管理界面进行恢复（我们仅通过网页界面进行备份，不进行恢复）。我们会将文件 sftp 到容器中（包含上传文件），然后按如下方式恢复：
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
不过，前几天我创建了一个新的 nginx 反向代理到 Unix 套接字 配置时，并没有从数据库恢复，因为数据库已经存在于 data 容器中（正如操作指南主题中所提到的）。
这就是为什么我必须手动将上传文件复制到新容器的原因。
您的情况似乎与我们的不同。
希望这能帮到您。
谢谢。
看起来您通过命令行执行了与我们通过界面相同的操作：启用恢复功能，并从包含数据库和上传文件的 tgz 文件中恢复数据。
但随后您提到，为了让头像功能正常运行（使用套接字和 Nginx 反向代理），您还需要单独对上传文件进行一次恢复，我理解得对吗？
嘿 @ariznaf……不完全是……
起初，我们有一个独立的应用程序。我将该应用拆分为两个不同的容器（数据容器和仅 Web 容器），然后从包含上传文件的完整备份文件中执行了一次恢复操作。
一切进展顺利……
接着，我创建了一个名为 socket-only 的新容器，并将其配置为使用反向代理。
我并没有在 socket-only 新容器中执行恢复操作（因为数据容器中已经完整保留了数据库数据），但我忘记手动复制上传文件（这是我的失误）。如果我执行了正常的恢复流程，这一步本来是不必要的。
不过，在新容器中完全没有必要再次手动恢复数据库，这正是将数据独立存放在一个专属小容器中的原因。因此，在这种情况下，必须将上传文件手动复制到新容器中。其实这样设计得很巧妙。
这样解释有帮助吗？
我说的不是这个。我说的是后端无法通过前端的 nginx 访问自身。你所说的恰恰相反。
为了优化上传，Sidekiq 作业会通过 http(s) 获取上传内容。
不，您可以禁用 SSL 模板，但需要手动启用 force_https。