将您的 Discourse 实例迁移到不同的服务器

[Discourse]

本指南介绍了如何将您的 Discourse 实例从一台服务器迁移到另一台服务器，包括所有设置和数据。本指南适用于使用 Docker 的自托管 Discourse 实例。

所需用户级别：系统管理员

此过程涉及域名和 DNS 更改。请确保您可以访问源服务器和目标服务器。

本指南将引导您完成将 Discourse 实例从一台服务器迁移到另一台服务器的过程，确保您的数据、设置和配置得以保留。

@pfaffman 2025-09-12T05:00:00Z 添加的免责声明。

现在这些说明不太好用，因为您现在使用的是 HTTPS 和 Let’s Encrypt，这要求新服务器的 DNS 指向它，以便它可以请求密钥。我建议遵循使用 rsync 将 Discourse 站点移动到另一台 VPS（可能使用 --exclude postgres*，然后从命令行备份和恢复数据库。）这很巧妙，因为如果您知道如何操作，您可以调整本地 DNS 指向新服务器，以便在互联网其余部分仍然看到旧站点时测试它是否正常工作。

摘要

您将在此指南中执行以下关键步骤：

1. 备份您当前的 Discourse 实例（源服务器）。
2. 将备份文件传输到您的目标 Discourse 实例（目标服务器）。
3. 在目标服务器上恢复备份。
4. 更新 DNS 设置（如果适用）。

调整 DNS 设置（需要时）

如果您对新服务器使用相同的域名，请提前降低 DNS 条目的 TTL（生存时间）。这确保了更新的 DNS 记录传播期间的停机时间最少。如果您将使用新的域名，则可以跳过此步骤。

登录并准备源服务器

1. 使用具有管理员权限的帐户登录到您的源 Discourse 实例。
2. 确保源服务器和目标服务器都使用：
   • 相同的 Discourse 版本。
   • 相同的插件集。
3. 访问 /admin/upgrade 来升级两台服务器上的 Discourse 版本。

避免将较新的备份恢复到较旧的 Discourse 版本或不兼容的 PostgreSQL 版本上，因为这可能会导致错误。

创建和下载备份

1. 在您的源 Discourse 实例上导航到 /admin/backups。
2. 单击 Backup（备份）按钮来创建一个备份：
   
   
3. 出现提示时，单击 Yes（是）确认。
4. 备份完成后，转到 Backup files（备份文件）选项卡，找到新创建的备份。
5. 单击 Download（下载）以下载一个包含下载链接的电子邮件。单击电子邮件中的链接将备份文件保存到本地。
   
   

在继续之前，请检查您的 app.yml 文件，以确保任何可选设置（例如 CDN 配置、已安装的插件或 HTTPS 支持）在源服务器和目标服务器之间保持一致。

在目标服务器上恢复备份

要通过命令行恢复备份，请参阅相关文档。

1. 登录到您的目标 Discourse 实例并使用管理员凭据。
2. 导航到 /admin/backups/settings，并启用 allow restore（允许恢复）设置。
3. 转到 /admin/backups 并单击 Backup files（备份文件）选项卡。通过单击 Upload（上传）按钮上传您之前下载的备份文件：
   
   
4. 上传完成后，单击上传的备份旁边的 ⋮（更多选项）菜单，然后单击 Restore（恢复）：
   
   
5. 出现提示时，单击 Yes（是）确认。

恢复过程将开始。这可能需要一些时间，具体取决于您的数据库大小。过程完成后，系统将自动注销您。

收尾和登录

1. 使用您的管理员凭据登录到您的目标 Discourse 实例。
2. 如果站点是使用 HTTPS 备份的，请确保新服务器上启用了 HTTPS。如果配置不正确，请使用 Rails 控制台暂时禁用“强制 HTTPS”设置。
3. 通过编辑 app.yml 文件并重建实例来重新启用任何可选配置。这可能包括：
   • 启用 CDN 支持。
   • 安装其他插件。
   • 设置 HTTPS 配置。

常见问题和解决方案

备份文件无法恢复

• 检查源服务器和目标服务器之间的 Discourse 和 PostgreSQL 版本是否匹配。

恢复后无法登录（启用了 HTTPS）

• 使用 Rails 控制台通过运行以下命令暂时禁用 force https：

  SiteSetting.force_https = false
  

[bayardo.rivas]

这个指南在 11 年后仍然有效吗？

我正在 Ubuntu 上运行 Discourse，并且希望从 20.04 LTS 升级到 24.04 LTS，同时尽量减少停机时间。它在 AWS 上。

[merefield (Robert)]

@bayardo.rivas

11年后仍然有效吗？

这有点悲观

@Discourse

最后由 @SaraDev 编辑 2024-11-21T00:47:52Z

[Jagster (Jakke Flemming)]

还是说……这很现实？也就是说，因为这类事情：

@Discourse

检查源服务器和目标服务器之间的 Discourse 和 PostgreSQL 版本是否匹配。

[bayardo.rivas]

我认为有必要表示担忧并询问这是否符合文档。我最近升级了我的 Discourse 论坛，遇到了一些导致系统崩溃的问题，我只是从一个版本升级到了最新版本。这与一些现在已成为 Discourse 核心系统的新插件有关。

