Wie man diese Unordnung von wechselnden Uploads von S3 nach lokal kontrolliert

Unterstützung
1

Nach 4-5 Jahren Nutzung habe ich endlich beschlossen, meine Uploads vom AWS S3 Bucket zurück auf meinen lokalen Server für meine sehr kleine lokale Website zu holen.
Da ich nur begrenzte Kenntnisse habe, habe ich diese Aufgabe für einen sehr vernünftigen Betrag an einen Freund übergeben. Er hat die Website für lokale Uploads konfiguriert, aber irgendwie sind fast die Hälfte der 3000 Bilder, etwa 50%, von ihrer Quelle kaputt gegangen. Mein Freund hat mir nichts berechnet und mich gebeten, die Website auf das Backup zurückzusetzen (das erstellt wurde, bevor ich ihm am 11. April 2025 die Kontrolle übergeben habe).

Wie auch immer, ich war etwa einen Monat lang faul und habe es nicht rückgängig gemacht. Bis ich beschloss, die Dinge mit Hilfe des Discourse Helper Bots/ChatGpt KI-Bots zu reparieren. Und eine weitere Version meiner alten Website lokal auf meinem Ubuntu-Laptop erstellt.

Ich habe es geschafft, eine Instanz meiner ursprünglichen Website auf meinem Laptop zu erstellen, indem ich einfach einen “t.” vor meinen ursprünglichen Domainnamen gesetzt habe. Jetzt funktioniert diese (Staging-Site genannt) für mich einwandfrei, hat aber nur Aktivitäten bis zum 11. April 2025.

Und meine Produktionswebsite, die alle Daten auf dem neuesten Stand hat, aber viele Hunderte von Beiträgen mit fehlenden Bildern hat.

Bedenken Sie, dass ich viele Rake-Aufgaben für die Migration oder die Wiederherstellung der fehlenden Verbindung zu Bildern ohne Erfolg ausprobiert habe.

Nachdem ich mir fast einen Monat lang den Kopf zerbrochen hatte. Meine Schlussfolgerung ist diese. Dass die rohen Beiträge in Ruby in Staging und in Produktion gleich sind.
Aber die verarbeiteten Beiträge werden unterschiedlich. Das heißt, meiner Produktionsdatenbanktabelle fehlt vielleicht eine Verbindung zu den tatsächlichen physischen Bildern, die auf dem Server liegen.

Ich habe auch festgestellt, dass ohne diese Verbindung diese “verwaisten” Bilder automatisch vom Server gelöscht werden. Aber glücklicherweise synchronisiere ich sie wieder von Staging oder von meinem S3-Bucket auf meinen Produktionsserver.

Endlich das Problem, in den Worten von mehr oder weniger ChatGpt, dass der Staging-Server entweder endgültige verarbeitete Versionen hat, die keine Beziehung zu den (kurzen) rohen URLs haben. Und die Produktion, der die endgültigen verarbeiteten URL-Versionen zu Bildern fehlen, kann diese korrekten Bild-URLs nicht erhalten und greift auf “transparente” Platzhalter zurück.

Und ChatGpt schlägt mir vor, die verarbeitete Version von Staging-Posts in die verarbeitete Version der Produktion zu kopieren. Was für mich keine sehr gute Idee zu sein scheint.

2

Exakte Formulierung von ChatGpt, wo wir stehen:

  • Sowohl in Staging als auch in der Produktion ist post.raw identisch und enthält upload://...-Referenzen.
  • In Staging werden Bilder angezeigt, aber die Abfrage von Post.find(12849).uploads liefert keine Ergebnisse – das bedeutet, dass es keine Einträge in den Tabellen uploads oder post_uploads für diese Dateien gibt, selbst in Staging.
  • Bilder werden also in Staging rein deshalb angezeigt, weil der gekochte HTML-Code von vor der Migration die vollständigen Links /uploads/default/original/... enthält.
  • Da die Produktion jedoch nach der Migration neu gebacken wurde, schlägt derselbe Rohinhalt nun fehl und greift auf den Platzhalter transparent.png zurück.

:white_check_mark: Upload-Dateien existieren noch auf der Festplatte

Alle Bilddateien (auch die für die fehlenden Uploads) sind sowohl in Staging als auch in der Produktion noch unter /var/www/discourse/public/uploads/default/original/ vorhanden. Discourse kann sie jedoch nicht mehr auflösen, da ihre uploads-Einträge fehlen.

3

Der einfache Weg war und ist möglicherweise immer noch, die Einstellung Enable hidden setting to include S3 uploads in the backups zu aktivieren, ein Backup zu erstellen und es dann auf einem Server wiederherzustellen, auf dem S3 nicht konfiguriert ist (ich würde es auf einem neuen Server tun, um den alten nicht zu beschädigen, falls etwas schiefgeht). Aber es klingt, als ob die Produktionsseite auch kaputt ist, das wird also wahrscheinlich überhaupt nicht helfen.

Wenn Sie die Uploads-Tabelle so durcheinander gebracht haben, dass sie mehrere S3-Pfade enthält, ist die Aufgabe viel schwieriger.

Anstatt ChatGPT würde ich https://ask.discourse.com/ empfehlen, das zumindest etwas über Discourse weiß, aber wahrscheinlich immer noch nicht viel helfen wird.

Ich würde Uploads.pluck(:url) ansehen und sehen, was dort ist.

3 „Gefällt mir“