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]

Ist diese Anleitung auch 11 Jahre später noch gültig?

Ich betreibe mein Discourse unter Ubuntu und möchte das Betriebssystem von 20.04 LTS auf 24.04 LTS mit möglichst geringer Ausfallzeit upgraden. Es ist in AWS.

[merefield (Robert)]

@bayardo.rivas

noch 11 Jahre gültig?

Das ist ein wenig pessimistisch

@Discourse

Zuletzt bearbeitet von @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Lehtonen)]

Oder ist es… realistisch? D. h. Wegen dieser Art von Dingen:

@Discourse

Stellen Sie sicher, dass die Discourse- und PostgreSQL-Versionen zwischen Quell- und Zielserver übereinstimmen.

[bayardo.rivas]

Ich halte es für berechtigt, besorgt zu sein und zu fragen, ob dies der Dokumentation entspricht. Ich habe kürzlich mein Discourse-Forum aktualisiert und einige Probleme gehabt, die das System zum Absturz brachten. Ich habe gerade von einer Version auf die neueste aktualisiert. Etwas über neue Plugins, die jetzt im Kernsystem von Discourse enthalten sind.

Ich denke, der Umzug zu einer anderen Instanz mit einem neueren Betriebssystem ist eine große Veränderung. Wenn ich diesen Ansatz versuchen werde, möchte ich so viel Feedback wie möglich erhalten.

Ich schätze jeden nützlichen Kommentar. Danke.

[merefield (Robert)]

Dieser Leitfaden liegt etwas außerhalb des Geltungsbereichs dieser spezifischen Änderung.

[bayardo.rivas]

Danke für deine Kommentare.

[Gunnar (Gunnar Helliesen)]

Wenn Sie sich noch auf Ubuntu 20.04 befinden, verwenden Sie Docker und aufs?

Wenn ja, sollten Sie dies lesen, bevor Sie fortfahren:

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

Ich glaube schon, obwohl ich nicht besonders genau hingesehen habe. Nein. Die neue Website kann keine Schlüssel von Let’s Encrypt abrufen, wenn die DNS-Einträge nicht darauf zeigen. Sie müssten also ein Backup erstellen, das Backup übertragen, die DNS-Einträge auf den neuen Server umstellen und dann neu aufbauen.

Wenn Sie die Ausfallzeit minimieren möchten, empfehle ich Eine Discourse-Website mit rsync auf einen anderen VPS verschieben. Dies kopiert Ihre SSL-Schlüssel, sodass der neue Server bereit ist, wenn Sie den Neuaufbau durchführen.

Es sei denn, Sie haben bereits auf Postgres 15 aktualisiert (und vielleicht sogar dann), empfehle ich (was ich tue) --exclude postgres*, neu aufbauen und dann die Hauptwebsite sichern und dieses Backup auf dem neuen Server wiederherstellen. Wenn dies wiederhergestellt ist, ändern Sie die DNS-Einträge. Die rsync-Anweisungen besagen, dass Sie die Datenbank herunterfahren, damit Sie die rohen Datenbankdateien kopieren können. Es gibt einige Fälle, in denen dies nicht sehr gut funktioniert, daher erstelle ich meistens ein reines Datenbank-Backup und stelle es wieder her.

EDIT: Ich habe dies zum OP hinzugefügt.

@\"Discourse

\n### Haftungsausschluss von @pfaffman hinzugefügt 2025-09-12T05:00:00Z.\n\nDiese Anweisungen funktionieren jetzt nicht gut, da Sie https und Let’s Encrypt verwenden, was erfordert, dass der neue Server über DNS darauf verweist, damit er Schlüssel anfordern kann. Was ich empfehle, ist, Eine Discourse-Website mit rsync auf einen anderen VPS verschieben zu befolgen (vielleicht mit --exclude postgres* und dann die Datenbank von der Befehlszeile sichern und wiederherstellen). Dies ist raffiniert, da Sie, wenn Sie wissen, wie, Ihre lokalen DNS-Einträge so anpassen können, dass sie auf den neuen Server zeigen, damit Sie testen können, ob er funktioniert, während der Rest des Internets immer noch die alte Website sieht.\n

[nathank (Nathan Kershaw)]

Danke Jay! Ich habe mich gefragt, warum ich in der (jüngsten) Vergangenheit ein wenig mit dem ganzen URL / DNS / LetsEncrypt-Ding feststeckte, als ich versuchte, den Anweisungen im OP zu folgen.

Ich habe es schließlich geschafft, indem ich eine Subdomain für die neue Website verwendet habe, sichergestellt habe, dass meine wiederhergestellte Website auf dem neuen Server funktionierte, und dann einen schnellen DNS / URL-Wechsel vorgenommen habe. Aber das war alles ein wenig wackelig / schmerzhaft (besonders das anschließende Remap-Whack-a-Mole!).

Warum ich all das tun musste, ergibt jetzt Sinn. Und gut zu wissen, dass rsync einige der Schmerzpunkte umgehen kann.

Ich denke, dass einige klare Anweisungen hier anderen wirklich helfen würden, da es im Moment etwas verwirrend ist - und ich bin mir nicht sicher, wie ich es in Zukunft am besten machen kann. Könnte Ihr Haftungsausschluss vielleicht in den gesamten OP als Umschreibung (vielleicht von @SaraDev?) aufgenommen werden.

[pfaffman (Jay Pfaffman)]

@nathank

Ich habe mich gefragt, warum ich in der (jüngsten) Vergangenheit ein wenig bei dem ganzen URL / DNS / LetsEncrypt-Ding hängen geblieben bin, als ich versuchte, den Anweisungen im OP zu folgen.

Deshalb habe ich vorgeschlagen, diese Anweisungen nicht zu befolgen.

@nathank

Ich denke, dass einige klare Anweisungen hier anderen wirklich helfen würden, da es im Moment etwas verwirrend ist

Ich denke, dass das Ignorieren oder Löschen dieser Anweisungen und das Befolgen des rsync-Themas, das ich verlinkt habe, den Leuten helfen würde.

Fehlt mir etwas?