We’ve been building, testing and intentionally finding gaps in our Discourse forum before we push it entire thing to production. I just migrated my test forum that had S3 uploads enabled from one server to another and upon restoration all of the URLs for anything attached got rewritten to the forum’…

Before restoring you can configure S3 on the destination site in your app.yml (not via the admin dashboard), once you confirm that’s setup and can reach the correct bucket you can go ahead with the restore and media should be linked up correctly. We have a guide for configuring S3 this way here: Co…

Hi Kris We effectively did that and that’s how we ended up in that situation. I copied the app.yml as it was to the destination and then backed up from the original. It was the restoration that was the problem as when we restored, that’s when the URLs got rewritten despite the fact that nothing ha…

That sounds like you did configure S3 via site settings, not env variables as Kris suggested. The restore process needs to know about S3. That’s not possible with site settings. You could also create a backup without uploads on the console of you want: discourse backup --sql_only Restoring such a …

The S3 configuration is in the app.yml. Not site settings. Edit: I realize I’m not being overly explanative and I’m not meaning to hide details. We use OVH S3 and it’s configured in app.yml. I backed up our test forum without uploads but still had S3 enabled at that point. I then restored it on…

Hiya, just following up on this.

As I said, if you want to restore on a server that uses the same S3 bucket, make sure to have S3 configured in app.yml and create a backup without uploads (discourse backup --sql_only). Upload URLs won’t be rewritten when the backup doesn’t contain uploads. If you wish to restore on a server that u…

Yes I did. When I initially restored it with the uploads done it actually broke so I had to completely wipe and start again this time, taking a backup without uploads. That’s where the issue started. The URLs were still written incorrectly. There were 0 changes made to app.yml.

[Bild] Maxine: taking a backup without uploads. That’s where the issue started. The URLs were still written incorrectly. I’m not sure how that happened. The restore process skips all upload-related code (including rewriting of upload URLs) when you restore a .sql.gz file. Maybe we are talkin…

So to answer all of these questions: No hostnames were changed. Just updated A records, backed up and done. User avatars were missing(and that was because I did not migrate the uploads folder). S3 images for attachments/media was re-written for the forum URL. Not the bucket URL. [image] So whil…

[Bild] Maxine: I can literally spin up another VM again and do a straight up restore if you want me to verify all of the steps I’ve taken. Yes, please do that. And look at the output from the restore. It shouldn’t mention any remapping of URLs when you restore a .sql.gz

Bilder nach einer Wiederherstellung haben keine S3-Bucket-URL

Unterstützung

gerhard (Gerhard Schlager) 12. Juni 2026 um 08:55 11

Ja, bitte tu das. Und schaue dir die Ausgabe der Wiederherstellung an. Es sollte keine Erwähnung einer URL-Umzuordnung geben, wenn du eine .sql.gz-Datei wiederherstellst.

Thema		Antworten	Aufrufe
Uploads missing after restore Self-hosting	3	717	24. April 2022
Restore process cancelled at migrating uploads to S3 step Support	48	2953	24. Januar 2026
Restore from backup fails due to S3 migration Support	8	1314	10. September 2019
Help restoring - system hung at midnight Self-hosting	26	2517	13. Juni 2022
Unable to migrate to S3, therefore unable to restore from backup Self-hosting	2	1229	9. März 2022

Bilder nach einer Wiederherstellung haben keine S3-Bucket-URL

Verwandte Themen