Wenn Sie Unterstützung bei der Ursachenanalyse für Probleme wie diese benötigen, lassen Sie es mich bitte wissen. Ich helfe gerne.
Also, ich habe versucht, mein 2,2 GB großes Backup wiederherzustellen, und habe Folgendes erhalten – die Wiederherstellung ist fehlgeschlagen:
AUSNAHME: 44 Beiträge wurden nicht auf die neue S3-Upload-URL umgemappt. Die S3-Migration für die Datenbank ‘default’ ist fehlgeschlagen.
Ich verwende die Version 2.6b6, also eine recht aktuelle Version. Die Seite ist jedoch ziemlich alt und stammt aus dem Jahr 2016.
Von Zeit zu Zeit stoßen wir auf Backups, bei denen die automatische Ummapping und Migration zu S3 aus verschiedenen Gründen fehlschlägt.
Dies ist ein altes Thema. Gibt es daher eine Empfehlung für korrigierende Maßnahmen? Dass ich ein Backup habe, das ich tatsächlich nicht zur Wiederherstellung verwenden kann, macht mich etwas nervös.
Edit: Mir ist gerade aufgefallen, dass ich möglicherweise im falschen Thread bin, da dies wie das gleiche Problem aussieht:
Ich habe es erneut versucht und scheitere immer noch beim Wiederherstellen mit dem Fehler „44 Beiträge wurden nicht zugeordnet."
Das vorübergehende Deaktivieren von S3-Uploads vor dem Backup (wie von @RGJ vorgeschlagen) löst das Problem nicht, und aktuell habe ich kein funktionierendes Backup-Verfahren, was ziemlich ernst ist.
Hast du Vorschläge, was ich noch versuchen könnte?
Okay, das ist der seltsamste Fall, den ich bisher gesehen habe. Ich bin auf diesen Beitrag gestoßen.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
Nachdem ich bereits stundenlang damit verbracht hatte, habe ich aus Spaß die DISCOURSE_CDN_URL definiert, eine Funktion, die meine Seite gar nicht nutzt. Das Backup wurde erfolgreich wiederhergestellt.
Was ist in diesem Szenario die Bedeutung dieses Parameters? @Falco @pfaffman
EDIT:
Ich nehme das zurück. Nach dem Erfolg beim Test habe ich ein frisches Backup von der Produktion erstellt und erneut mit der Migration auf einen neuen Server begonnen. Diesmal ist es erneut fehlgeschlagen, aber die Fehlermeldung hat sich geändert.
AUSNAHME: rake posts:missing_uploads hat 3 Probleme festgestellt. Die S3-Migration für die Datenbank ‘default’ ist fehlgeschlagen.
EDIT2:
Also habe ich die Datenbank weiter durchsucht und diese 3 Beiträge gefunden.
- Zwei waren sehr alte Bilder, die ursprünglich veröffentlicht, aber dann von einem Moderator durch eine modifizierte Version ersetzt wurden. Diese stammen aus den Jahren 2016 und 2018.
- Aber der letzte war seltsam. Es war ein sehr aktueller Beitrag von mir aus vor ein paar Wochen, der einen oneboxed https://-Link zu einem Entwicklungsserver enthielt, der nicht mehr existiert. Ein defekter Link bricht also den Wiederherstellungsprozess.
Ich habe diese Beiträge einfach manuell gelöscht.
Jetzt zeigt ein neuer Testlauf erneut, dass ein Backup tatsächlich erfolgreich sein könnte. Wir werden sehen.
@ljpp Ich scheine mich in einer ähnlichen Situation zu befinden, bei der eine Wiederherstellung fehlschlägt mit:
AUSNAHME: 1 Beitrag wurde nicht auf die neue S3-Upload-URL umgemappt. Die S3-Migration für die Datenbank ‘default’ ist fehlgeschlagen.
Könntest du bitte näher erläutern, wie du die problematischen Beiträge gefunden und gelöscht hast? Welche Befehle wurden verwendet?
Er hat die betreffenden Beiträge gelöscht.
Aber du hast deine Installation gelöscht, also kannst du das nicht, oder?
Ich habe dieses Problem beim Wiederherstellen meiner Datenbank. Wie haben Sie die beanstandeten Beiträge gefunden?
Ich denke, der Code, der die Überprüfung durchführt, befindet sich hier:
Also denke ich, das hier:
prefix = @migrate_to_multisite ? "uploads/#{@current_db}/original/" : "original/"
base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
bad = Upload.by_users.where("url NOT LIKE '#{base_url}%'")
Und zur Sicherheit
good = Upload.by_users.where("url LIKE '#{base_url}%'")
Lass mich wissen, ob das für dich funktioniert, und ich werde sehen, ob ich ein Thema erstellen kann.
discourse(prod) > prefix = @migrate_to_multisite ? “uploads/#{RailsMultisite::ConnectionManagement.current_db}/original/” : “original/”
discourse(prod) > base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
discourse(prod) > bad_uploads = Upload.by_users.where(“url NOT LIKE ‘#{base_url}%’”)
discourse(prod) > bad_uploads.count
=> 0
Dieser Check ergab bei mir 0 Fehler
Haben Sie das auf dem ursprünglichen Server gemacht? Oder müssen Sie es tun, nachdem die Datenbank wiederhergestellt wurde, bevor sie diese Prüfung durchführt, indem Sie die Option --pause verwenden?
Ich habe es auf dem alten Server gemacht.
Beim Wiederherstellen erhielt ich denselben Fehler
[2026-01-16 13:45:52] EXCEPTION: 3 Beiträge werden nicht auf die neue S3-Upload-URL umgeordnet. S3-Migration für die Datenbank „default“ fehlgeschlagen.
[2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
Nun. Verdammt. Ich weiß nicht, was ich dir sonst noch sagen soll.
Hat der good deine Uploads gefunden?
Ich würde wahrscheinlich einfach den --pause-Schalter verwenden und die Wiederherstellung stoppen, bevor er diese Überprüfung durchführt.
Ich würde tun, was Richard gesagt hat.
Ich bin mir Ihrer genauen Situation nicht sicher, aber Sie möchten möglicherweise einfach die S3-Uploads deaktivieren, das Backup erstellen, wiederherstellen und sie wieder aktivieren. Das hat mir schon oft geholfen.
Also, ich muss diese Optionen ausschalten, richtig?
Korrekt.
- Deaktivieren Sie „S3-Uploads aktivieren“
- Sichern / Herunterladen
- Hochladen / Wiederherstellen
- Aktivieren Sie „S3-Uploads aktivieren“
Ich spreche kein Italienisch, wenn es nicht ums Essen geht… vielleicht tun Sie uns allen einen Gefallen und kopieren/fügen Sie es in Google Translate ein 
Entschuldigung
S3-Uploads aktivieren
Speichert Uploads auf dem Amazon S3-Speicherplatz. WICHTIG: Erfordert die Angabe gültiger S3-Anmeldeinformationen (sowohl die Zugriffsschlüssel-ID als auch das Zugriffsschlüssel-Geheimnis).
Sie können S3-Uploads nicht aktivieren, da sie bereits global aktiviert sind, und das Aktivieren von S3-Uploads auf Site-Ebene könnte zu kritischen Problemen mit Uploads führen.
Ich nehme an, Sie haben das bereits in app.yml erledigt.
Funktionieren (neue) Uploads korrekt? Wenn ja, gibt es kein Problem.
In app.yml habe ich S3 konfiguriert, korrekt.
Was muss ich also tun, um sicher ein Backup zu erstellen und wiederherzustellen, ohne Uploads zu überprüfen?
Einfach „S3-Uploads aktivieren“ deaktivieren funktioniert nicht.