我认为迁移到带有更新操作系统的不同实例是一个重大的改变。如果我要尝试这种方法，我希望得到尽可能多的反馈。

我感谢任何有用的评论。谢谢。

[merefield (Robert)]

本指南与该特定更改的范围有些脱节。

[bayardo.rivas]

感谢您的评论。

[Gunnar (Gunnar Helliesen)]

如果您仍在使用 Ubuntu 20.04，您是否在使用 Docker 和 aufs？

如果您正在使用，请在继续之前阅读此内容：

Docker Upgrade Removed AUFS Storage Driver, Killed Discourse

I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I don’t see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I can’t start Docker to mount m…

[pfaffman (Jay Pfaffman)]

是的，虽然我没有仔细看。 不会。如果 DNS 没有指向新站点，新站点将无法从 Let’s Encrypt 获取密钥。因此，您需要备份、传输备份、将 DNS 指向新服务器，然后重建。

如果您想最大限度地减少停机时间，我推荐 将 Discourse 站点迁移到另一台 VPS 并使用 rsync。这会复制您的 SSL 密钥，以便在新服务器准备就绪时即可使用。

除非您已经升级到 Postgres 15（即使如此也可能），否则我推荐（我这样做）是使用 --exclude postgres*，重建，然后备份主站点并在新服务器上恢复该备份。恢复后，切换 DNS。rsync 说明要求您关闭数据库以便复制原始数据库文件。在某些情况下，这可能效果不佳，因此我主要进行数据库备份并恢复它。

编辑：我已将此添加到 OP。

@Discourse

@pfaffman 添加的免责声明 2025-09-12T05:00:00Z。

这些说明现在效果不佳，因为您现在使用的是 https 和 Let’s Encrypt，这要求新服务器的 DNS 指向它，以便它可以请求密钥。我推荐遵循 将 Discourse 站点迁移到另一台 VPS 并使用 rsync（也许使用 --exclude postgres* 然后从命令行备份和恢复数据库。）这很巧妙，因为如果您知道如何操作，您可以调整本地 DNS 指向新服务器，这样您就可以在互联网上的其他人仍然看到旧站点时测试它是否正常工作。

[nathank (Nathan Kershaw)]

谢谢 Jay！我一直想知道为什么在过去（最近）尝试遵循 OP 中的说明时，在 URL / DNS / LetsEncrypt 这方面会遇到一些困难。

最终，我通过为新网站使用子域、确保新服务器上的恢复站点正常运行，然后快速切换 DNS / URL 来解决了这个问题。但这一切都有些不稳定/痛苦（尤其是之后的重新映射）。

现在我明白了为什么需要做所有这些。很高兴知道 rsync 可以绕过一些痛点。

我认为这里有一些清晰的说明将真正帮助到其他人，因为它目前有点令人困惑——而且我不确定将来最好的方法是什么。您的免责声明是否可以作为重写（也许由 @SaraDev？）合并到整个 OP 中。

[pfaffman (Jay Pfaffman)]

@nathank

我一直在想，为什么我最近在尝试遵循 OP 中的说明时，在 URL / DNS / LetsEncrypt 的问题上有点卡住了。

这就是我建议不要遵循这些说明的原因。

@nathank

我认为这里有一些清晰的说明真的会帮助到其他人，因为目前有点令人困惑。

我认为忽略或删除这些说明并遵循我链接的 rsync 主题会帮助到人们。

我错过了什么吗？

[Ethsim2 (Ethan)]

在此补充一个我在迁移过程中遇到的边缘情况，希望能帮助到其他遇到类似问题的人。

在将独立的 Discourse 实例迁移到新 VPS 时，我遇到了一个 Let’s Encrypt/SSL 的边缘情况，因此我记录了详细的诊断和恢复步骤，希望这对其他按照本指南操作的人有用。

在我的案例中，app 内的 nginx 无法启动，因为 /var/discourse/shared/standalone/ssl/ 中的两个 .cer 文件都变成了零字节文件：

PEM_read_bio_X509_AUX() failed

重新构建尝试再次签发证书，经过多次尝试后，我触发了 Let’s Encrypt 的证书速率限制。仅从旧服务器复制仍然有效的证书文件是不够的，因为启动 app 会再次将它们替换为零字节文件。

最终解决问题的方法是停止 app，并从旧服务器复制工作正常的 /var/discourse/shared/standalone/ssl/ 目录以及对应的 /var/discourse/shared/standalone/letsencrypt/ 状态，然后再次启动容器。

我已在此处记录了完整的步骤：

server_migration_diagnosing_standard_ssl.md

这些是针对此次特定迁移的诊断/恢复笔记，而非官方迁移或 HTTPS 文档的替代品。

还有一个较旧的 Meta 主题涵盖了相关的零字节 .cer 故障模式：

Let's Encrypt：*.cer 文件为空

我无法连接到新的 标准 30 分钟安装。环境为 AWS Lightsail，2GB 内存，Ubuntu 18.04 LTS x64，已开放 :443 端口。问题是 Let’s Encrypt 的 *.cer 文件为空。原因是什么？ nginx 日志 root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-r–r-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail error.log PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE) 非…