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
  

[bayardo.rivas]

Ce guide est-il toujours valide 11 ans plus tard ?

Je fais fonctionner mon Discourse sur Ubuntu et je souhaite mettre à niveau le système d’exploitation de 20.04 LTS vers 24.04 LTS avec le moins de temps d’arrêt possible. Il est sur AWS.

[merefield (Robert)]

@bayardo.rivas

toujours valable 11 ans plus tard ?

C’est un peu pessimiste

@Discourse

Dernière modification par @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Lehtonen)]

Ou est-ce… réaliste ? C’est-à-dire à cause de ce genre de choses :

@Discourse

Vérifiez que les versions de Discourse et PostgreSQL correspondent entre les serveurs source et destination.

[bayardo.rivas]

Il me semble légitime de s’inquiéter et de demander si cela correspond à la documentation. J’ai récemment mis à niveau mon forum Discourse et j’ai rencontré des problèmes qui ont fait planter le système, alors que je ne faisais qu’une mise à niveau d’une version à la dernière. Il s’agissait apparemment de nouveaux plugins qui font maintenant partie du système de base de Discourse.

Je pense que passer à une instance différente avec un système d’exploitation plus récent est un changement majeur. Si je dois essayer cette approche, j’aimerais avoir autant de retours que possible.

J’apprécie tout commentaire utile. Merci.

[merefield (Robert)]

Ce guide sort un peu du cadre de ce changement spécifique.

[bayardo.rivas]

Merci pour vos commentaires.

[Gunnar (Gunnar Helliesen)]

Si vous êtes toujours sur Ubuntu 20.04, utilisez-vous Docker et aufs ?

Si c’est le cas, vous devriez lire ceci avant de continuer :

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

Je crois bien, bien que je n’aie pas regardé de très près. Non. Le nouveau site échouera à obtenir des clés de let’s encrypt si le DNS ne pointe pas vers lui. Vous devrez donc sauvegarder, transférer la sauvegarde, basculer le DNS vers le nouveau serveur, puis reconstruire.

Si vous souhaitez minimiser les interruptions de service, je vous recommande Déplacer un site Discourse vers un autre VPS avec rsync. Cela copie vos clés SSL afin que le nouveau serveur soit prêt lorsque vous effectuerez la reconstruction.

À moins que vous n’ayez déjà mis à niveau vers Postgres 15 (et peut-être même dans ce cas), ce que je recommande (ce que je fais) est --exclude postgres*, reconstruire, puis sauvegarder le site principal et restaurer cette sauvegarde sur le nouveau serveur. Une fois celle-ci restaurée, basculez le DNS. Les instructions rsync vous demandent d’arrêter la base de données afin que vous puissiez copier les fichiers bruts de la base de données. Il y a des cas où cela ne fonctionnera pas très bien, donc la plupart du temps je fais une sauvegarde de la base de données uniquement et je la restaure.

EDIT : J’ai ajouté cela à l’OP.

@Discourse

Avertissement ajouté par @pfaffman 2025-09-12T05:00:00Z.

Ces instructions ne fonctionnent plus très bien car vous utilisez maintenant https et let’s encrypt, qui nécessitent que le nouveau serveur ait le DNS pointant vers lui afin qu’il puisse demander des clés. Ce que je recommande est de suivre Déplacer un site Discourse vers un autre VPS avec rsync (peut-être en utilisant --exclude postgres* puis en sauvegardant et en restaurant la base de données depuis la ligne de commande.) C’est astucieux car si vous savez comment faire, vous pouvez modifier votre DNS local pour qu’il pointe vers le nouveau serveur afin que vous puissiez tester qu’il fonctionne pendant que le reste d’Internet voit toujours l’ancien site.

[nathank (Nathan Kershaw)]

Merci Jay ! Je me suis demandé pourquoi j’avais eu un peu de mal avec tout le truc URL / DNS / LetsEncrypt dans le passé (récent) en essayant de suivre les instructions dans le OP.

J’ai fini par y arriver en utilisant un sous-domaine pour le nouveau site, en m’assurant que mon site restauré sur le nouveau serveur fonctionnait, puis en effectuant un rapide changement DNS / URL. Mais tout cela était un peu bancal / douloureux (surtout le jeu du taupe-et-marteau de remap après !).

Je comprends maintenant pourquoi j’ai dû faire tout cela. Et c’est bien de savoir que rsync peut contourner certains points douloureux.

Je pense que des instructions claires ici aideraient vraiment les autres, car c’est un peu déroutant pour le moment - et je ne suis pas sûr de la meilleure façon de le faire à l’avenir. Votre avertissement pourrait-il être intégré à l’ensemble du OP en tant que réécriture (peut-être par @SaraDev ?).

[pfaffman (Jay Pfaffman)]

@nathank

Je me suis demandé pourquoi j’étais un peu bloqué sur la question des URL / DNS / LetsEncrypt dans le passé (récent) en essayant de suivre les instructions de l’OP.

C’est pourquoi j’ai suggéré de ne pas suivre ces instructions.

@nathank

Je pense que des instructions claires ici aideraient vraiment les autres, car c’est un peu déroutant pour le moment.

Je pense qu’ignorer ou supprimer ces instructions et suivre le sujet rsync que j’ai lié aiderait les gens.

Est-ce que je rate quelque chose ?