If you need any help with drilling down to the root cause of issues like this, please let me know. I’m happy to help.
So, tried to restore my 2.2GB backup and got this - the restore failed:
EXCEPTION: 44 posts are not remapped to new S3 upload URL. S3 migration failed for db ‘default’.
I am on the 2.6b6, so a fairly recent version. The site is fairly old, from 2016.
From time to time we run into backups were the automatic remapping and migration to S3 fails for various reasons.
This is an old topic, so any recommendation for corrective action? Having a backup I can’t actually use to restore makes me a little nervous.
Edit: I just realized I may be in the wrong thread, as this seems like the same issue
Gave this another shot and I am still failing on the restore to the 44 posts are not remapped -error.
Temporary disabling of S3 uploads prior to the backup (proposed by @RGJ does not solve the issue, and currently I don’t have a working backup scheme, which is pretty damn serious.
Any suggestions on what to try?
Okay, this is the weirdest case I’ve seen so far. I stumpled upon this post.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
After wasting hours on this already, I defined the DISCOURSE_CDN_URL just for kicks, a feature my site does not use. The backup was restored successfully.
What is the significance of this parameter, in this scenario? @Falco @pfaffman
EDIT:
I take that back. After success with the test, I took a fresh backup from production and once again started to migrate to a new server. It failed again, but the error message changed.
EXCEPTION: rake posts:missing_uploads identified 3 issues. S3 migration failed for db ‘default’.
EDIT2:
So I kept drilling the database and found these 3 posts.
- 2 were very old images, that were first published but then moderator replaced the images with a modified version. These were from 2016 and 2018.
- But the last 1 was odd. It was a very recent post just a couple of weeks ago by myself and it contained a oneboxed https:// link to a development server, that no longer exists. So a broken link breaks the restore process.
I simply deleted these posts manually.
Now, again, a test run shows that a backup might actually succeed. We’ll see.
@ljpp I seem to be in a similar situation with a restore failing with
EXCEPTION: 1 posts are not remapped to new S3 upload URL. S3 migration failed for db ‘default’.
Can you elaborate on how you found and deleted the offending posts? What commands are used?
He deleted the posts in question.
But you wiped your install so you can’t do that, right?
لدي هذه المشكلة في استعادة قاعدة البيانات الخاصة بي. كيف تجد المشاركات المخالفة؟
أعتقد أن الكود الذي يقوم بالتحقق موجود هنا:
لذا أعتقد أن هذا:
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}%'")
وللتأكد
good = Upload.by_users.where("url LIKE '#{base_url}%'")
أخبرني إذا كان هذا يعمل معك وسأفكر في إنشاء موضوع.
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
أعطتني هذه العملية 0 أخطاء
هل قمت بذلك على الخادم الأصلي؟ أم تحتاج إلى القيام بذلك بعد استعادة قاعدة البيانات قبل أن تقوم بهذا الفحص، باستخدام المفتاح --pause؟
لقد فعلت ذلك على الخادم القديم.
عند الاستعادة، واجهت نفس الخطأ
[2026-01-16 13:45:52] EXCEPTION: 3 مشاركات لم تتم إعادة تعيينها إلى عنوان URL جديد للتحميل S3. فشلت ترحيل S3 لقاعدة البيانات ‘default’.
[2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
حسناً. يا للأسف. لست متأكداً مما يمكنني قوله لك بخلاف ذلك.
هل وجدت الأداة good الملفات التي رفعتها؟
كنت سأستخدم على الأرجح الخيار --pause وأوقف الاستعادة قبل أن تجري هذا الفحص.
سأفعل ما قاله ريتشارد.
لست متأكدًا من وضعك بالضبط ولكن قد ترغب ببساطة في إيقاف تحميلات S3، وإجراء النسخ الاحتياطي، والاستعادة، وتشغيلها مرة أخرى. لقد أنقذني هذا عدة مرات.
إذًا، يجب عليّ إيقاف تشغيل هذا الخيار، أليس كذلك؟

صحيح.
- ألغِ تحديد “تمكين تحميلات S3”
- النسخ الاحتياطي / التنزيل
- التحميل / الاستعادة
- حدد “تمكين تحميلات S3”
أنا لا أتحدث الإيطالية عندما لا يتعلق الأمر بالطعام… ربما يمكنك أن تقدم لنا جميعًا خدمة ونسخ/لصقها في ترجمة جوجل ![]()
آسف
تمكين تحميلات S3
يخزن التحميلات على مساحة قرص Amazon S3. هام: يتطلب توفير بيانات اعتماد S3 صالحة (كل من مفتاح الوصول ID ومفتاح الوصول السري).
لا يمكنك تمكين تحميلات S3 لأنها ممكّنة بالفعل على مستوى العالم، وقد يتسبب تمكين تحميلات S3 على مستوى الموقع في حدوث مشكلات حرجة في التحميلات.
أفترض أنك قمت بذلك بالفعل في app.yml.
هل تعمل عمليات الرفع (الجديدة) بشكل صحيح؟ إذا كان الأمر كذلك، فلا توجد مشكلة.
في app.yml لديّ إعداد S3، هذا صحيح.
إذًا، ما الذي يجب عليّ فعله للنسخ الاحتياطي والاستعادة بأمان دون التحقق من عمليات الرفع؟
مجرد إلغاء تحديد “تمكين تحميلات S3” لا يعمل
