Avatare nach der Wiederherstellung verloren. Wie bekomme ich sie zurück?

Ich habe eine saubere Installation von Discourse durchgeführt und das Backup wiederhergestellt, das noch in derselben Nacht erstellt wurde (mithilfe der Discourse-Oberfläche für Backup und Wiederherstellung).

Das Backup umfasste die Datenbank und die Uploads.

Nach der Wiederherstellung und dem Rebuild der Discourse-App (was ich aufgrund der Konfigurationsänderungen durch die saubere Installation für notwendig hielt), ist ein Problem aufgetreten.

Alle benutzerdefinierten Profilbilder (Avatare) wurden verloren.

Ich vermute, dass dies mit der Bildoptimierung zusammenhängt. Vielleicht müssen Sie etwas anderes tun (neben dem Rebuild der App über den Launcher), um sie wiederherzustellen.

Ich habe jedoch nicht herausgefunden, welcher Schritt fehlt.

Ich habe einen Thread gefunden, in dem es um den Verlust der Standard-Avatare (die mit Discourse ausgelieferten) geht, aber das ist bei uns nicht der Fall: Benutzer, die ihren Avatar nicht geändert und kein Bild hochgeladen haben, haben ihren Buchstaben-Avatar weiterhin.

UPDATE:

Ich habe ausgeführt:
./launcher enter app
rake posts:rebake

Das hat jedoch nicht geholfen.

Vielleicht ist es nicht posts:rebake?

@arinaf,

Seltsamerweise ist mir heute auf einer Einrichtung mit einem Nginx-Reverse-Proxy zu einem Unix-Domain-Socket genau das Gleiche passiert. Alles war in Ordnung, aber die benutzerdefinierten Avatarbilder wurden als Symbole (das Personensymbol) angezeigt, und alle Buchstaben-Avatare waren korrekt.

Während der Fehlersuche bin ich zu einem Standard-Setup mit zwei Containern zurückgekehrt (kein Nginx-Frontend, kein Unix-Socket), und das Problem war verschwunden.

Dann bin ich zurück zum Nginx-Reverse-Proxy-Setup mit Unix-Socket gegangen, und das Problem ist wieder aufgetreten.

Ich weiß nicht weiter … also mache ich erstmal eine Pause :slight_smile:

Offensichtlich sind die Daten in Ordnung, da alles perfekt funktioniert, ohne einen Nginx-Reverse-Proxy, was seltsam ist, weil es ohne ihn einwandfrei funktioniert. LOL. (Es funktionierte in beiden Varianten einwandfrei, und plötzlich trat das seltsame Avatar-Problem auf…)

Das ist genau meine Konfiguration, da ich andere Software in einem Docker-Container ausführe (ein Ghost-Blog). Ich habe Nginx als Reverse-Proxy.

Offensichtlich ist das Wiederherstellen von Backups nicht so einfach, wie es scheint.

Ich habe bereits Rebuilds durchgeführt, da ich dachte, es läge an einem Problem beim Speichern von Thumbnails, leider ohne Erfolg.

Ich werde versuchen, das zu tun, was du sagst, um zu bestätigen, ob das Problem beim Reverse-Proxy liegt (ich habe keine Ahnung, warum dieser stören könnte, aber ich verliere nichts beim Ausprobieren).

Ja… Ich glaube nicht, dass das Problem mit der Backend-Datenbank zusammenhängt, weder beim Wiederherstellen der DB noch beim Rake.

Sobald ich den Reverse-Proxy ausschalte und zwei Container ohne ihn laufen lasse, ist das Problem verschwunden. Da die DB in allen Fällen dieselbe ist, ist es unwahrscheinlich, dass es sich um ein DB-Problem handelt.

Ich bin für 12 Stunden offline, melde mich also später wieder und schaue, was bei deiner Einrichtung passiert ist, @ariznaf.

Betreibst du HTTPS außerhalb des Containers?

Hast du die Seitenquelle untersucht, um zu sehen, welche URLs für die Avatare verwendet werden?

Es klingt so, als wäre force_https nicht aktiviert.

Ich kann es im Moment nicht tun, da ich alles von vorne beginnen muss.

Ich habe versucht, alle Dateien zu kopieren (wobei Discourse im Ursprung heruntergefahren war), aber das hat auch nicht funktioniert (Probleme mit der Datenbank).

Ich werde es erneut versuchen: eine saubere Discourse-Installation durchführen und dann das mit Discourse erstellte Backup wiederherstellen.

Ich werde das prüfen, danke.

