Move your Discourse Instance to a Different Server

:bookmark: 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.

:person_raising_hand: Required user level: System Administrator

:warning: 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.

:exclamation: 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:

:warning: 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

:bulb: 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 documentPerform check on document:
「いいね!」 74

このガイドは11年後の現在でも有効ですか?

DiscourseをUbuntuで実行しており、OSを20.04 LTSから24.04 LTSに、ダウンタイムを最小限にしてアップグレードしたいと考えています。AWS上にあります。

それは少し悲観的すぎますよ :wink: :slight_smile:

それとも…現実的?つまり、このようなことのせいです。

ドキュメントと同じように懸念して質問するのは妥当だと思います。最近、Discourseフォーラムをアップグレードしたところ、システムが壊れる問題が発生しました。最新バージョンにアップグレードしたばかりでした。新しいプラグインがDiscourseのコアシステムに組み込まれたことに関する何らかの問題です。

新しいOSを搭載した別のインスタンスに移行するのは大きな変更だと思います。このアプローチを試すのであれば、可能な限り多くのフィードバックを得たいと思います。

何か役立つコメントがあれば感謝します。ありがとうございます。

このガイドは、その特定の変更の範囲外です。

コメントありがとうございます。

Ubuntu 20.04 をまだ使用していますか。Docker と aufs を使用していますか?

もしそうなら、続行する前にこれを読むことをお勧めします。

そうだと思いますが、よく確認しませんでした。 いいえ。DNSが新しいサイトを指していない場合、新しいサイトはLet’s Encryptからキーを取得できなくなります。そのため、バックアップを取得し、バックアップを転送し、DNSを新しいサーバーに切り替え、その後再構築する必要があります。

ダウンタイムを最小限に抑えたい場合は、Discourseサイトをrsyncで別のVPSに移動することをお勧めします。これにより、SSLキーがコピーされるため、再構築時に新しいサーバーの準備が整います。

Postgres 15にすでにアップグレードしている場合(またはそうでない場合でも)、お勧めするのは(私がやっていることですが)--exclude postgres*で再構築し、その後メインサイトをバックアップして、そのバックアップを新しいサーバーに復元することです。復元したら、DNSを切り替えます。rsyncの手順では、データベースファイルをコピーできるようにデータベースをシャットダウンします。これはあまりうまくいかない場合があるため、ほとんどの場合、データベースのみのバックアップを作成して復元します。

追記:OPに追加しました。

「いいね!」 1

ジェイさん、ありがとうございます!以前、OPの指示に従おうとした際に、URL/DNS/LetsEncryptの件で少し行き詰まってしまった理由がわかりました。

最終的には、新しいサイトにサブドメインを使用し、新しいサーバーで復元したサイトが動作していることを確認してから、DNS/URLを素早く切り替えることで対応しました。しかし、それはかなり不安定で面倒な作業でした(特にその後のリマップのいたちごっこは!)。

なぜそのような作業が必要だったのか、今なら理解できます。そして、rsync が一部の痛みを回避できると知ってよかったです。

ここにはっきりとした指示があれば、他の人たちも助かると思います。現時点では少し混乱しており、将来的に最善の方法がわかりません。あなたの免責事項を、OP全体に書き直して(おそらく@SaraDevさんによって?)組み込むことはできないでしょうか。

だから、これらの指示に従わないことを提案したんです。:rofl:

これらの指示を無視または削除して、私がリンクしたrsyncトピックに従うことが、人々を助けることになると思います。

何か見落としていることはありますか?