# 恢复后头像丢失。如何找回？ **URL:** \ **Category:** Support\ **Created:** [2020年四月16日 10:43 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223 "2020-04-16T10:43:23Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 10:43 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/1 "2020-04-16T10:43:24Z")
我已经对 Discourse 进行了全新安装，并恢复了今晚通过 Discourse 界面备份的数据（备份和恢复均通过 Discourse 界面完成）。 备份内容包括数据库和上传文件。 在恢复数据并对 Discourse 应用执行重建操作后（我推测由于全新安装导致配置文件变更，因此需要执行重建），我们遇到了一个问题。 所有自定义过头像的用户，其头像均已丢失。 我猜测这可能与图片优化有关，或许除了执行 launcher rebuild app 之外，还需要进行其他操作来重新生成这些头像。 但我尚未找到缺失的步骤是什么。 我找到了一些关于用户丢失默认头像（即 Discourse 自带的头像）的讨论帖，但我们的情况并非如此：那些未更改头像（也未上传图片）的用户，其字母头像仍然正常显示。 更新： 我执行了以下命令： ./launcher enter app rake posts:rebake 但这并未解决问题。 是否应该执行其他命令而非 posts:rebake？ ---
**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\ **Post date:** [2020年四月16日 13:33 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/2 "2020-04-16T13:33:14Z")
> [@ariznaf](#): > > 所有自定义了头像的用户的头像都丢失了。 @arinaf， 奇怪的是，今天我在一个通过 nginx 反向代理连接到 Unix 域套接字的配置上也遇到了同样的问题。一切看起来都很正常，但自定义头像显示为图标（人像图标），而所有字母头像则正常显示。 在排查问题时，我回退到了标准的两容器配置（没有 nginx 前端，也没有 Unix 套接字），问题就消失了。 然后，我又换回了通过 nginx 反向代理连接到 Unix 域套接字的配置，问题又出现了。 我完全摸不着头脑……所以先休息一会儿吧 🙂 显然数据本身没有问题，因为在不使用 nginx 反向代理的情况下一切运行完美。这很奇怪，因为不使用它时确实没问题。LOL。（两种配置之前都运行得毫无问题，突然就出现了这个奇怪的头像问题……） ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 13:39 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/3 "2020-04-16T13:39:33Z")
这正是我的配置，因为我正在 Docker 容器中运行其他软件（一个 Ghost 博客）。我使用 Nginx 作为反向代理。 显然，恢复备份并不像看起来那么简单。 我一直尝试重新构建（rebakes），因为我以为是缩略图保存的问题，但毫无成效。 我会尝试你所说的方法来确认问题是否与反向代理有关（虽然我不明白为什么会受此影响，但尝试一下也没什么损失）。 ---
**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\ **Post date:** [2020年四月16日 13:43 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/4 "2020-04-16T13:43:28Z")
> [@ariznaf](#): > > 这正是我的配置，因为我正在 Docker 容器中运行其他软件（一个 Ghost 博客）。 > 我使用 Nginx 作为反向代理。 是的……我认为问题与后端数据库无关，无论是恢复数据库还是执行 rake 任务。 一旦我关闭反向代理，并直接运行两个容器而不使用它，问题就消失了。由于在所有情况下数据库都是相同的，因此不太可能是数据库的问题。 我将离线 12 小时，稍后会回来查看您的设置 @ariznaf 的情况。 ---
**Author:** ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)\ **Post date:** [2020年四月16日 13:45 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/5 "2020-04-16T13:45:00Z")
你在容器外部使用 HTTPS 吗？ 你检查过页面源代码，看看头像使用的 URL 是什么吗？ 听起来 `force_https` 没有启用。 ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 13:46 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/6 "2020-04-16T13:46:09Z")
我现在无法完成，因为需要从头开始。 我一直在尝试复制所有文件（在源端关闭 Discourse），但也没有成功（数据库存在问题）。 我将尝试重新开始，安装一个干净的 Discourse，然后恢复使用 Discourse 制作的备份。 ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 13:47 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/7 "2020-04-16T13:47:21Z")
我会检查一下，谢谢。 尝试恢复数据库或在不同主机之间迁移，难度比预期更大。 感谢两位。 ---
**Author:** ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)\ **Post date:** [2020年四月16日 14:02 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/8 "2020-04-16T14:02:03Z")
只要您未使用反向代理，且目标平台具有代表性且配置正确，整个过程通常非常简单。 ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 15:17 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/9 "2020-04-16T15:17:39Z")
好吧，除非在此期间对 Discourse 本身或您使用的插件进行了升级（我只使用了一些官方插件、主题列表预览和少量组件），否则每次我尝试模拟恢复时都会遇到某种问题。 我觉得备份系统简单直接，但在需要将所有内容迁移到其他服务器时，其稳健性不足。 而且灵活性也不够。 完成备份所需的时间也太长了（对于一个不大的网站来说，完整备份竟然有 3GB）。 我们旧的论坛数据量超过 100GB，使用当前的系统根本无法备份如此庞大的论坛。 ---
**Author:** ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)\ **Post date:** [2020年四月16日 17:56 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/10 "2020-04-16T17:56:16Z")
各种尺寸的头像图片不会包含在备份中，只有原始图片。定时任务需要一些时间来处理并生成每个头像的缩放版本。 ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 18:00 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/11 "2020-04-16T18:00:09Z")
啊，好的。 非常感谢！ 我并不知道它们是在后台重建的。 所以这只是一个等待的问题。 我之前用 rake posts:rebuild 之类的命令时很着急。 你帮我省去了很多麻烦。非常感谢。 ---
**Author:** ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)\ **Post date:** [2020年四月16日 18:08 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/12 "2020-04-16T18:08:50Z")
您可以通过访问论坛的 `/sidekiq/scheduled` 页面，并在 `CreateMissingAvatars` 任务旁边点击“触发”按钮来加速处理。 ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月16日 18:49 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/13 "2020-04-16T18:49:54Z")
哇，/sidekiq 里竟然隐藏着一个完整的世界：slight\_smile: 我一直在尝试你建议的方法。 但是 CreateMissingAvatars 作业已被调度并正在运行，不过它几乎立即终止，完成仅耗时几毫秒。我尝试手动运行它（使用 Trigger），结果同样是立即终止并返回 OK。 但头像仍然不正确。 我目前使用的是原始配置，Discourse 监听 socket，Nginx 作为反向代理。 接下来我将尝试移除 Nginx，让 Discourse 直接在 80 和 443 端口上运行。 ---
**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\ **Post date:** [2020年四月17日 01:57 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/14 "2020-04-17T01:57:18Z")
> [@ariznaf](#): > > 我现在将尝试移除 nginx，并在 80 和 443 端口上运行 Discourse。 你好 @ariznaf 今天早晨醒来，在断网 12 小时后，我切换回了我们的 `socket-only.yml` 配置，一切又恢复正常了。 所以，至少在广阔的 Discourse 宇宙的这一端，“双容器 + nginx 反向代理到 Unix 套接字” 的环境再次安然无恙。 我们在异常被发现前大约六小时切换到了 `nginx` 前端配置，当时一切正常。 基于 @riking 提供的这条宝贵提示（一如既往地感谢，Kane）： > 各种尺寸的头像缩略图并不包含在备份中，只有原始图片。需要一些时间让定时任务遍历并生成所有头像的缩略图。 ![Screen Shot 2020-04-17 at 9.06.09 AM](https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/optimized/3X/f/f/fffea2fc5b21dfecab2a840cdab2d64418a14c14_2_690x31.jpeg) 我最大的猜测是：当我们切换到 `nginx` 时，由于许多头像图片已被缓存，且再生过程尚未结束，所以我们没有发现任何问题；随着时间的推移，这些图片的缓存过期，异常便开始显现。 于是我断网 12 小时（`socket-only.yml` 容器仍在后台运行，但处于非活动状态），早晨醒来后发现 `sidekiq` 整夜都在施展魔法（正如 @riking 所言，顺便说一句，Kane 在 Meta 的每个话题上都提供了极好的支持）。 这个场景似乎证实了 @riking 的推测。 说实话，我们使用 Discourse 的时间越长，就越喜欢它。这些小插曲和异常非常有趣，而双容器配置也确实非常棒。 我们当前的容器列表如下： ```plaintext # 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` 文件所带来的任何感知上的“代价”。_ ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月17日 09:23 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/15 "2020-04-17T09:23:59Z")
就我而言，我尝试仅使用通过界面创建的备份来执行恢复操作。 正如之前所讨论的，我们丢失了头像图片以及一些其他次要内容。 我尝试按照 @riking 提供的指导进行操作，但未能成功。 我尝试通过强制执行该过程来刷新头像图片。但执行在几毫秒后显示“成功”状态，头像却并未生成。 由于我们急于迁移内容，我停止了旧服务器上的论坛，使用 tar 命令复制了所有容器和共享目录中的内容，并在新的服务器上安装了 Discourse（未进行初始配置），然后将共享目录和容器目录复制到新服务器并重建应用。 现在新服务器上的所有功能都已正常运行。 从备份恢复的问题比预期中更复杂（尽管根据说明，只需重新安装并通过界面恢复，看似非常直接）。 我需要调查恢复过程中出现了什么问题，以及如何确保即使 Discourse 的版本已远高于备份时的版本，系统仍能正常启动。 我非常喜欢 Discourse。 从其他传统论坛迁移过来时，有时会觉得难以找到所需功能。 在这种情况下，简洁的界面反而增加了查找难度。 但当你最终找到所需功能时，会发现它确实位于合理的位置，并且以巧妙的方式运作。 我们目前仅遇到从备份恢复的问题，有时也涉及缓存使用过重的问题。 Discourse 首次在你的网页浏览器中加载需要一些时间，但之后运行非常流畅。这是因为大部分处理都在你的本地设备上完成，并且大量使用了缓存（如头像、图片、CSS 等）。 应用不会重复获取你电脑上已有的信息，从而大大减轻了服务器的负担（至少根据我的经验来看是这样）。 当我尝试从一个服务器迁移到另一个服务器，或从头重新安装 Discourse 时，即使刷新页面，仍会看到旧内容。 直到我清除网页浏览器的导航历史记录，才解决了这个问题。这让我困扰和困惑了相当长一段时间。 顺便问一下：如果在备份中选择了保存缩略图，这些头像图片会被保存吗？ 你认为保存它们是否更好？ 我们的论坛规模不大，但保存 36,000 张图片确实花费了不少时间。 ---
**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\ **Post date:** [2020年四月17日 10:01 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/16 "2020-04-17T10:01:54Z")
> [@ariznaf](#): > > 完成时间太长了（对于一个如此庞大的 Noto 站点来说，完整备份仅 3GB）。 你好 @ariznaf， 我们的完整备份大小也差不多，完全 gzipped 后约为 3GB。 到目前为止，我尚未遇到你在帖子（上文 #13）中提到的任何问题。 你是通过命令行还是从用户界面进行恢复的？ 我们仅在容器内通过命令行进行恢复。我假设你的情况也是如此？ > [@ariznaf](#): > > 现在新服务器上的所有功能都已正常运行。 这是个好消息。恭喜。 ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月17日 13:54 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/17 "2020-04-17T13:54:43Z")
感谢您的关注。 我已按照教程中的说明使用界面进行操作。但我不清楚如何通过命令行恢复（使用 Discourse 界面创建的备份）。 让我详细说明一下： 我需要将服务器从 [a.domain.com](http://a.domain.com) 迁移到 [b.domain.com](http://b.domain.com)。 Discourse 论坛通过 HTTPS 访问，使用自定义 SSL（我们拥有全域 SSL 证书）。 Discourse 通过 socket 安装，且 HOST\_NAME 设置为 [a.domain.com](http://a.domain.com)。 我们已配置 Nginx 作为反向代理，将 HTTP（80 端口）流量永久重定向到 HTTPS（443 端口），同时 HTTPS（443 端口）也作为反向代理，将流量转发至 Discourse 监听的 socket。 我在 S3 存储桶中备份了 [a.domain.com](http://a.domain.com) 的数据（通过界面操作），包含数据库和上传文件，但不包含缩略图（约 3GB）。 我安装了 Nginx，并复制了来自 [a.domain.com](http://a.domain.com) 的配置文件，仅将主机名从 [a.domain.com](http://a.domain.com) 更改为 [b.domain.com](http://b.domain.com)。 我按照“30 分钟安装教程”中的建议，从 GitHub 克隆并安装了 Discourse。 随后，我运行了 Discourse 设置（此时 Nginx 已停止），并将 HOSTNAME 配置为 [b.domain.com](http://b.domain.com)。 我以管理员身份登录新的 [b.domain.com](http://b.domain.com) 安装实例。 通过界面，我配置了备份以访问 S3 存储桶，启用了管理员恢复功能，并恢复了最新的备份。 随后，由于用户、配置等已更新，您会被自动登出 Discourse。 回到命令行，我编辑了 app.yml 文件，复制了原始服务器（[a.domain.com](http://a.domain.com)）的配置，仅将主机名更改为 [b.domain.com](http://b.domain.com)。 接着，我执行了 ./launcher rebuild all 命令，完成后启动 Nginx。 我现在可以访问 Discourse 论坛，但头像丢失，且图像缩略图也存在一些问题。 ---
**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\ **Post date:** [2020年四月17日 14:39 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/18 "2020-04-17T14:39:22Z")
> [@ariznaf](#): > > ，我已经配置了备份以访问 S3 存储桶，并启用了管理员恢复功能，同时恢复了上一次备份。 感谢 @ariznaf 提供的如此详细的说明。 老实说，我并不喜欢像 S3 这样的云存储服务。因此，我认为最好搁置任何进一步的设想，毕竟我们并不是“S3 用户”。 ---
**Author:** ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)\ **Post date:** [2020年四月17日 14:50 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/19 "2020-04-17T14:50:48Z")
你说头像丢失了，但你检查过页面源代码，看看它们是从哪里请求的吗？ 它们还在 S3 上吗？ 为什么需要更改子域名？ 明确一下，你既更换了物理服务器，也更改了 DNS 地址，对吗？ ---
**Author:** ![ariznaf](https://avatars.discourse-cdn.com/v4/letter/a/ecccb3/32.png) [@ariznaf](https://meta.discourse.org/u/ariznaf)\ **Post date:** [2020年四月17日 14:57 UTC](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223/20 "2020-04-17T14:57:20Z")
Riking 表示系统需要重新构建缩略图，但该任务似乎已完成。 我将再试一次。目前我已通过另一种方式解决了问题。 在 S3 中仅保存备份，而图像和上传文件则本地存储。 但我需要进行恢复测试，以查明问题所在。 我会查看系统尝试从何处获取图像。 不过，它确实显示了一张白色剪影图像，因此并非链接损坏，很可能是系统因缺少缩略图而进行了替换。 [下一頁](https://meta.discourse.org/t/avatars-lost-after-restore-how-to-get-them-back/148223.md?page=2)