إذا كنت بحاجة إلى أي مساعدة في تحديد السبب الجذري لمثل هذه المشكلات، فلا تتردد في إخباري. يسعدني مساعدتك.
لذا، حاولت استعادة نسخة احتياطية بحجم 2.2 جيجابايت وواجهت هذه المشكلة: فشل الاستعادة:
استثناء: 44 منشورًا لم يتم إعادة تعيينها إلى عنوان URL جديد لرفع S3. فشل الترحيل إلى S3 لقاعدة البيانات ‘default’.
أنا أستخدم الإصدار 2.6b6، وهو إصدار حديث نسبيًا. الموقع قديم نسبيًا، يعود لعام 2016.
بين الحين والآخر، نواجه نسخًا احتياطية يفشل فيها إعادة تعيين تلقائي وترحيل إلى S3 لأسباب مختلفة.
هذه قضية قديمة، فهل هناك أي توصيات لاتخاذ إجراء تصحيحي؟ وجود نسخة احتياطية لا يمكنني فعليًا استخدامها للاستعادة يجعلني قلقًا بعض الشيء.
تعديل: أدركت للتو أنني قد أكون في الموضوع الخطأ، حيث يبدو أن هذه هي نفس المشكلة
حسنًا، هذه أغرب حالة رأيتها حتى الآن. لقد تعثرت في هذا المنشور.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
بعد إضاعة ساعات في هذا بالفعل، عرّفت DISCOURSE_CDN_URL فقط للمحاكاة، وهي ميزة لا يستخدمها موقعي. تم استعادة النسخة الاحتياطية بنجاح.
ما هي أهمية هذا المعلمة في هذا السيناريو؟ @Falco @pfaffman
تعديل:
أرجع عن ذلك. بعد النجاح في الاختبار، أخذت نسخة احتياطية جديدة من بيئة الإنتاج وبدأت مرة أخرى في الهجرة إلى خادم جديد. فشلت العملية مرة أخرى، لكن رسالة الخطأ تغيرت.
استثناء: rake posts:missing_uploads حددت 3 مشكلات. فشلت هجرة S3 لقاعدة البيانات ‘default’.
تعديل 2:
لذلك واصلت البحث في قاعدة البيانات ووجدت هذه المنشورات الثلاثة.
- كان اثنان من الصور القديمة جدًا، نُشرت لأول مرة ثم استبدلها المشرف بنسخة معدلة. كانت هذه من عامي 2016 و2018.
- لكن المنشور الثالث كان غريبًا. كان منشورًا حديثًا جدًا قبل بضعة أسابيع فقط من طرفي، وكان يحتوي على رابط https مُدمج (oneboxed) إلى خادم تطوير لم يعد موجودًا. لذا فإن الرابط المعطوب يعطل عملية الاستعادة.
لقد حذفت هذه المنشورات ببساطة يدويًا.
الآن، مرة أخرى، يُظهر اختبار تجريبي أن النسخة الاحتياطية قد تنجح في الواقع. سنرى.
@ljpp يبدو أنني في موقف مشابه حيث فشل الاستعادة مع
استثناء: 1 منشور لم يتم إعادة تعيينه إلى عنوان URL جديد لرفع S3. فشل هجرة S3 لقاعدة البيانات ‘default’.
هل يمكنك التوضيح حول كيفية العثور على المنشورات المشكلة وحذفها؟ ما هي الأوامر المستخدمة؟
حذف المنشورات المعنية.
لكنك قمت بمسح تثبيتك، لذا لا يمكنك فعل ذلك، أليس كذلك؟
لدي هذه المشكلة في استعادة قاعدة البيانات الخاصة بي. كيف تجد المشاركات المخالفة؟
أعتقد أن الكود الذي يقوم بالتحقق موجود هنا:
لذا أعتقد أن هذا:
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” لا يعمل