Sposta la tua istanza Discourse su un server diverso

[Discourse]

Questa è una guida per spostare la tua istanza Discourse da un server all’altro, incluse tutte le impostazioni e i dati. Questa guida si applica alle istanze Discourse self-hosted che utilizzano Docker.

Livello utente richiesto: Amministratore di sistema

Questa procedura comporta modifiche al dominio e al DNS. Assicurati di avere accesso sia al server di origine che a quello di destinazione.

Questa guida ti illustra il processo di migrazione della tua istanza Discourse da un server all’altro, assicurando che i tuoi dati, le impostazioni e la configurazione vengano preservati.

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 su di esso in modo che possa richiedere le chiavi. Ciò che raccomando è seguire Move a Discourse site to another VPS with 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, 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 sito vecchio.

Sommario

Eseguirai i seguenti passaggi chiave in questa guida:

1. Esegui il backup della tua attuale istanza Discourse (server di origine).
2. Trasferisci il file di backup sulla tua istanza Discourse di destinazione (server di destinazione).
3. Ripristina il backup sul server di destinazione.
4. Aggiorna le impostazioni DNS (se applicabile).

Regolazione delle impostazioni DNS (quando richiesto)

Se stai utilizzando lo stesso dominio per il nuovo server, riduci il TTL (time to live) sulla tua voce DNS in anticipo. Ciò garantirà un tempo di inattività minimo durante la propagazione dei record DNS aggiornati. Se utilizzerai un nuovo dominio, questo passaggio può essere omesso.

Accesso e preparazione del server di origine

1. Accedi alla tua istanza Discourse di origine con un account che dispone di privilegi di amministratore.
2. Assicurati che sia il server di origine che quello di destinazione stiano utilizzando:
   • La stessa versione di Discourse.
   • Lo stesso insieme di plugin.
3. Aggiorna la versione di Discourse su entrambi i server visitando /admin/upgrade.

Evita di ripristinare un backup più recente su una versione di Discourse precedente, o versioni PostgreSQL incompatibili, poiché ciò potrebbe causare errori.

Creazione e download del backup

1. Naviga su /admin/backups sulla tua istanza Discourse di origine.
2. Clicca sul pulsante Backup per creare un backup:
   
   
3. Quando richiesto, conferma cliccando su Sì.
4. Una volta completato il backup, vai alla scheda File di backup e individua il backup appena creato.
5. Clicca su Download per ricevere un’email con un link per il download. Clicca sul link nell’email per salvare il file di backup localmente.
   
   

Prima di procedere, esamina il tuo file app.yml per assicurarti che tutte le impostazioni opzionali, come le configurazioni CDN, i plugin installati o il supporto HTTPS, siano coerenti tra il server di origine e quello di destinazione.

Ripristino del backup sul server di destinazione

Per ripristinare il backup tramite la riga di comando, consulta la documentazione pertinente.

1. Accedi come amministratore alla tua istanza Discourse di destinazione.
2. Naviga su /admin/backups/settings e abilita l’impostazione allow restore.
3. Vai su /admin/backups e clicca sulla scheda File di backup. Carica il file di backup che hai scaricato in precedenza cliccando sul pulsante Upload:
   
   
4. Dopo che il caricamento è completato, clicca sul menu ⋮ (altre opzioni) accanto al backup caricato, quindi clicca su Restore (Ripristina):
   
   
5. Conferma cliccando su Sì quando richiesto.

Il processo di ripristino avrà inizio. Potrebbe volerci del tempo a seconda delle dimensioni del tuo database. Dopo il completamento del processo, sarai automaticamente disconnesso.

Finalizzazione e accesso

1. Accedi alla tua istanza Discourse di destinazione con le tue credenziali di amministratore.
2. Se il sito è stato sottoposto a backup utilizzando HTTPS, assicurati che HTTPS sia abilitato sul nuovo server. Se non configurato correttamente, utilizza la console Rails per disabilitare temporaneamente l’impostazione “force https”.
3. Riabilita eventuali configurazioni opzionali modificando il file app.yml e ricostruendo la tua istanza. Questo potrebbe includere:
   • Abilitazione del supporto CDN.
   • Installazione di plugin aggiuntivi.
   • Impostazione delle configurazioni HTTPS.

Problemi comuni e soluzioni

Il file di backup non viene ripristinato

• Verifica che le versioni di Discourse e PostgreSQL corrispondano tra il server di origine e quello di destinazione.

Impossibile accedere dopo il ripristino (con HTTPS abilitato)

• Utilizza la console Rails per disabilitare temporaneamente force https eseguendo:

  SiteSetting.force_https = false
  

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

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?

[Ethsim2 (Ethan)]

Aggiungo qui un caso particolare di migrazione che ho incontrato, nel caso possa essere utile a qualcun altro.

Ho riscontrato un caso particolare con Let’s Encrypt/SSL durante il trasferimento di un’istanza Discourse standalone su un nuovo VPS, quindi ho redatto una descrizione dettagliata della diagnosi e dei passaggi di recupero, nel caso possano risultare utili a chiunque segua questa guida.

Nel mio caso, nginx all’interno di app non avviava perché entrambi i file .cer in /var/discourse/shared/standalone/ssl/ erano diventati file vuoti (zero byte):

PEM_read_bio_X509_AUX() failed

La ricostruzione ha tentato nuovamente l’emissione del certificato e, dopo ripetuti tentativi, ho raggiunto il limite di frequenza dei certificati di Let’s Encrypt. Copiare i file del certificato ancora validi dal server vecchio non era sufficiente, perché l’avvio di app li sostituiva nuovamente con file vuoti.

Ciò che alla fine ha risolto il problema è stato fermare app e copiare sia la directory funzionante /var/discourse/shared/standalone/ssl/ sia lo stato corrispondente di /var/discourse/shared/standalone/letsencrypt/ dal server vecchio, per poi riavviare il container.

Ho documentato la sequenza completa qui:

server_migration_diagnosing_standard_ssl.md

Queste sono note di diagnosi/recupero relative a questa specifica migrazione e non costituiscono una sostituzione della documentazione ufficiale su migrazione o HTTPS.

Esiste anche un argomento Meta più vecchio che copre il relativo modalità di errore con file .cer vuoti:

Let's Encrypt - file *.cer vuoti

Non riesco a connettermi a una nuova installazione standard di 30 minuti (standard 30-minute install). AWS Lightsail, 2 GB di RAM, Ubuntu 18.04 LTS x64 con la porta :443 aperta. Il problema è che i file *.cer di Let’s Encrypt sono vuoti. Perché? Log di nginx root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-r–r-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail …