Restaurer une sauvegarde via la ligne de commande

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

Ces instructions ont fonctionné pour nous permettre de restaurer à partir d’une sauvegarde, mais nous avons dû modifier la commande discourse restore pour :

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

(mon exemple utilise le nom de fichier de l’exemple ci-dessus) afin que la restauration trouve les sauvegardes que nous avions placées dans le répertoire /var/discourse/shared/standalone/backups/default (par opposition aux sauvegardes stockées sur s3).

[Isambard]

La reconstruction après restauration est-elle nécessaire ?

De plus, j’ai restauré sur un nouveau serveur où il y a un proxy inverse NGINX qui transmet ensuite à Discourse en amont. J’ai donc désactivé le SSL sur Discourse, mais j’ai remarqué pendant la restauration :

Remapping 'https://example.com' to 'http://example.com'

Est-ce que cela remappe tous les liens internes ? Est-il aussi simple de défaire cela que discourse remap http://example.com https://example.com ?

[pfaffman (Jay Pfaffman)]

@Isambard

La reconstruction après restauration est-elle nécessaire ?

Non.

@Isambard

Est-ce que cela remappe tous les liens internes ?

Il semble que oui. Oui, vous pouvez les remapper.

Vous devriez définir la variable force_https.

[pinder99 (Pushpender Singh)]

si la sauvegarde fait 15 Go, combien d’espace est nécessaire pour la restaurer ?

[pfaffman (Jay Pfaffman)]

Est-ce juste la base de données ou les téléchargements aussi ?

Probablement 3 à 5 fois plus.

[pinder99 (Pushpender Singh)]

c’est base de données+téléchargement 15 Go, j’ai 20 Go d’espace sur un disque dur de 60 Go mais la restauration échoue à chaque fois, j’ai besoin d’au moins 50-60 Go d’espace pour restaurer ?

[pfaffman (Jay Pfaffman)]

Vous avez besoin de suffisamment d’espace pour la sauvegarde, les téléversements et la base de données non compressée.

Vous pourriez essayer de restaurer d’abord une sauvegarde de base de données uniquement, puis copier les téléversements à la main avec rsync.

[Ethsim2 (Ethan)]

J’ai vérifié mon compte administrateur sur l’auto-hébergement et j’ai téléchargé une sauvegarde .sql.gz, pas une .tar.gz.

La restauration dans l’interface utilisateur n’est pas fructueuse, j’ai donc effectué la restauration depuis la ligne de commande en utilisant « Restaurer la sauvegarde », avec un résultat [FAILED] à la fin du processus discourse restore. Le fichier d’entrée provenant d’un hébergement officiel étant .tar.gz pourrait-il être la cause de l’échec du processus ?

Mon hébergement officiel date de quelques jours, et mon auto-hébergement a commencé à fonctionner correctement aujourd’hui après avoir modifié les valeurs SMTP dans container.yml.

[pfaffman (Jay Pfaffman)]

Vous devrez inclure l’erreur que vous avez reçue. Le nom du fichier contient des informations de version, donc si vous avez renommé le fichier, vous devrez probablement le renommer à nouveau, en modifiant uniquement les mots au début du nom du fichier.

[helmi]

Existe-t-il une documentation pour discourse restore quelque part ? car il semble y avoir un commutateur --location local, je suppose qu’il y en aurait aussi un pour S3 ?

Je cherche à restaurer à partir de sauvegardes situées sur S3 et éviter de devoir les télécharger manuellement au préalable.

EDIT : tant pis. Je viens de découvrir que discourse restore --location s3 $filename semble fonctionner tout à fait bien.

[Jagster (Jakke Lehtonen)]

Parce que j’ai activé S3 dans app.yml, une simple commande discourse restore <nom_de_fichier> a fonctionné parfaitement.

Je pense que si vous recherchez backup restore s3, vous trouverez le bon article.

[Ethsim2 (Ethan)]

Salut, j’ai terminé ce processus en utilisant s3(-cli) comme mon scp et un changement de fournisseur de messagerie sortante de MailGun à Brevo

Depuis la restauration, je ne trouve aucun moyen de supprimer la bannière ?

[Moin]

@Discourse

Le processus de restauration définit automatiquement le paramètre disable emails sur « non-staff », de sorte que les e-mails ne sont pas envoyés aux utilisateurs de votre site tant que vous n’êtes pas prêt.

Le moyen le plus simple de supprimer la bannière est d’activer les e-mails dans les paramètres du site

[pfaffman (Jay Pfaffman)]

@Moin

La façon la plus simple de supprimer la bannière est d’activer les e-mails dans les paramètres du site.

C’est vrai. Vous pourriez aussi la masquer avec du CSS !

[Moin]

Vrai. J’étais un peu prudent en recommandant cela car j’ai dû penser à Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

J’étais un peu prudent en recommandant cela car j’ai dû penser à le thème Air masque l’avertissement « e-mail sortant désactivé »

Chaque fois que vous restaurez une sauvegarde, l’e-mail est automatiquement désactivé pour les non-membres du personnel. J’imagine que cela a été ajouté au code juste quelques fois après qu’une restauration a été effectuée sur un serveur de test qui a commencé à inonder ses utilisateurs de notifications pour un serveur dont ils n’étaient pas censés avoir connaissance.

J’ai mis à jour l’OP en conséquence :

@Discourse

Activer l’e-mail

Lorsqu’une sauvegarde est restaurée, les e-mails sortants pour les non-membres du personnel sont désactivés. Vous ne voulez pas que votre serveur de test, votre nouveau serveur ou un serveur pour lequel vous venez de restaurer une sauvegarde pour une autre raison commence à envoyer des e-mails à vos utilisateurs ! Changez le paramètre du site « disable_emails » pour réactiver l’e-mail.

[thoka (Thomas Kalka)]

Note pour le guide pratique :

Si vous restaurez régulièrement des sauvegardes à des fins de test et que votre serveur de test est correctement configuré pour envoyer des e-mails à un service d’e-mails de débogage (comme GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.), vous pourriez vouloir activer les e-mails via un script :

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

[pfaffman (Jay Pfaffman)]

Dans ce cas, vous voudrez peut-être définir DISCOURSE_DISABLE_EMAILS sur non dans votre app.yml. (et aussi DISCOURSE_ENABLE_RESTORE pour faciliter la restauration)