Ripristinare un backup dalla riga di comando

[Discourse]

This guide explains how to restore a Discourse backup from the command line without using the Discourse web UI.

Required user level: Administrator

Console access required

Here’s how to restore a Discourse backup from the command line, without ever booting the Discourse web UI. This is handy when you’re moving servers.

Prerequisites

Before you start, make sure you complete the following steps:

1. Download the latest backup file from the source Discourse instance.
2. Bootstrap the destination Discourse instance by running ./discourse-setup or copying your existing app.yml.
3. Ensure the destination Discourse instance is on the latest version. Update it if necessary.

Transfer the backup

1. SSH into the destination server, or otherwise create the backup folder there:

mkdir -p /var/discourse/shared/standalone/backups/default

2. Upload your backup file to the destination server.

scp /path/to/backup/backup.tar.gz root@192.168.1.1:/var/discourse/shared/standalone/backups/default

Be sure to replace the paths, filenames, and server names with the ones you are using – but you do want the backup file to end up in:

/var/discourse/shared/standalone/backups/default

You can also upload and download your Discourse backup file from popular web storage sites such as Google Drive, Dropbox, OneDrive, etc – you’ll need to look up the specific command line instructions based on your preferred web storage provider.

DO NOT CHANGE THE FILENAME OF THE BACKUP! Discourse treats the backup filename as metadata, so if you change the filename, restoring will not work. Stick with the original file name.

Replace /path/to/backup/discourse-xyz.tar.gz with the local path of your backup file, and replace <server_ip_address> with the IP address of destination server.

If Nginx is used as reverse proxy make sure all paths to the backup are readable by the container and Nginx can read the .sock file.

Restore the backup

1. Access your destination server and navigate to the Discourse folder:

cd /var/discourse

2. Enter the Discourse Docker app container:

./launcher enter app

3. Enable restore functionality:

discourse enable_restore

4. Restore the backup file:

discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz

5. Exit the Discourse Docker app container:

exit

Rebuild

After restoring the backup, you may choose to rebuild the destination instance to ensure all settings and configurations are applied correctly.

Now is a good time to update /var/discourse/containers/app.yml with full HTTPS, additional plugins or CDN configuration. Compare the app.yml configuration of both instances to make sure!

cd /var/discourse
./launcher rebuild app

Enable Email

When a backup is restored, outgoing mail for non-staff is disabled. You don’t want your test server, new server, or server that you just restored a backup for some other reason to start emailing your users! Change site setting “disable_emails” to re-enable email.

That’s it. Your Discourse server is successfully restored.

Last edited by @pfaffman 2025-05-18T19:32:40Z

Check document

Perform check on document:

[gregcaporaso]

Queste istruzioni hanno funzionato per il ripristino dal backup, ma abbiamo dovuto modificare il comando discourse restore in:

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

(il mio esempio utilizza il nome del file dall’esempio sopra) per far sì che il ripristino trovasse i backup che avevamo inserito nella directory /var/discourse/shared/standalone/backups/default (a differenza dei backup archiviati su s3).

[Isambard]

La ricostruzione dopo il ripristino è necessaria?

Inoltre, ho ripristinato su un nuovo server dove c’è un proxy inverso NGINX che poi inoltra al discourse upstream. Pertanto, ho disabilitato SSL su discourse, ma ho notato che durante il ripristino:

Rimappatura di 'https://example.com' in 'http://example.com'

Questa rimappatura riguarda tutti i link interni? È semplice annullare questa operazione con discourse remap http://example.com https://example.com?

[pfaffman (Jay Pfaffman)]

@Isambard

La ricostruzione dopo il ripristino è necessaria?

No.

@Isambard

Questo rimappa tutti i collegamenti interni?

Sembra di sì. Sì, puoi rimapparli.

Dovresti impostare la variabile force_https.

[pinder99 (Pushpender Singh)]

Se il backup è di 15 GB, quanto spazio è necessario per ripristinare?

[pfaffman (Jay Pfaffman)]

È solo il database o anche i caricamenti?

Probabilmente 3-5 volte tanto.

[pinder99 (Pushpender Singh)]

è database+upload 15gb, ho 20gb di spazio su HD da 60gb ma il ripristino fallisce ogni volta, ho bisogno di almeno 50-60gb di spazio per ripristinare?

