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.

[이미지] 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 talking…

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…

[이미지] 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

복원된 이미지에는 S3 버킷 URL이 없습니다

지원

gerhard (Gerhard Schlager) 6월 12, 2026, 8:55오전 11

네, 그렇게 해 주세요. 그리고 복원 시 출력 내용을 확인해 주세요. .sql.gz 파일을 복원할 때 URL 재매핑에 대한 언급이 있어서는 안 됩니다.

글		댓글	조회수
Uploads missing after restore Self-hosting	3	739	4월 24, 2022
Restore process cancelled at migrating uploads to S3 step Support	48	3573	1월 24, 2026
Restore from backup fails due to S3 migration Support	8	1381	9월 10, 2019
Help restoring - system hung at midnight Self-hosting	26	2681	6월 13, 2022
Unable to migrate to S3, therefore unable to restore from backup Self-hosting	2	1286	3월 9, 2022

복원된 이미지에는 S3 버킷 URL이 없습니다

Related topics