Ein Backup über die Kommandozeile wiederherstellen

[Discourse]

Dieser Leitfaden erklärt, wie Sie ein Discourse-Backup über die Befehlszeile wiederherstellen, ohne die Discourse-Web-UI zu verwenden.
Erforderliche Benutzerebene: Administrator
Konsolenzugriff erforderlich

Hier erfahren Sie, wie Sie ein Discourse-Backup über die Befehlszeile wiederherstellen, ohne jemals die Discourse-Web-UI zu starten. Dies ist nützlich, wenn Sie Server wechseln.

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie die folgenden Schritte abgeschlossen haben:

1. Laden Sie die neueste Sicherungsdatei von der Quell-Discourse-Instanz herunter.
2. Richten Sie die Ziel-Discourse-Instanz ein, indem Sie ./discourse-setup ausführen oder Ihre vorhandene app.yml kopieren.
3. Stellen Sie sicher, dass die Ziel-Discourse-Instanz auf der neuesten Version ist. Aktualisieren Sie sie bei Bedarf.

Die Sicherung übertragen

1. Stellen Sie per SSH eine Verbindung zum Zielserver her oder erstellen Sie den Sicherungsordner dort auf andere Weise:

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

2. Laden Sie Ihre Sicherungsdatei auf den Zielserver hoch.

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

Stellen Sie sicher, dass Sie die Pfade, Dateinamen und Servernamen durch die von Ihnen verwendeten ersetzen – aber Sie möchten, dass die Sicherungsdatei hier landet:

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

Sie können Ihre Discourse-Sicherungsdatei auch von beliebten Web-Speicherseiten wie Google Drive, Dropbox, OneDrive usw. hoch- und herunterladen – Sie müssen die spezifischen Befehlszeilenanweisungen basierend auf Ihrem bevorzugten Web-Speicheranbieter nachschlagen.

ÄNDERN SIE DEN DATEINAMEN DER SICHERUNG NICHT! Discourse behandelt den Dateinamen der Sicherung als Metadaten. Wenn Sie den Dateinamen ändern, funktioniert die Wiederherstellung nicht. Behalten Sie den ursprünglichen Dateinamen bei.

Ersetzen Sie /path/to/backup/discourse-xyz.tar.gz durch den lokalen Pfad Ihrer Sicherungsdatei und ersetzen Sie \u003cserver_ip_address\u003e durch die IP-Adresse des Zielservers.

Wenn Nginx als Reverse-Proxy verwendet wird, stellen Sie sicher, dass alle Pfade zur Sicherung vom Container lesbar sind und Nginx die .sock-Datei lesen kann.

Die Sicherung wiederherstellen

1. Greifen Sie auf Ihren Zielserver zu und navigieren Sie zum Discourse-Ordner:

cd /var/discourse

2. Rufen Sie den Discourse Docker App-Container auf:

./launcher enter app

3. Aktivieren Sie die Wiederherstellungsfunktion:

discourse enable_restore

4. Stellen Sie die Sicherungsdatei wieder her:

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

Tipp: Wenn Sie discourse restore ohne Dateinamen ausführen, werden alle verfügbaren Sicherungsdateien aufgelistet.

Wenn die Einstellung backup_location Ihrer Website so konfiguriert ist, dass S3 verwendet wird, Sie die Sicherungsdatei aber manuell in das lokale Dateisystem hochgeladen haben, müssen Sie --location local angeben:

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

Verwenden Sie auf ähnliche Weise --location s3, um die Wiederherstellung direkt aus einer S3-Sicherung vorzunehmen, ohne sie vorher herunterzuladen.

5. Beenden Sie den Discourse Docker App-Container:

exit

Erneut erstellen (Rebuild)

Nachdem Sie die Sicherung wiederhergestellt haben, können Sie die Zielinstanz erneut erstellen, um sicherzustellen, dass alle Einstellungen und Konfigurationen korrekt angewendet werden.

Jetzt ist ein guter Zeitpunkt, um /var/discourse/containers/app.yml mit vollständigem HTTPS, zusätzlichen Plugins oder CDN-Konfigurationen zu aktualisieren. Vergleichen Sie die app.yml-Konfiguration beider Instanzen, um sicherzugehen!

cd /var/discourse
./launcher rebuild app

E-Mail aktivieren

Wenn eine Sicherung wiederhergestellt wird, wird der ausgehende Mailverkehr für Nicht-Mitarbeiter deaktiviert. Sie möchten nicht, dass Ihr Testserver, neuer Server oder ein Server, für den Sie aus einem anderen Grund eine Sicherung wiederhergestellt haben, anfängt, Ihre Benutzer anzuschreiben! Ändern Sie die Website-Einstellung disable_emails auf „no“, um E-Mails wieder zu aktivieren.

Das war’s. Ihr Discourse-Server wurde erfolgreich wiederhergestellt.

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

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)