[pfaffman (Jay Pfaffman)]

È necessario disporre di spazio sufficiente per il backup, i caricamenti e il database non compresso.

Potresti provare prima a ripristinare solo il backup del database e quindi copiare i caricamenti manualmente con rsync.

[Ethsim2 (Ethan)]

Ho verificato il mio account amministratore sull’host autonomo e ho caricato un backup .sql.gz, non un .tar.gz.

Il ripristino nell’interfaccia utente non è proficuo, quindi l’ho eseguito dalla “Ripristina il backup” dalla riga di comando, ottenendo [FAILED] alla fine del processo discourse restore, potrebbe il file di input da un hosting ufficiale essere .tar.gz causare il superamento del processo?

Il mio hosting ufficiale ha pochi giorni e il mio host autonomo ha iniziato a funzionare correttamente oggi dopo aver modificato i valori SMTP in container.yml.

[pfaffman (Jay Pfaffman)]

Dovrai includere quale errore hai ricevuto. Il nome del file contiene informazioni sulla versione, quindi se hai rinominato il file, probabilmente dovrai rinominarlo di nuovo, modificando solo le parole all’inizio del nome del file.

[helmi]

C’è qualche documentazione per discourse restore da qualche parte? Poiché sembra esserci un’interruttore --location local, presumo ci sia anche uno per S3?

Sto cercando di ripristinare da backup situati su S3 evitando di doverli scaricare manualmente in anticipo.

MODIFICA: niente. Ho scoperto che discourse restore --location s3 $nomefile sembra funzionare abbastanza bene.

[Jagster (Jakke Lehtonen)]

Poiché ho abilitato S3 in app.yml, un semplice discourse restore <filename> ha funzionato perfettamente.

Penso che se cerchi backup restore s3 troverai il post giusto.

[Ethsim2 (Ethan)]

Ciao, ho completato questo processo utilizzando s3(-cli) come mio scp e una modifica del provider di posta in uscita da MailGun a Brevo

Dopo il ripristino non riesco a trovare un modo per rimuovere il banner?

[Moin]

@Discourse

Il processo di ripristino imposta automaticamente l’impostazione disabilita email su “non staff”, in modo che le email non vengano inviate agli utenti del tuo sito finché non sei pronto.

Il modo più semplice per rimuovere il banner è abilitare le email nelle impostazioni del sito

[pfaffman (Jay Pfaffman)]

@Moin

Il modo più semplice per rimuovere il banner è abilitare le email nelle impostazioni del sito

Giusto. Potresti anche nasconderlo con il CSS!

[Moin]

Vero. Ero un po’ cauto nel consigliarlo perché ho dovuto pensare a Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

Ero un po’ cauto nel consigliarlo perché ho dovuto pensare a Air theme nasconde l’avviso “email in uscita disabilitata”

Ogni volta che ripristini un backup, l’email viene automaticamente disabilitata per i non staff. Immagino che questo sia stato aggiunto al codice solo un paio di volte dopo che un ripristino è stato effettuato su un server di test che ha iniziato a inondare i suoi utenti con notifiche per un server di cui non avrebbero dovuto essere a conoscenza.

Ho aggiornato l’OP di conseguenza:

@Discourse

Abilita Email

Quando viene ripristinato un backup, la posta in uscita per i non staff viene disabilitata. Non vorrai che il tuo server di test, il nuovo server o il server per cui hai appena ripristinato un backup per qualsiasi altro motivo inizi a inviare email ai tuoi utenti! Cambia l’impostazione del sito “disable_emails” per riabilitare l’email.

[thoka (Thomas Kalka)]

Nota per la guida:

Se ripristini regolarmente i backup a scopo di test e il tuo server di test è configurato correttamente, per inviare e-mail a un servizio di debug e-mail (come GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.) potresti voler abilitare le e-mail tramite scripting:

docker exec -it app /bin/bash --login \
-c "rails runner 'SiteSetting.disable_emails=\"no\";'"

[pfaffman (Jay Pfaffman)]

In tal caso, potresti voler impostare DISCOURSE_DISABLE_EMAILS su no nel tuo app.yml. (e anche DISCOURSE_ENABLE_RESTORE per rendere più facile il ripristino)