Move your Discourse Instance to a Different Server

[Discourse]

This is a guide for moving your Discourse instance from one server to another, including all settings and data. This guide applies to self-hosted Discourse instances using Docker.

Required user level: System Administrator

This procedure involves domain and DNS changes. Ensure you have access to both the source and destination servers.

This guide walks you through the process of migrating your Discourse instance from one server to another, ensuring your data, settings, and configuration are preserved.

Disclaimer added by @pfaffman 2025-09-12T05:00:00Z.

These instructions don’t work well now because you’re now using https and let’s encrypt, which require the new server to have DNS pointed to it so that it can request keys. What I recommend is follow the Move a Discourse site to another VPS with rsync (perhaps using --exclude postgres* and then backing up and restoring the database from the command line.) This is slick since if you know how, you can tweak your local DNS to point to the new server so you can test that it works while the rest of the internet still sees the old site.

Summary

You will perform the following key steps in this guide:

1. Back up your current Discourse instance (source server).
2. Transfer the backup file to your target Discourse instance (destination server).
3. Restore the backup on the destination server.
4. Update DNS settings (if applicable).

Adjusting DNS settings (when required)

If you’re using the same domain for the new server, reduce the TTL (time to live) on your DNS entry in advance. This ensures minimal downtime during propagation of the updated DNS records. If you’ll use a new domain, this step can be skipped.

Logging in and preparing the source server

1. Log in to your source Discourse instance with an account that has administrator permissions.
2. Ensure both the source and destination servers are using:
   • The same Discourse version.
   • The same set of plugins.
3. Upgrade the Discourse version on both servers by visiting /admin/upgrade.

Avoid restoring a newer backup onto an older Discourse version, or incompatible PostgreSQL versions, as this may result in errors.

Creating and downloading the backup

1. Navigate to /admin/backups on your source Discourse instance.
2. Click the Backup button to create a backup:
   
   
3. When prompted, confirm by clicking Yes.
4. Once the backup is complete, return to the Backups tab, and locate the newly created backup.
5. Click Download to save the file locally:
   
   

Before proceeding, review your app.yml file to ensure any optional settings, such as CDN configurations, installed plugins, or HTTPS support, are consistent between the source and destination servers.

Restoring the backup on the destination server

To restore the backup via the command line, refer to the relevant documentation.

1. Sign in as an administrator to your destination Discourse instance.
2. Navigate to /admin/site_settings, and search for restore. Enable the allow restore setting.
3. Go to /admin/backups and upload the backup file you downloaded earlier by clicking the Upload button:
   
   
4. After the upload completes, click the Restore button for the uploaded backup:
   
   
5. Confirm by clicking Yes when prompted.

The restoration process will begin. This may take some time depending on your database size. After the process completes, you’ll be logged out automatically.

Finishing up and logging in

1. Log into your destination Discourse instance with your admin credentials.
2. If the site was backed up using HTTPS, ensure HTTPS is enabled on the new server. If not properly configured, use the Rails console to disable the “force https” setting temporarily.
3. Re-enable any optional configurations by editing the app.yml file and rebuilding your instance. This may include:
   • Enabling CDN support.
   • Installing additional plugins.
   • Setting HTTPS configurations.

Common issues and solutions

Backup file is not restoring

• Check that the Discourse and PostgreSQL versions match between the source and destination servers.

Unable to log in after restoration (with HTTPS enabled)

• Use the Rails console to disable force https temporarily by running:

  SiteSetting.force_https = false
  

Last edited by @pfaffman 2025-09-12T22:10:57Z

Check document

Perform check on document:

[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 Lehtonen)]

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

@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 主题会帮助到人们。

我错过了什么吗？