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]

Questa guida è ancora valida dopo 11 anni?

Sto eseguendo Discourse su Ubuntu e voglio aggiornare il sistema operativo da 20.04 LTS a 24.04 LTS con il minor tempo di inattività possibile. Si trova su AWS.

[merefield (Robert)]

@bayardo.rivas

ancora valido dopo 11 anni?

Questo è un po’ pessimista

@Discourse

Ultima modifica di @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Lehtonen)]

O è… realistico? Cioè, a causa di questo tipo di cose:

@Discourse

Verifica che le versioni di Discourse e PostgreSQL corrispondano tra i server di origine e di destinazione.

[bayardo.rivas]

Ritengo sia valido preoccuparsi e chiedere se questo sia conforme alla documentazione. Recentemente ho aggiornato il mio forum Discourse e ho riscontrato alcuni problemi che hanno compromesso il sistema, stavo semplicemente aggiornando da una versione all’ultima. Qualcosa riguardo ai nuovi plugin che ora sono nel sistema principale di Discourse.

Penso che passare a un’istanza diversa con un sistema operativo più recente sia un cambiamento importante. Se dovessi provare questo approccio, vorrei avere tutti i feedback possibili.

Apprezzo qualsiasi commento utile. Grazie.

[merefield (Robert)]

Questa guida è un po’ al di fuori dell’ambito di quella specifica modifica.

[bayardo.rivas]

grazie per i tuoi commenti.

[Gunnar (Gunnar Helliesen)]

Se sei ancora su Ubuntu 20.04, stai usando Docker e aufs?

Se sì, dovresti leggere questo prima di procedere:

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

Credo di sì, anche se non ho guardato molto attentamente. No. Il nuovo sito non riuscirà a ottenere le chiavi da Let’s Encrypt se il DNS non punta ad esso. Quindi dovresti eseguire il backup, trasferire il backup, cambiare il DNS al nuovo server e poi ricostruire.

Se vuoi ridurre al minimo i tempi di inattività, ti consiglio di Spostare un sito Discourse su un altro VPS con rsync. Questo copia le tue chiavi SSL in modo che il nuovo server sia pronto quando esegui la ricostruzione.

A meno che tu non abbia già aggiornato a Postgres 15 (e forse anche allora), quello che consiglio (quello che faccio) è --exclude postgres*, ricostruire, e poi eseguire il backup del sito principale e ripristinare quel backup sul nuovo server. Una volta ripristinato, cambia il DNS. Le istruzioni di rsync prevedono lo spegnimento del database in modo da poter copiare i file grezzi del database. Ci sono alcuni casi in cui questo non funziona molto bene, quindi per lo più faccio un backup solo del database e lo ripristino.

MODIFICA: Ho aggiunto questo all’OP.

@Discourse

Disclaimer aggiunto da @pfaffman 2025-09-12T05:00:00Z.

Queste istruzioni non funzionano bene ora perché stai usando https e Let’s Encrypt, che richiedono che il nuovo server abbia il DNS puntato ad esso in modo che possa richiedere le chiavi. Quello che consiglio è seguire Spostare un sito Discourse su un altro VPS con rsync (forse usando --exclude postgres* e poi eseguendo il backup e il ripristino del database dalla riga di comando.) Questo è intelligente poiché se sai come fare, puoi modificare il tuo DNS locale per puntare al nuovo server in modo da poter testare che funzioni mentre il resto di Internet vede ancora il vecchio sito.

[nathank (Nathan Kershaw)]

Grazie Jay! Mi sono chiesto perché fossi rimasto un po’ bloccato con tutta la questione URL / DNS / LetsEncrypt in (recente) passato quando ho tentato di seguire le istruzioni nell’OP.

Alla fine ci sono riuscito usando un sottodominio per il nuovo sito, assicurandomi che il mio sito ripristinato sul nuovo server funzionasse, e poi facendo un rapido cambio DNS / URL. Ma è stato tutto un po’ incerto / doloroso (specialmente il whack-a-mole di rimappatura dopo!).

Ora capisco perché dovevo fare tutto questo. Ed è utile sapere che rsync può aggirare alcuni dei punti dolenti.

Penso che delle istruzioni chiare qui aiuterebbero davvero gli altri, dato che al momento è un po’ confuso - e non sono sicuro del modo migliore per farlo in futuro. La tua clausola di esclusione di responsabilità potrebbe forse essere integrata nell’intero OP come una riscrittura (magari da @SaraDev?).

[pfaffman (Jay Pfaffman)]

@nathank

Mi sono chiesto perché mi sono bloccato un po’ su tutta la questione URL / DNS / LetsEncrypt in (recente) passato quando ho cercato di seguire le istruzioni nell’OP.

Ecco perché ho suggerito di non seguire queste istruzioni.

@nathank

Penso che alcune istruzioni chiare qui aiuterebbero davvero gli altri, dato che al momento è un po’ confuso

Penso che ignorare o eliminare queste istruzioni e seguire l’argomento rsync che ho collegato aiuterebbe le persone.

Mi sfugge qualcosa?