Das Wiederherstellen von Datenbanken oder das Migrieren von einem Host zum anderen wird schwieriger als erwartet.

Danke an euch beide.

Wenn Sie keinen Reverse-Proxy verwenden und die Zielplattform repräsentativ und korrekt konfiguriert ist, ist dies in der Regel unglaublich einfach.

Nun, es sei denn, es gab in der Zwischenzeit ein Upgrade für Discourse selbst oder die von dir verwendeten Plugins (ich verwende nur ein paar offizielle Plugins, Vorschauen der Themenliste und einige Komponenten). Jedes Mal, wenn ich versucht habe, eine Wiederherstellung zu simulieren, gab es irgendein Problem.

Ich finde, das Sicherungssystem ist einfach und übersichtlich, aber nicht robust genug, wenn man alles auf einen anderen Server übertragen muss.
Und es ist nicht flexibel genug.

Es dauert auch zu lange, bis es fertig ist (für eine nicht so große Seite beträgt die vollständige Sicherung nur 3 GB).

Unser altes Forum hatte mehr als 100 GB Daten; es wäre unmöglich, ein solches Forum mit dem aktuellen System zu sichern.

Die verschiedenen verkleinerten Avatar-Bilder sind nicht in einem Backup enthalten, nur die Originaldateien. Es wird einige Zeit dauern, bis der geplante Job alle Avatares durchläuft und die verkleinerten Versionen generiert.

AH, OK.
Vielen Dank!
Ich wusste nicht, dass sie im Hintergrund neu aufgebaut werden.
Es ist also eine Frage des Wartens.

Ich wurde wütend, als ich rake posts:rebuild und ähnliches verwendete.

Du hast mir viele Kopfschmerzen erspart. Vielen Dank.

Sie können es beschleunigen, indem Sie auf Ihrem Forum zu /sidekiq/scheduled gehen und neben dem Job CreateMissingAvatars auf die Schaltfläche “Trigger” klicken.

Wow, da versteckt sich eine ganze Welt in /sidekiq :slight_smile:

Ich habe versucht, das umzusetzen, was du vorgeschlagen hast.

Der Job CreateMissingAvatars wird zwar geplant und ausgeführt, bricht aber fast sofort ab; er dauert nur wenige Millisekunden. Ich habe versucht, ihn manuell auszulösen (über Trigger), doch auch dann endet er sofort mit dem Ergebnis OK.

Die Avatare sind jedoch immer noch falsch.

Ich nutze derzeit meine ursprüngliche Konfiguration, bei der Discourse über einen Socket läuft und Nginx als Reverse-Proxy dient.

Ich werde nun versuchen, Nginx zu entfernen und Discourse direkt auf den Ports 80 und 443 laufen zu lassen.

Yo @ariznaf

Ich bin heute Morgen aufgewacht, nachdem ich 12 Stunden lang offline war, und habe wieder auf unsere socket-only.yml-Konfiguration umgestellt. Alles ist wieder normal.

Also, zumindest auf meiner Seite des riesigen Discourse-Universums, ist in der Zwei-Container-Welt mit Nginx als Reverse-Proxy für Unix-Sockets wieder alles in Ordnung.

Wir waren etwa sechs Stunden vor dem Auftreten der Anomalie (die bemerkt wurde) auf die Nginx-Frontend-Konfiguration umgestiegen, und alles war in Ordnung.

Basierend auf diesem hilfreichen Hinweis von @riking (wie immer sehr geschätzt, Kane)

Die verschiedenen vergrößerten Avatar-Bilder sind nicht in einem Backup enthalten, nur die Originale. Es wird einige Zeit dauern, bis der geplante Job durchläuft und die vergrößerten Versionen aller Avatare generiert.

Screen Shot 2020-04-17 at 9.06.09 AM

Meine beste Vermutung ist, dass wir beim Umstieg auf Nginx keine Probleme bemerkt haben, weil die vielen Avatar-Bilder bereits zwischengespeichert waren und der Regenerierungsprozess noch nicht abgeschlossen war. Mit der Zeit lief der Cache für diese Bilder ab, und die Anomalie trat auf.

Also bin ich 12 Stunden offline (der socket-only.yml-Container läuft weiterhin im Hintergrund, inaktiv), wache morgens auf, und Sidekiq hat über Nacht seine Magie gewirkt (hier), wie @riking (großartige Unterstützung übrigens, Kane, zu jedem Thema hier auf Meta).

Dieses Szenario scheint zu bestätigen, was @riking vorgeschlagen hat.

