我已经对 Discourse 进行了全新安装，并恢复了今晚通过 Discourse 界面备份的数据（备份和恢复均通过 Discourse 界面完成）。
备份内容包括数据库和上传文件。
在恢复数据并对 Discourse 应用执行重建操作后（我推测由于全新安装导致配置文件变更，因此需要执行重建），我们遇到了一个问题。
所有自定义过头像的用户，其头像均已丢失。
我猜测这可能与图片优化有关，或许除了执行 launcher rebuild app 之外，还需要进行其他操作来重新生成这些头像。
但我尚未找到缺失的步骤是什么。
我找到了一些关于用户丢失默认头像（即 Discourse 自带的头像）的讨论帖，但我们的情况并非如此：那些未更改头像（也未上传图片）的用户，其字母头像仍然正常显示。
更新：
我执行了以下命令：
./launcher enter app
rake posts:rebake
但这并未解决问题。
是否应该执行其他命令而非 posts:rebake？
@arinaf，
奇怪的是，今天我在一个通过 nginx 反向代理连接到 Unix 域套接字的配置上也遇到了同样的问题。一切看起来都很正常，但自定义头像显示为图标（人像图标），而所有字母头像则正常显示。
在排查问题时，我回退到了标准的两容器配置（没有 nginx 前端，也没有 Unix 套接字），问题就消失了。
然后，我又换回了通过 nginx 反向代理连接到 Unix 域套接字的配置，问题又出现了。
我完全摸不着头脑……所以先休息一会儿吧 
显然数据本身没有问题，因为在不使用 nginx 反向代理的情况下一切运行完美。这很奇怪，因为不使用它时确实没问题。LOL。（两种配置之前都运行得毫无问题，突然就出现了这个奇怪的头像问题……）
这正是我的配置，因为我正在 Docker 容器中运行其他软件（一个 Ghost 博客）。我使用 Nginx 作为反向代理。
显然，恢复备份并不像看起来那么简单。
我一直尝试重新构建（rebakes），因为我以为是缩略图保存的问题，但毫无成效。
我会尝试你所说的方法来确认问题是否与反向代理有关（虽然我不明白为什么会受此影响，但尝试一下也没什么损失）。
是的……我认为问题与后端数据库无关，无论是恢复数据库还是执行 rake 任务。
一旦我关闭反向代理，并直接运行两个容器而不使用它，问题就消失了。由于在所有情况下数据库都是相同的，因此不太可能是数据库的问题。
我将离线 12 小时，稍后会回来查看您的设置 @ariznaf 的情况。
你在容器外部使用 HTTPS 吗？
你检查过页面源代码，看看头像使用的 URL 是什么吗？
听起来 force_https 没有启用。
我现在无法完成，因为需要从头开始。
我一直在尝试复制所有文件（在源端关闭 Discourse），但也没有成功（数据库存在问题）。
我将尝试重新开始，安装一个干净的 Discourse，然后恢复使用 Discourse 制作的备份。
我会检查一下，谢谢。
尝试恢复数据库或在不同主机之间迁移，难度比预期更大。
感谢两位。
只要您未使用反向代理，且目标平台具有代表性且配置正确，整个过程通常非常简单。
好吧，除非在此期间对 Discourse 本身或您使用的插件进行了升级（我只使用了一些官方插件、主题列表预览和少量组件），否则每次我尝试模拟恢复时都会遇到某种问题。
我觉得备份系统简单直接，但在需要将所有内容迁移到其他服务器时，其稳健性不足。
而且灵活性也不够。
完成备份所需的时间也太长了（对于一个不大的网站来说，完整备份竟然有 3GB）。
我们旧的论坛数据量超过 100GB，使用当前的系统根本无法备份如此庞大的论坛。
各种尺寸的头像图片不会包含在备份中，只有原始图片。定时任务需要一些时间来处理并生成每个头像的缩放版本。
啊，好的。
非常感谢！
我并不知道它们是在后台重建的。
所以这只是一个等待的问题。
我之前用 rake posts:rebuild 之类的命令时很着急。
你帮我省去了很多麻烦。非常感谢。
您可以通过访问论坛的 /sidekiq/scheduled 页面，并在 CreateMissingAvatars 任务旁边点击“触发”按钮来加速处理。
哇，/sidekiq 里竟然隐藏着一个完整的世界：slight_smile:
我一直在尝试你建议的方法。
但是 CreateMissingAvatars 作业已被调度并正在运行，不过它几乎立即终止，完成仅耗时几毫秒。我尝试手动运行它（使用 Trigger），结果同样是立即终止并返回 OK。
但头像仍然不正确。
我目前使用的是原始配置，Discourse 监听 socket，Nginx 作为反向代理。
接下来我将尝试移除 Nginx，让 Discourse 直接在 80 和 443 端口上运行。
你好 @ariznaf
今天早晨醒来，在断网 12 小时后，我切换回了我们的 socket-only.yml 配置，一切又恢复正常了。
所以，至少在广阔的 Discourse 宇宙的这一端，“双容器 + nginx 反向代理到 Unix 套接字” 的环境再次安然无恙。
我们在异常被发现前大约六小时切换到了 nginx 前端配置，当时一切正常。
基于 @riking 提供的这条宝贵提示（一如既往地感谢，Kane）：
各种尺寸的头像缩略图并不包含在备份中，只有原始图片。需要一些时间让定时任务遍历并生成所有头像的缩略图。
我最大的猜测是：当我们切换到 nginx 时，由于许多头像图片已被缓存，且再生过程尚未结束，所以我们没有发现任何问题；随着时间的推移，这些图片的缓存过期，异常便开始显现。
于是我断网 12 小时（socket-only.yml 容器仍在后台运行，但处于非活动状态），早晨醒来后发现 sidekiq 整夜都在施展魔法（正如 @riking 所言，顺便说一句，Kane 在 Meta 的每个话题上都提供了极好的支持）。
这个场景似乎证实了 @riking 的推测。
说实话，我们使用 Discourse 的时间越长，就越喜欢它。这些小插曲和异常非常有趣，而双容器配置也确实非常棒。
我们当前的容器列表如下：
# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml
我喜欢这一点的是，即使遇到问题（例如这次的 头像再生异常），我们也可以轻松地在 socket-only.yml 和 web-only.yml 之间来回切换。
在这种情况下，我们在再生过程中切换回了 web-only，并在过程结束后再次切换回来（因为所有容器仍在运行）。当我们执行容器重建时，可以非常轻松地在这些容器和配置之间切换。
在运营了二十年的 LAMP 论坛之后，我们在系统管理层面越来越对 Discourse 印象深刻。
侧栏（编辑观点）：
当然，这超出了我在 Meta 上的发帖等级范围，但我认为基本的双容器配置（不含反向代理）应该作为默认选项，因为它非常容易设置，而且我们从这种配置中获得的收益远大于拥有两个 yml 文件所带来的任何感知上的“代价”。
就我而言，我尝试仅使用通过界面创建的备份来执行恢复操作。
正如之前所讨论的，我们丢失了头像图片以及一些其他次要内容。
我尝试按照 @riking 提供的指导进行操作，但未能成功。
我尝试通过强制执行该过程来刷新头像图片。但执行在几毫秒后显示“成功”状态，头像却并未生成。
由于我们急于迁移内容，我停止了旧服务器上的论坛，使用 tar 命令复制了所有容器和共享目录中的内容，并在新的服务器上安装了 Discourse（未进行初始配置），然后将共享目录和容器目录复制到新服务器并重建应用。
现在新服务器上的所有功能都已正常运行。
从备份恢复的问题比预期中更复杂（尽管根据说明，只需重新安装并通过界面恢复，看似非常直接）。
我需要调查恢复过程中出现了什么问题，以及如何确保即使 Discourse 的版本已远高于备份时的版本，系统仍能正常启动。
我非常喜欢 Discourse。
从其他传统论坛迁移过来时，有时会觉得难以找到所需功能。
在这种情况下，简洁的界面反而增加了查找难度。
但当你最终找到所需功能时，会发现它确实位于合理的位置，并且以巧妙的方式运作。
我们目前仅遇到从备份恢复的问题，有时也涉及缓存使用过重的问题。
Discourse 首次在你的网页浏览器中加载需要一些时间，但之后运行非常流畅。这是因为大部分处理都在你的本地设备上完成，并且大量使用了缓存（如头像、图片、CSS 等）。
应用不会重复获取你电脑上已有的信息，从而大大减轻了服务器的负担（至少根据我的经验来看是这样）。
当我尝试从一个服务器迁移到另一个服务器，或从头重新安装 Discourse 时，即使刷新页面，仍会看到旧内容。
直到我清除网页浏览器的导航历史记录，才解决了这个问题。这让我困扰和困惑了相当长一段时间。
顺便问一下：如果在备份中选择了保存缩略图，这些头像图片会被保存吗？
你认为保存它们是否更好？
我们的论坛规模不大，但保存 36,000 张图片确实花费了不少时间。
你好 @ariznaf，
我们的完整备份大小也差不多，完全 gzipped 后约为 3GB。
到目前为止，我尚未遇到你在帖子（上文 #13）中提到的任何问题。
你是通过命令行还是从用户界面进行恢复的？
我们仅在容器内通过命令行进行恢复。我假设你的情况也是如此？
这是个好消息。恭喜。
感谢您的关注。
我已按照教程中的说明使用界面进行操作。但我不清楚如何通过命令行恢复（使用 Discourse 界面创建的备份）。
让我详细说明一下：
我需要将服务器从 a.domain.com 迁移到 b.domain.com。
Discourse 论坛通过 HTTPS 访问，使用自定义 SSL（我们拥有全域 SSL 证书）。
Discourse 通过 socket 安装，且 HOST_NAME 设置为 a.domain.com。
我们已配置 Nginx 作为反向代理，将 HTTP（80 端口）流量永久重定向到 HTTPS（443 端口），同时 HTTPS（443 端口）也作为反向代理，将流量转发至 Discourse 监听的 socket。
我在 S3 存储桶中备份了 a.domain.com 的数据（通过界面操作），包含数据库和上传文件，但不包含缩略图（约 3GB）。
我安装了 Nginx，并复制了来自 a.domain.com 的配置文件，仅将主机名从 a.domain.com 更改为 b.domain.com。
我按照“30 分钟安装教程”中的建议，从 GitHub 克隆并安装了 Discourse。
随后，我运行了 Discourse 设置（此时 Nginx 已停止），并将 HOSTNAME 配置为 b.domain.com。
我以管理员身份登录新的 b.domain.com 安装实例。
通过界面，我配置了备份以访问 S3 存储桶，启用了管理员恢复功能，并恢复了最新的备份。
随后，由于用户、配置等已更新，您会被自动登出 Discourse。
回到命令行，我编辑了 app.yml 文件，复制了原始服务器（a.domain.com）的配置，仅将主机名更改为 b.domain.com。
接着，我执行了 ./launcher rebuild all 命令，完成后启动 Nginx。
我现在可以访问 Discourse 论坛，但头像丢失，且图像缩略图也存在一些问题。
感谢 @ariznaf 提供的如此详细的说明。
老实说，我并不喜欢像 S3 这样的云存储服务。因此，我认为最好搁置任何进一步的设想，毕竟我们并不是“S3 用户”。
你说头像丢失了，但你检查过页面源代码，看看它们是从哪里请求的吗？
它们还在 S3 上吗？
为什么需要更改子域名？
明确一下，你既更换了物理服务器，也更改了 DNS 地址，对吗？
Riking 表示系统需要重新构建缩略图，但该任务似乎已完成。
我将再试一次。目前我已通过另一种方式解决了问题。
在 S3 中仅保存备份，而图像和上传文件则本地存储。
但我需要进行恢复测试，以查明问题所在。
我会查看系统尝试从何处获取图像。
不过，它确实显示了一张白色剪影图像，因此并非链接损坏，很可能是系统因缺少缩略图而进行了替换。