Backup über die Befehlszeile wiederherstellen

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

Diese Anweisungen funktionierten für uns, um aus einem Backup wiederherzustellen, aber wir mussten den Befehl discourse restore wie folgt ändern:

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

(mein Beispiel verwendet den Dateinamen aus dem obigen Beispiel), damit die Wiederherstellung die Backups finden konnte, die wir im Verzeichnis /var/discourse/shared/standalone/backups/default abgelegt hatten (im Gegensatz zu Backups, die auf S3 gespeichert waren).

[Isambard]

Ist der Wiederaufbau nach der Wiederherstellung notwendig?

Außerdem habe ich auf einem neuen Server wiederhergestellt, auf dem sich ein NGINX-Reverse-Proxy befindet, der dann an den Upstream-Discourse weiterleitet. Daher habe ich SSL auf Discourse deaktiviert, aber ich habe bemerkt, dass während der Wiederherstellung:

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

Werden dadurch alle internen Links neu zugeordnet? Ist es so einfach, dies rückgängig zu machen, wie discourse remap http://example.com https://example.com?

[pfaffman (Jay Pfaffman)]

@Isambard

Ist der Wiederaufbau nach der Wiederherstellung notwendig?

Nein.

@Isambard

Wird dies alle internen Links neu zuordnen?

Sieht so aus. Ja, du kannst sie neu zuordnen.

Du solltest die Variable force_https setzen.

[pinder99 (Pushpender Singh)]

Wenn das Backup 15 GB beträgt, wie viel Speicherplatz wird dann für die Wiederherstellung benötigt?

[pfaffman (Jay Pfaffman)]

Ist das nur die Datenbank oder auch Uploads?

Wahrscheinlich 3-5x so viel.

[pinder99 (Pushpender Singh)]

Es ist Datenbank+Upload 15 GB, ich habe 20 GB Speicher auf einer 60 GB Festplatte, aber die Wiederherstellung schlägt jedes Mal fehl. Ich benötige mindestens 50-60 GB Speicher für die Wiederherstellung?

[pfaffman (Jay Pfaffman)]

Sie benötigen genügend Speicherplatz für das Backup, die Uploads und die unkomprimierte Datenbank.

Sie könnten versuchen, zuerst nur ein Datenbank-Backup wiederherzustellen und dann die Uploads manuell mit rsync zu kopieren.

[Ethsim2 (Ethan)]

Ich habe mein Admin-Konto auf Self-Host verifiziert und ein .sql.gz-Backup hochgeladen, kein .tar.gz.

Die Wiederherstellung über die Benutzeroberfläche ist nicht erfolgreich, daher habe ich den Prozess über die Befehlszeile mit „Backup wiederherstellen“ durchgeführt. Am Ende des discourse restore-Prozesses kam die Meldung [FAILED]. Könnte die Eingabedatei von einem offiziellen Hoster, die .tar.gz ist, den Prozess zum Erfolg führen?

Mein offizieller Hoster ist ein paar Tage alt, und mein Self-Host funktionierte heute nach dem Ändern der SMTP-Werte in container.yml wieder richtig.

[pfaffman (Jay Pfaffman)]

Sie müssen den Fehler angeben, den Sie erhalten haben. Der Dateiname enthält Versionsinformationen. Wenn Sie die Datei umbenannt haben, müssen Sie sie wahrscheinlich zurückbenennen und nur die Wörter am Anfang des Dateinamens ändern.

[helmi]

Gibt es irgendwo eine Dokumentation für discourse restore? Da es anscheinend einen --location local-Schalter gibt, nehme ich an, es gäbe auch einen für S3?

Ich möchte von auf S3 gespeicherten Backups wiederherstellen und vermeiden, sie vorher manuell herunterzuladen.

BEARBEITUNG: NVMD. Ich habe gerade herausgefunden, dass discourse restore --location s3 $filename scheinbar ganz gut funktioniert.

[Jagster (Jakke Lehtonen)]

Da ich S3 in app.yml aktiviert habe, hat ein reines discourse restore <Dateiname> einwandfrei funktioniert.

Ich denke, wenn Sie nach backup restore s3 suchen, finden Sie den richtigen Beitrag.

[Ethsim2 (Ethan)]

Hallo, ich habe diesen Prozess mit s3(-cli) als mein scp und einer Änderung des ausgehenden Mail-Anbieters von MailGun zu Brevo abgeschlossen

Seit der Wiederherstellung kann ich das Banner nicht mehr entfernen?

[Moin]

@Discourse

Der Wiederherstellungsprozess setzt die Einstellung disable emails automatisch auf „non-staff“, sodass E-Mails erst an die Benutzer Ihrer Website gesendet werden, wenn Sie bereit sind.

Der einfachste Weg, das Banner zu entfernen, ist die Aktivierung von E-Mails in den Website-Einstellungen

[pfaffman (Jay Pfaffman)]

[quote=“Moin, post:71, topic:108034”]Der einfachste Weg, das Banner zu entfernen, ist, E-Mails in den Website-Einstellungen zu aktivieren.
[/quote]

Stimmt. Man könnte es auch mit CSS ausblenden!

[Moin]

Wahr. Ich war etwas vorsichtig, dies zu empfehlen, weil ich an Air theme hides "outgoing email disabled" warning denken musste

[pfaffman (Jay Pfaffman)]

@Moin

Ich war etwas vorsichtig mit dieser Empfehlung, weil ich an Air-Theme blendet Warnung „ausgehende E-Mails deaktiviert“ aus denken musste.

Jedes Mal, wenn Sie ein Backup wiederherstellen, werden E-Mails für Nicht-Mitarbeiter automatisch deaktiviert. Ich stelle mir vor, dass dies ein paar Mal in den Code aufgenommen wurde, nachdem ein Backup auf einem Testserver wiederhergestellt wurde, der begann, seine Benutzer mit Benachrichtigungen für einen Server zu überfluten, von dem sie nichts wissen sollten.

Ich habe den OP entsprechend aktualisiert:

@Discourse

E-Mail aktivieren

Wenn ein Backup wiederhergestellt wird, werden ausgehende E-Mails für Nicht-Mitarbeiter deaktiviert. Sie möchten nicht, dass Ihr Testserver, Ihr neuer Server oder ein Server, für den Sie aus irgendeinem anderen Grund gerade ein Backup wiederhergestellt haben, Ihre Benutzer per E-Mail kontaktiert! Ändern Sie die Website-Einstellung „disable_emails“, um E-Mails wieder zu aktivieren.

[thoka (Thomas Kalka)]

Hinweis für die Anleitung:

Wenn Sie regelmäßig Backups zu Testzwecken wiederherstellen und Ihr Testserver richtig konfiguriert ist, um E-Mails an einen Debugging-E-Mail-Dienst (wie GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.) zu senden, möchten Sie möglicherweise E-Mails per Skripting aktivieren:

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

[pfaffman (Jay Pfaffman)]

In diesem Fall sollten Sie in Ihrer app.yml DISCOURSE_DISABLE_EMAILS auf nein setzen. (und auch DISCOURSE_ENABLE_RESTORE, um Wiederherstellungen zu erleichtern)