Ehrlich gesagt, je mehr wir Discourse nutzen, desto mehr mögen wir es. Die Hürden und Anomalien sind sehr interessant, und die Zwei-Container-Konfiguration ist wirklich großartig.

Unsere Container sehen derzeit so aus:

# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml

Das Tolle daran ist, dass wir, selbst wenn wir ein Problem sehen, wie zum Beispiel diese Avatar-Regenerierungs-Anomalie, leicht zwischen socket-only.yml und web-only.yml hin- und herwechseln können.

In diesem Fall sind wir während dieser Regenerierung wieder auf web-only umgestiegen und danach wieder zurück, da alle Container weiterhin laufen. Wenn wir einen Container-Neuaufbau durchführen, können wir ganz einfach zwischen diesen Containern und Konfigurationen wechseln.

Nach zwei Jahrzehnten im Betrieb eines LAMP-Forums sind wir auf der Sysadmin-Seite immer mehr von Discourse beeindruckt.

Sidebar (Editorial):

Natürlich liegt das weit über meinem Rang hier auf Meta, aber ich denke, die grundlegende Zwei-Container-Konfiguration (ohne Reverse-Proxy) sollte der Standard sein, da sie sehr einfach einzurichten ist und wir aus dieser Konfiguration viel mehr gewinnen als jede wahrgenommene „Strafe“ für zwei yml-Dateien.

Auf meiner Seite habe ich versucht, die Wiederherstellung nur mit dem über die Schnittstelle erstellten Backup durchzuführen.

Wie bereits erwähnt, haben wir Avatar-Bilder und einige andere Kleinigkeiten verloren.

Ich habe versucht, die Anleitung von @riking zu befolgen, aber leider ohne Erfolg.

Ich habe versucht, die Avatar-Bilder zu aktualisieren, indem ich die Ausführung des Prozesses erzwungen habe. Das endete jedoch nach wenigen Millisekunden mit einem OK-Status, und die Avatare wurden nicht generiert.

Da wir unter Zeitdruck standen, um den Inhalt zu migrieren, habe ich das Forum auf dem alten Server gestoppt, den gesamten Inhalt in Containern und freigegebenen Verzeichnissen mit tar kopiert und Discourse auf dem neuen Server installiert (ohne die Anfangskonfiguration). Anschließend habe ich das freigegebene Verzeichnis und das Container-Verzeichnis dorthin kopiert und die App neu aufgebaut.

Jetzt funktioniert auf dem neuen Server alles.

Die Wiederherstellung aus einem Backup ist problematischer als erwartet (da es angesichts der Anweisungen, einfach neu zu installieren und über die Schnittstelle wiederherzustellen, eigentlich einfach erscheinen sollte).

Ich muss untersuchen, was bei der Wiederherstellung schiefgeht, und herausfinden, wie ich sicherstellen kann, dass das System hochfährt, auch wenn wir ein altes Backup wiederherstellen, während Discourse mehrere Versionen voraus ist im Vergleich zur Version, bei der das Backup erstellt wurde.

Ich mag Discourse sehr.
Wenn man von anderen traditionellen Foren kommt, fällt es manchmal schwer, herauszufinden, wo sich das Gesuchte befindet.
Die saubere Oberfläche hilft in solchen Fällen nicht unbedingt weiter.

Aber wenn man es schließlich findet, ist es dort, wo es sein sollte, und funktioniert auf clevere Weise.

Wir haben nur Probleme mit der Wiederherstellung aus Backups.
Und manchmal auch mit der starken Nutzung des Caches.

Discourse braucht beim ersten Laden in Ihrem Webbrowser eine Weile, aber danach läuft es flott, da ein Großteil der Verarbeitung auf Ihrem eigenen Rechner stattfindet und viel Caching verwendet (Avatare, Bilder, CSS usw.).
Die App ruft keine Informationen ab, die bereits auf Ihrem Computer gespeichert sind, was dem Server viel Arbeit spart (zumindest scheint das so zu sein, basierend auf meiner Erfahrung).

Wenn ich versuche, von einem Server auf einen anderen zu wechseln oder Discourse komplett neu zu installieren, sehe ich weiterhin den alten Inhalt, selbst wenn ich die Ansicht aktualisiere.

Ich konnte das Problem nicht lösen, bis ich den Verlauf des Webbrowsers gelöscht habe. Das hat mich eine ganze Weile beschäftigt und verwirrt.

ÜBRIGENS: Werden diese Avatar-Bilder gespeichert, wenn Sie die gespeicherten Miniaturbilder im Backup auswählen?
Denken Sie, es ist besser, sie zu speichern?
Unser Forum ist nicht allzu groß, aber das Sichern von 36.000 Bildern hat ziemlich lange gedauert.

Hallo @ariznaf,

Unser vollständiges Backup hat die gleiche Größe, etwa 3 GB, vollständig gzip-komprimiert.

Bisher habe ich keine der Probleme festgestellt, die du in deinem Beitrag erwähnt hast (direkt oben, #13).

Stellst du von der Kommandozeile oder über die Benutzeroberfläche wieder her?

Wir stellen nur von der Kommandozeile im Container wieder her. Ich gehe davon aus, dass bei dir dasselbe der Fall ist?

Das sind gute Nachrichten. Herzlichen Glückwunsch.

Vielen Dank für Ihr Interesse.

Ich habe die Anweisungen in den Tutorials über die Benutzeroberfläche befolgt. Ich weiß jedoch nicht, wie man von der Kommandozeile aus wiederherstellt (Backups, die über die Discourse-Oberfläche erstellt wurden).

Lassen Sie mich das erklären:

Ich musste den Server von a.domain.com auf b.domain.com verlegen.
Das Discourse-Forum wird über HTTPS mit einem benutzerdefinierten SSL-Zertifikat (wir verwenden unternehmensweite SSL-Zertifikate) erreicht.
Discourse wurde mit einem Socket installiert und der HOSTNAME war a.domain.com.
Wir haben nginx als Reverse-Proxy konfiguriert, um http(80)-Verkehr dauerhaft auf https(443) umzuleiten, und https(443) fungiert als Reverse-Proxy für https-Verkehr und leitet ihn an den Socket weiter, auf dem Discourse lauscht.

Ich hatte ein Backup (über die Oberfläche) von a.domain.com in einem S3-Bucket, mit Datenbank und Uploads, aber ohne Thumbnails (ca. 3 GB).

Ich habe nginx installiert und die Konfigurationsdatei von a.domain.com kopiert, wobei ich den Hostnamen von a.domain.com in b.domain.com geändert habe.

Ich habe Discourse durch Klonen von GitHub installiert (wie im 30-Minuten-Installations-Tutorial empfohlen).
Anschließend habe ich die Discourse-Installation ausgeführt (wobei nginx gestoppt war) und sie auf HOSTNAME b.domain.com konfiguriert.

Ich habe auf die neue Installation unter b.domain.com zugegriffen und mich als Admin angemeldet.
Über die Oberfläche habe ich Backups so konfiguriert, dass sie auf den S3-Bucket zugreifen, Admin-Wiederherstellungsfunktionen aktiviert und das letzte Backup wiederhergestellt.

Danach wurde man von Discourse abgemeldet, da es neue Benutzer, Konfigurationen usw. gibt.

Zurück an der Kommandozeile habe ich die app.yml bearbeitet und die Konfiguration vom ursprünglichen Server (a.domain.com) kopiert, wobei ich nur den Hostnamen in b.domain.com geändert habe.

Dann habe ich ./launcher rebuild all ausgeführt und nach Abschluss nginx gestartet.

Ich habe Zugriff auf das Discourse-Forum erhalten, aber Avatare sind verloren gegangen und es gibt weitere Probleme mit Bild-Thumbnails.

Danke für diese ausführlichen Informationen, @ariznaf.

Um ehrlich zu sein, bin ich kein Fan von Cloud-Speicherdiensten wie S3. Daher halte ich es für besser, weitere Ideen vorerst beiseitezulegen, da wir keine „S3-Nutzer

Du sagst, Avatare seien verloren, aber hast du die Seitenquelle untersucht, um zu sehen, von wo sie angefordert werden?

Sind sie noch in S3?

Warum musstest du Subdomains ändern?

Um es klarzustellen: Du hast sowohl den physischen Server als auch die DNS-Adresse geändert?

Riking sagt, dass das System die Miniaturansichten neu erstellen muss. Der Job scheint jedoch abgeschlossen zu sein.

Ich werde es erneut versuchen. Jetzt habe ich es auf eine andere Weise gelöst.

In S3 werden nur die Backups gespeichert; Bilder und Uploads werden lokal gespeichert.

Ich muss jedoch Wiederherstellungstests durchführen, um das Problem zu identifizieren.
Ich werde prüfen, von wo das System versucht, das Bild abzurufen.

Es wurde jedoch ein Bild mit einer weißen Silhouette angezeigt, also handelt es sich nicht um einen defekten Link. Es wurde wahrscheinlich vom System geändert, weil keine Miniaturansicht vorhanden ist.