# 重建大约需要3小时

**URL:** <https://meta.discourse.org/t/rebuild-taking-3hours/240859>\
**Category:** Self-hosting\
**Tags:** server-resources\
**Created:** [2022年十月4日 06:11 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859 "2022-10-04T06:11:54Z")\
**Posts on this page:** 16\
**Page:** 2

<div class="post-metadata">

**Author:** ![Jagster](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jagster/32/192154_2.png) [@Jagster](https://meta.discourse.org/u/Jagster)\
**Post date:** [2022年十月4日 18:27 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/21 "2022-10-04T18:27:18Z")

</div>

这不是我的问题，但这意味着没有其他东西了吗？

> [@smileBeda](#):
>
> 这是一个仅用于此 discourse 实例的 VPS

---

<div class="post-metadata">

**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:** [2022年十月4日 18:59 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/22 "2022-10-04T18:59:38Z")

</div>

也许并非有意，但值得审计主机内容中是否存在加密货币挖掘进程等。

---

<div class="post-metadata">

**Author:** ![supermathie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/supermathie/32/507518_2.png) [@supermathie](https://meta.discourse.org/u/supermathie)\
**Post date:** [2022年十月6日 16:21 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/23 "2022-10-06T16:21:39Z")

</div>

步骤 1：修复已识别的 `vfs` 驱动程序性能问题

---

<div class="post-metadata">

**Author:** ![smileBeda](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/smilebeda/32/272497_2.png) [@smileBeda](https://meta.discourse.org/u/smileBeda)\
**Post date:** [2022年十月7日 09:38 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/24 "2022-10-07T09:38:12Z")

</div>

关于切换到（理想情况下是）`overlay2`，我将不得不删除我当前的安装并重新安装所有东西。这是因为我目前所在的宿主机仅支持 `fuse-overlayfs` 或 `vfs`，而这两者都不推荐。

但是他们很快就会启用支持 `overlay2` 的 KVM。

所以我的意图是使用 KVM，而不是同样不推荐的 fuse-overlayfs。

现在，在 Discourse 应用本身中，我可以进行备份。这具体备份了什么？

如果我进行备份，在一个全新的服务器上重新安装一个全新的 Discourse，然后在初始 Discourse 设置后用备份覆盖它，我是否会丢失当前 Discourse 论坛的任何东西（我的意思是像消息、聊天、设置、用户、上传的图片等）？

这样做会奏效吗？

---

<div class="post-metadata">

**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\
**Post date:** [2022年十月7日 09:48 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/25 "2022-10-07T09:48:25Z")

</div>

是的，那会奏效。

您唯一没有提到的是，要确保在新 Discourse 上安装与当前 Discourse 相同的插件。如果您重新使用 `app.yml`，那么您也会没事的。

---

<div class="post-metadata">

**Author:** ![smileBeda](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/smilebeda/32/272497_2.png) [@smileBeda](https://meta.discourse.org/u/smileBeda)\
**Post date:** [2022年十月7日 10:02 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/26 "2022-10-07T10:02:17Z")

</div>

好的，谢谢你指出来，我敢肯定我差点就撞上了。

好的，那么……

1. 在 Discourse 管理区域进行备份
2. 为了安全起见，当然要备份服务器
3. 复制 yaml 文件
4. 转储服务器
5. 使用支持的技术设置新服务器
6. 安装具有正确存储驱动程序的 Docker
7. _使用备份的 yaml 文件_重建一个全新的 Discourse 实例
8. 从备份恢复 Discourse

有点惊讶备份只有 19.2 MB。  
我们已经上传了几个图片等……但我想我只能试试了。

我将在周末进行尝试，如果存储驱动程序更改奏效，我会回来报告。

---

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2022年十月7日 10:24 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/27 "2022-10-07T10:24:10Z")

</div>

> [@smileBeda](#):
>
> 有点惊讶备份只有 19.2 MB。

检查是否已设置：

![image](https://global.discourse-cdn.com/meta/original/4X/3/1/1/3119b09335e3d1393c87ddc18535844d0abb0aa9.png)

---

<div class="post-metadata">

**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\
**Post date:** [2022年十月7日 10:36 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/28 "2022-10-07T10:36:36Z")

</div>

请注意，该特定设置仅适用于_计划_备份，而不适用于手动备份。手动备份始终会为您提供明确的选择。

另一个要启用的设置是`在备份中包含缩略图`

@smileBeda 我建议将#4推迟到一切正常工作为止。

---

<div class="post-metadata">

**Author:** ![smileBeda](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/smilebeda/32/272497_2.png) [@smileBeda](https://meta.discourse.org/u/smileBeda)\
**Post date:** [2022年十月7日 10:38 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/29 "2022-10-07T10:38:35Z")

</div>

它确实被勾选了，但 `在备份中包含生成的缩略图。禁用此选项将减小备份大小，但需要在恢复后重新烘焙所有帖子。` 没有被勾选。

@RGJ … 对，好主意，需要采取更多步骤，因为我将不得不以新的实体创建一个服务器，但这与风险相比微不足道。

我将让\_自动\_备份触发，以便我获得其中的所有数据，因为据我所知，手动备份不包括图片等。

谢谢…

---

<div class="post-metadata">

**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\
**Post date:** [2022年十月7日 10:39 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/30 "2022-10-07T10:39:58Z")

</div>

> [@smileBeda](#):
>
> 我明白手动备份不包含图片等。

这是一个错误的假设。

创建手动备份时，会弹出一个窗口供您选择是仅备份数据库，还是包含上传文件。

创建计划备份时，由“备份含上传文件”设置决定。

---

<div class="post-metadata">

**Author:** ![smileBeda](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/smilebeda/32/272497_2.png) [@smileBeda](https://meta.discourse.org/u/smileBeda)\
**Post date:** [2022年十月7日 10:57 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/31 "2022-10-07T10:57:39Z")

</div>

> [@RGJ](#):
>
> 这是一个错误的假设。

好的，我误解了您之前的“请注意，该特定设置仅适用于计划备份，而不适用于手动备份。”

谢谢……

---

<div class="post-metadata">

**Author:** ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)\
**Post date:** [2025年三月13日 14:17 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/32 "2025-03-13T14:17:51Z")

</div>

您好，我重新开启了这个话题，因为它仍然是开放的，并且在迁移到新的虚拟服务器后，我们遇到了同样的问题。就像其他人说的那样，我以前重建 Discourse 从来没有超过 20 分钟，但在新服务器上却需要几个小时，而且它的资源是以前服务器的两倍。🤔

我查看了 Meta 上关于长达一小时的升级的其他话题，但无法弄清楚我们遇到的问题是什么：

服务器：4Gb 内存，2CPU，50 Gb 磁盘。

交换空间：

```plaintext
/$ free
              总计 已用 可用 共享 缓冲/缓存 可用
内存: 3911740 507208 2318476 268 1384032 3404532
交换空间: 4095976 45472 4050504

```

Docker：

```plaintext
/$ sudo docker info
客户端:
 版本: 26.1.3
 上下文: default
 调试模式: false

服务器:
 容器: 3
  运行中: 0
  暂停: 0
  已停止: 3
 镜像: 3
 服务器版本: 26.1.3
 存储驱动程序: overlay2
  后端文件系统: extfs
  支持 d_type: true
  使用元数据复制: false
  原生 Overlay Diff: true
  userxattr: false
 日志驱动程序: json-file
 Cgroup 驱动程序: systemd
 Cgroup 版本: 2
 插件:
  卷: local
  网络: bridge host ipvlan macvlan null overlay
  日志: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: 非活动
 运行时: io.containerd.runc.v2 runc
 默认运行时: runc
 Init 二进制文件: docker-init
 containerd 版本:
 runc 版本:
 init 版本:
 安全选项:
  apparmor
  seccomp
   配置文件: builtin
  cgroupns
 内核版本: 6.8.0-31-generic
 操作系统: Ubuntu 24.04.2 LTS
 OSType: linux
 架构: x86_64
 CPUs: 2
 总内存: 3.731GiB
 名称: podkasts
 ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 Docker 根目录: /var/lib/docker
 调试模式: false
 实验性: false
 不安全注册表:
  127.0.0.0/8
 实时恢复启用: false

```

在我看来一切正常，但我可能遗漏了什么。我们还能从哪里查找问题？

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2025年三月13日 21:27 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/33 "2025-03-13T21:27:21Z")

</div>

> [@icaria36](#):
>
> 在这个新服务器上需要几个小时，而且它的资源是以前服务器的两倍

也许是“吵闹的邻居”导致你的新虚拟机比旧虚拟机慢，因为他们占用了你得不到的所有 CPU？

---

<div class="post-metadata">

**Author:** ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)\
**Post date:** [2025年三月14日 10:23 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/34 "2025-03-14T10:23:38Z")

</div>

是的，谢谢你，很高兴像你这样经验丰富的管理员也没有在上述信息中发现任何明显问题，这让人感到安心。是的，我们已经开始检查物理服务器和我们的虚拟环境。至少论坛运行正常，用户没有注意到任何问题。我们只在重建时遇到这个严重的性能问题。昨天我们花了 4 个小时进行重建。😵‍💫

---

<div class="post-metadata">

**Author:** ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)\
**Post date:** [2025年三月15日 19:59 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/35 "2025-03-15T19:59:27Z")

</div>

如果我遇到这个问题，我会打开两到三个终端窗口。一个用于运行重建，一个用于记录经过的时间以及日志更新之间发生长时间延迟的位置，最后一个用于记录机器活动：可能运行 `vmstat 5`

当日志长时间不更新时，请记下 vmstat 报告的活动。

在此处发布日志中的合适摘录，以及您的笔记和相应的 vmstat 输出。

看起来重建的特定部分很可能耗时：要做的是找出是哪些部分，并在那些时候查看机器在做什么。

在停顿期间，我可能还会使用 `ps auxf` 拍摄机器活动的快照。

---

<div class="post-metadata">

**Author:** ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)\
**Post date:** [2025年三月16日 23:27 UTC](https://meta.discourse.org/t/rebuild-taking-3hours/240859/36 "2025-03-16T23:27:25Z")

</div>

谢谢，这是个很好的建议。下次需要重建时，我们会照此办理。

[上一頁](https://meta.discourse.org/t/rebuild-taking-3hours/240859.md?page=1)
