Hallo Discourse,
letzte Nacht habe ich mich durch die Discourse-Updates gekämpft und die App neu aufgebaut, was eine Reihe von Postgres-Fehlern zur Folge hatte. Mir wurde klar, dass dies auf das jüngste Upgrade zurückzuführen war, aber ich erhielt weiterhin Fehler wie „Zugriff verweigert
Wenn Ihre S3-Konfiguration in der app.yml hinterlegt ist, können Sie einfach eine Kommandozeilen-Wiederherstellung durchführen, und das Backup wird automatisch aus S3 geladen. Da Ihre Assets in S3 gespeichert sind, enthält das Backup nur die Datenbank.
Sie sollten einfach ein neues /var/discourse klonen, Ihre yml-Datei kopieren, neu aufbauen und die Wiederherstellung über die Kommandozeile durchführen.
Ich vermute, ich verwende den falschen Begriff dafür, wie meine Backups/Uploads eingerichtet sind. Ich habe diese Methode verwendet: Move Uploads and Backups to DigitalOcean Block Storage
Ich werde das korrigieren und sagen, dass meine Uploads und Backups nicht lokal im Hauptordner von Discourse liegen (das ist teilweise der Grund, wie alles begann; ich habe versucht, uns zu DigitalOcean Spaces zu migrieren). Also nein, leider habe ich keine S3-Konfigurationen vorgenommen, da ich sie nur auf einem eingebundenen Speicher gespeichert habe.
Die Backups wurden in mnt/my_storage/shared/standalone gespeichert, aber wenn ich dort nach Backups suche, habe ich nur die Datei wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz. Ich habe tatsächlich versucht, von dieser Datei wiederherzustellen, da mir keine bessere Idee eingefallen ist (was wahrscheinlich falsch war), aber ich habe eine Fehlermeldung „Zugriff verweigert
Sind deine Uploads also immer noch im DO-Block-Speicher?
Ja, alle Uploads sind intakt.
Ok, gut.
In diesem Fall solltest du die SQL-Datei wiederherstellen und dann das Blockspeicher-Volume erneut einbinden, um deine Uploads zurückzubekommen.
Es gibt zwei Arten von Backups: sql.gz, das keine Uploads enthält, und tar.gz, das Uploads enthält. Du hattest also die falsche Art von Backup, aber die Tatsache, dass deine Uploads auf einem externen Volume gespeichert waren, hat dich gerettet.
Also ich starte die App und stelle diese sql.gz wieder her, bekomme aber einen Fehler „Zugriff verweigert“. Hast du eine Idee, warum das sein könnte?
Du sagst es!! 
(Annahme, du meinst chmod). Wenn die Dateien dem falschen Besitzer zugeordnet sind, sind sie nicht beschreibbar.
Ich denke, das könnte den Fehler “Zugriff verweigert” verursacht haben.
Was ist die genaue Fehlermeldung?
Ja, danke. Ich war die ganze Nacht wach und bin etwas hirntot.
AUSNAHME: lib/discourse.rb:93:in `exec': Archiv konnte nicht in das tmp-Verzeichnis kopiert werden.
cp: kann '/var/www/discourse/public/backups/default/wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz' nicht zum Lesen öffnen: Keine Berechtigung
Versuchen Sie chmod 644 /var/www/discourse/public/backups/default/*
Okay, ich arbeite mich gerade daran durch. Ich melde mich in Kürze wieder. Vielen Dank, dass du dir die Zeit genommen hast, mir zu helfen.
Das hat funktioniert, um die Wiederherstellung zu starten, DANKE. 
Jetzt muss ich nur noch herausfinden, warum die Seite immer noch nicht lädt. 
Der Neuaufbau läuft derzeit mit der gespeicherten app.yml-Datei von vor dem Zusammenbruch.
Gibt es einen Befehl, um dieses Backup direkt in die App zu verschieben? Die Wiederherstellung findet es nicht, und ich kann mich nicht mehr daran erinnern, wie ich es zuvor zum Laden gebracht habe.
Sie können es von S3 herunterladen und in
/var/discourse/shared/standalone/backups/default
ablegen.
Anschließend sollten Sie in der Lage sein, die Wiederherstellung über die Kommandozeile durchzuführen.
Danach sollten Sie Ihre S3-Konfiguration wie in dem oben genannten Link beschrieben einrichten; das erleichtert die Arbeit.
Danke, Jay. Und ja, das ist definitiv mein Plan.
Okay, hier ist also mein aktueller Stand.
Allerdings ist die Website selbst immer noch nicht erreichbar. Ich nutze Cloudflare, habe aber derzeit den Development-Modus aktiviert und den DNS-Cache geleert. Alles ist korrekt konfiguriert. Die Cloudflare-Vorlage ist in der app.yml enthalten.
DNS wird korrekt aufgelöst, die Hostnamen sind aktuell, die Discourse-Installation wurde mit der entsprechenden URL durchgeführt, und ich bin langsam ratlos.
Die URL ist https://forum.wackywriters.com, aber ich erhalte nur Fehlermeldungen wie „Server nicht verfügbar“. Ich habe das Gefühl, im Kreis zu laufen (entschuldigung), aber habt ihr vielleicht noch Vorschläge?
Edit: Wenn ich ./discourse-doctor ausführe, sehe ich, dass zwei Instanzen der App in Docker laufen:
Ist das normal? (Es scheint mir unwahrscheinlich, aber in den letzten 24 Stunden wurde alles, was ich über Discourse zu wissen glaubte, über den Haufen geworfen 
)
Edit2: Ich habe das als letzten Ausweg hinausgeschoben, aber ich werde jetzt versuchen, einen komplett neuen Server mit einer frischen Discourse-Installation einzurichten. Ich befürchte, dass durch mein Herumprobieren etwas kaputtgegangen ist, und ich kann nicht herausfinden, was genau falsch läuft. Zum Glück habe ich noch das Backup und alle Uploads auf dem Block-Speicher. Wenn ich Glück habe, sollte ich diese Daten auf eine neue Droplet-Instanz übertragen können. Falls jemand weitere Vorschläge oder Tipps hat, würde ich mich über mehr Erfahrung als meine freuen.
Edit3: Selbst mit einem neuen Server und einer propagierten IP (nslookup und ping sehen beide gut aus, whatsmydns.net ebenfalls) lädt das Forum nicht. Ich erhalte weiterhin Verbindungsfehler. Es scheint, als würde die IP-Adresse nicht mit der Discourse-Instanz verknüpft, sondern stattdessen wird versucht, eine statische Seite zu laden, die in diesem Fall natürlich nicht existiert.
Nach fast 24 Stunden Kampf habe ich herausgefunden, warum die Seite nicht geladen wurde, nachdem ich die Wiederherstellung gestartet hatte.
Aufgrund so vieler Zurücksetzungen, Neuinstallationen und wer weiß was noch, habe ich das Kontingent erreicht. Deshalb habe ich die SSL-Vorlagen vorübergehend auskommentiert und werde sie in einer Woche wieder aktivieren.
Die Seite ist „funktionsfähig“, während ich alle Beiträge neu erstelle, um die defekten Bilder zu reparieren. Ich danke Jay und Richard sehr für ihre Hilfe heute – ihr habt mir durch die Teile geholfen, bei denen ich einfach nicht weiterkam.
Jetzt muss ich ein echtes Backup herunterladen, damit ich diese Woche S3 einrichten kann, ohne mir wieder Sorgen darüber machen zu müssen.
Wenn du suchst, gibt es eine Möglichkeit, eine zweite Domain hinzuzufügen, damit Let’s Encrypt dies als separate Anfrage zählt. Aber Warten ist einfacher.
Ich empfehle, Cloudflare auf die graue Wolke ohne Geschwindigkeitsverbesserungen zu stellen.
@pfaffman Verwechselst du nicht Objektspeicher mit Blockspeicher? Objektspeicher ist S3, aber TS sagt, sie hätten Blockspeicher verwendet, was einfach eine Festplatte ist, die an ihr Upload-Verzeichnis gemountet ist:
Oh. 
Ja. Also ergibt nichts von dem, was ich gesagt habe, einen Sinn.
Danke, dass du das bemerkt hast, Richard.
Nun, die meisten Dinge, die du gesagt hast, haben Sinn gemacht, aber du hast mich hier verwirrt
