So sichern und wiederherstellen Sie einen gesamten /var/discourse-App-Ordner?

Wie man den gesamten Ordner /var/discourse sichert und wiederherstellt?

Aufgrund von Problemen mit dem üblichen Sicherungs- und Wiederherstellungsprozess habe ich mich gefragt, ob ich den gesamten Ordner /var/discourse sichern und auf einem anderen Server wiederverwenden könnte. So habe ich es gemacht…

Auf dem Produktionsserver:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

Auf dem Staging-Server:

Docker installieren.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

Aber es erscheint 502 Bad Gateway.

Ich versuche, dem auf den Grund zu gehen.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432): down
root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: The cluster is owned [FAILoup id 116 which does not exist ... failed!
 failed!

Vermutlich einige Fixes:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

Aber das hat nicht geholfen.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" exited with status 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: database files are incompatible with server 2020-05-25 10:20:10.501 UTC [603] DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: could not start server Examine the lo[FAILput. ... failed!
 failed!

Warum werden diese Berechtigungsprobleme bei den Dateien eingeführt?

Warum wird PostgreSQL von Version 10 auf Version 12 aktualisiert, indem man einfach den gesamten Ordner von einem Server auf einen anderen kopiert? Ich muss etwas falsch machen.

Könntet ihr mir bitte Anweisungen geben, wie man die gesamte Discourse-App auf einem Server sichert und auf einen anderen Server verschiebt?

Verwendet Discourse Phabricator nicht?

Tippfehler. Ich meinte Discourse. Tippfehler korrigiert. Die ursprüngliche Frage bleibt bestehen.

Das verschiebt nicht den gesamten Ordner /var/discourse. Mir sind diese Anweisungen bekannt, diese funktionieren jedoch nicht für mich. Daher wollte ich eine vollständigere 1-zu-1-„Hardcopy“-Methode zum Sichern.

Sie können den Container herunterfahren und das gesamte Verzeichnis auf einen neuen Server kopieren, wobei die Verzeichnisse tmp, backup und cache ausgeschlossen werden (und ich glaube, es gibt noch eines? ). Das sollte funktionieren. Ich habe dies kürzlich gemacht, meiner Erinnerung nach aus einem ähnlichen Grund.

Sie müssen jedoch unbedingt das Problem mit dem beschädigten Index lösen.

Ich denke, die Docker-Version führt zu Unterschieden. (Was dann zum Fehler führt.)

Originalserver
docker-engine 17.05.0~ce-0~debian-stretch

vs neuerer (Stage-)Server
docker-engine 17.05.0~ce-0~debian-stretch

Das führt dazu, dass der Originalserver PostgreSQL 10 hat, während der neuere (Stage-)Server bereits PostgreSQL 12 hat.

Ist das zwingend erforderlich? Gibt es einen einfacheren Weg? Warum sollte es notwendig sein, nicht alles exakt so zu kopieren und wiederherzustellen?

Das führt zu Berechtigungsproblemen, die ich nicht erklären kann. Es sollte möglich sein, ohne die Berechtigungen zu beschädigen zu kopieren. Und ich bin mir auch nicht sicher, ob ich alle Berechtigungsprobleme vollständig behoben habe.

Ja, aber ich denke, es wäre viel sicherer, erst damit fortzufahren, sobald ich zumindest reproduzieren kann, was aktuell noch funktioniert.

[quote=“adrelanos, Beitrag: 5, Thema: 152598, full:true”]
Das verschiebt nicht den gesamten Ordner /var/discourse. Mir sind diese Anweisungen bekannt, diese [funktionieren] (Restore problem: relation "theme_fields" does not exist) für mich nicht. Daher wollte ich eine vollständigere 1-zu-1-Methode für ein „hartes

Gerne, du kannst alles mit rsync -rav kopieren.

Du hast vielleicht mehr Erfolg, wenn du deine App so änderst, dass sie die postgres 10-Vorlage verwendet. Aber es klingt so, als wäre das Einfachste, deine Datenbank direkt vor Ort zu reparieren.

Du kannst den Ordner verschieben, das funktioniert einwandfrei. Es ist nur nicht der bevorzugte Weg, da er den discourse-setup umgeht und alle dabei durchgeführten Anpassungen und Tests überspringt.

In meinem Fall hat es nicht funktioniert, da das aktualisierte Docker zu einer neueren PostgreSQL-Version im Docker-Container führte, was wiederum zu einem unbrauchbaren Forum aufgrund von PostgreSQL-Migrationsproblemen führte. Ich musste von PostgreSQL auf die PostgreSQL 10-Vorlage wechseln.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix erklärt die Details gut.

Ich vermute, ich müsste auch den /var/docker-Ordner sichern und wiederherstellen. Aber selbst das hat eine Chance zu scheitern, wegen folgendem:

[quote=“neounix, Beitrag: 8, Thema: 152598”]
Allerdings bietet diese Methode selbst mit dem „älteren Unix-Weg

Du befindest dich auf einem Irrweg. Wenn ich du wäre, würde ich mich darauf konzentrieren, dein ursprüngliches Problem mit Backup/Restore zu lösen.

Vielleicht sogar ein :rat: :rat: :rat: Loch.

Zustimmung… definitiv…

@adrelanos

Es gibt keine „Probleme

Lieber @adrelanos,

Zurück zu deiner ursprünglichen Frage in Beitrag #1 oben: Aus reiner Neugier war ich mit meiner früheren Antwort nicht wirklich zufrieden und habe heute einige Tests durchgeführt.

Kurz gesagt, habe ich bestätigt, dass wir docker save (für die Basis- und App-Container) sowie tar für das Verzeichnis /var/discourse verwenden können, um die App vollständig zu speichern, zu übertragen (zu sichern) und wiederherzustellen.

Ich bin mir zu 99,99 % sicher, dass diese Methode nicht „offiziell unterstützt“ wird, aber du verdienst eine Antwort, also habe ich dies für dich getestet:

Im Wesentlichen sind hier die Schritte, zusammengefasst:

  1. Speichere deine Container mit docker save.

Zum Beispiel, wenn du eine Standalone-App betreibst, kannst du den Basis- und den App-Container so speichern (basierend auf deiner Konfiguration):

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

und zusätzlich:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. Du kannst auch das Verzeichnis /var/discourse tarpen, wie du erwähnt hast:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

und anschließend deine Docker-Tar-Dateien nach Belieben gzipen und archivieren:

gzip /tmp/my.discourse.docker*.tar
  1. … und du kannst diese Dateien auf einen anderen Server verschieben, auf demselben Server archivieren oder alles andere tun, was du möchtest. Kehre dann die Schritte um und starte die Discourse-App ohne Probleme.

Ich habe dies bestätigt, indem ich es einfach „gemacht“ habe: Ich habe alle Container-Images und das Verzeichnis /var/discourse gelöscht. Im Grunde habe ich alles gelöscht und von den Sicherungen aus neu gestartet (kein Neuaufbau nötig, da sich die Domain usw. nicht geändert hat).

Zum Beispiel kannst du zum Wiederherstellen die oben gespeicherten Docker-Images laden, etwa so:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. Entpacke dann dein ursprüngliches Verzeichnis /var/discourse:
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. Als Nächstes musst du deine Images überprüfen, um sicherzustellen, dass sie korrekt gekennzeichnet sind:
docker images
  1. Falls die Images nicht korrekt gekennzeichnet sind, stelle sicher, dass du sie richtig taggst, zum Beispiel für dein App-Image:
docker tag 58ffc74989af local_discourse/app:latest
  1. Dann machst du einfach Folgendes:
cd /var/discourse
./launcher start app

Und es funktioniert einwandfrei. Ich habe es gerade zweimal getestet.

Ich hoffe, das hilft.

FWIW: Ich habe diese Methode auf zwei verschiedene Arten ausprobiert, indem ich die oben beschriebene Sicherungsmethode angewendet und alle Docker-Container, Images und das Verzeichnis /var/discourse gelöscht habe (jedes Mal alles vollständig zerstört).

In jedem Fall konnte ich meine gespeicherten Docker-Images laden, das Verzeichnis /var/discourse entpacken, ./launcher start app ausführen und Discourse startete fehlerfrei hoch. Zum Beweis konnte ich über die Benutzeroberfläche eine „normale Sicherung“ durchführen, was zeigte, dass alles in Ordnung war.

Ich bin nicht sicher, ob dies deine Frage beantwortet (und habe nicht an den Diskussionen oder dem Upgrade von Postgres 10 auf 12 teilgenommen); aber bezüglich deiner Frage, ob man die App einfach durch Tarpen als Sicherung erstellen und wiederherstellen kann, lautet die Antwort ja, aber du musst nicht nur das Verzeichnis /var/discourse archivieren, sondern auch deine Images mit docker save sichern.

Die größte „Falle“ besteht darin, die Repository-Namen und Tags deiner Images korrekt zu halten; dann sollte alles funktionieren.

Ich hoffe, dies beantwortet deine Frage zumindest teilweise:

Wie kann ich den gesamten Ordner /var/discourse einer Discourse-App sichern und wiederherstellen?

Die Antwort lautet: Du musst sowohl deinen Ordner als auch deine Docker-Images archivieren (wie im obigen Beispiel), wobei du docker save für die Images (zum Sichern) und docker load zum Wiederherstellen verwendest.

Denke daran, dass diese Methode nicht offiziell unterstützt wird; aber aus Neugier wollte ich herausfinden, wie man es aus der Perspektive eines Systemadministrators macht, und festgestellt, dass es einfacher ist, als meine früheren Antworten nahelegten.

Hinweis 1:

Du solltest möglicherweise alle Sicherungen aus deinem Verzeichnis backups/default (außerhalb des Verzeichnisbaums) verschieben, bevor du alles in /var/discourse/ tarpst, und diese Sicherungen separat aufbewahren, da diese Dateien so groß sind…

Hinweis 2:

Diese Art der Sicherung wird nicht unterstützt und wird daher für die meisten Discourse-Systemadministratoren nicht empfohlen. Ich empfehle Benutzern, die empfohlene (und offiziell unterstützte) Methode für die Sicherung und Wiederherstellung von Discourse zu befolgen.

Bleib neugierig!

Pass gut auf dich auf.


Für weitere Details, einschließlich Screenshots, siehe bitte meinen vollständigen Beitrag hier:

Das ist ein hervorragender Ansatz! Danke!

Ein Problem beim Wiederherstellungsserver.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: data directory “/shared/postgres_data” hat falsche Berechtigungen
2020-06-18 13:33:56.434 UTC [127] HINT: Der Server muss vom Benutzer gestartet werden, dem das Datenverzeichnis gehört.
./run: 3: echo: echo: I/O-Fehler
2020-06-18 13:33:57.448 GMT [128] LOG: fehlende Konfigurationsdatei “/shared/postgres_data/postgresql.auto.conf” wird übersprungen


Das könnte an fehlenden tar-Optionen liegen? Ich habe -p und -s während der Extraktion hinzugefügt, aber das hat nicht geholfen.

Ursprungsserver (außerhalb von Docker):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

Ursprungsserver (innerhalb von Docker (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


Wiederherstellungsserver außerhalb von Docker:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

Wiederherstellungsserver innerhalb von Docker:

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app würde es beheben, aber das ist nicht der Punkt.

Eine Idee?

Ich glaube, du hast docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735 gemeint, basierend auf deinem Wiederherstellungsprozess. Wie auch immer, gute Erklärung!

Aber wie du gesagt hast, glaube ich nicht, dass dies ein offiziell unterstützter Ansatz ist (aber ich glaube auch nicht, dass es etwas anderes gibt, das Fehler verursachen könnte, es sei denn, das Discourse-Team beginnt, mehr als ein Basis-Image im Wiederherstellungsprozess zu verwenden).

[quote=“adrelanos, Beitrag: 15, Thema: 152598”]
FATAL: Das Datenverzeichnis „/shared/postgres_data

Eine Methode, die ich verwendet habe und die kein docker save oder ein vollständiges Tar+Entpacken von /var/discourse erfordert: