مرحباً يا رفاق - في طور محاولة الترحيل من استضافة Discourse إلى الاستضافة الذاتية. لقد أجريت الكثير من الاختبارات الناجحة لأشياء مختلفة، ولكن عندما أحاول القيام بالشيء الحقيقي بما في ذلك جميع التحميلات، بعد ساعتين من فك ضغط الأرشيف، يقول إنه لا يوجد مثل هذا الملف أو الدليل عند محاولة استخراج ملف التفريغ. لذا أواجه الآن احتمال فقدان حوالي 140 جيجابايت من التحميلات ما لم يكن لدى أي شخص أي أفكار؟
هل يمكنك تقديم السجل؟
هل تقوم بالاستعادة من سطر الأوامر أم من الواجهة الرسومية؟ أوصي بالواجهة الرسومية.
مرحباً - لقد أرفقت السجل في البريد الإلكتروني السابق، على الرغم من أنني أرفقته مرة أخرى هنا. لقد جربته أولاً باستخدام الواجهة على الويب ثم في المرة الثانية عبر سطر الأوامر. لدي شك في أن النسخة الاحتياطية قد تكون تالفة بطريقة ما، حيث إنها غير معروفة عند تحميلها إلى S3 ويتم رفضها على الفور تقريبًا إذا حاولت تحميلها عبر المتصفح.
restore-failure-log.txt (3.28 KB)
هذا ما يبدو عليه الأمر. هل قمت بالتحميل باستخدام متصفح الويب أو scp/rsync؟ أقترح التحميل مرة أخرى باستخدام rsync.
مرحباً جاي - آسف لقد اختلط علي الأمر قليلاً في وقت سابق حيث كنا نجري مناقشات مع Discourse عبر البريد الإلكتروني طوال عملية الترحيل هذه، وهناك قمت بإرفاق ملف السجل.
بالنظر إلى الخطأ، أشك في أن ملف tarball لا يحتوي فعليًا على تفريغ sql، بل صور فقط. تم بدء الملف والتحقق منه بواسطة Discourse نيابة عنا. قمت بتنزيله عبر http وتحميله إلى الخادم عبر scp، حيث رفض المتصفح تحميله.
نعم، لقد قمت للتو بتشغيل أمر لفحص محتويات ملف tarball وهو يحتوي فقط على صور، ولا يوجد تفريغ SQL.
هل يمكنك التحقق مما إذا كانت أحجام الملفات المضغوطة متطابقة تمامًا؟
- على نسخة CDCK
- النسخة التي تم تنزيلها
- النسخة التي قمت بتحميلها باستخدام scp
قد ترغب في استخدام tar tfvz للتحقق مما إذا كان الأرشيف غير مبتور.
قد ترغب في التحقق مما إذا كنت لا تنفد مساحة القرص في أي مكان، حيث يتطلب ذلك مضاعفات حجم الأرشيف.
حسنًا، لقد خرجت لبعض الوقت ولكن سأتحقق لاحقًا. لن تكون هناك مشكلة في المساحة حيث لدي 512 جيجابايت وملف النسخ الاحتياطي هو 70 جيجابايت. لقد فوجئت بأن الملف كان أصغر ببضع جيجابايت من الملف الأخير الذي أنشأناه، كنت أتوقع أن يكون أكبر قليلاً. أنا متأكد تمامًا أنه لسبب ما لم يتضمن تفريغ SQL، والذي سيكون حوالي الفرق في الحجم.
مرحباً @pfaffman @RGJ، مجرد تحديث حول كيفية تقدم هذا الأمر. كان تفريغ SQL مفقودًا بالفعل من الأرشيف الذي تم تنزيله، ولم أكن متأكدًا مما إذا كان أخذ نسخة احتياطية منفصلة لقاعدة البيانات وإدراجها في الأرشيف سيعمل (وسيستغرق الأمر عدة ساعات للاختبار). لذلك انتهى بنا الأمر باستعادة قاعدة البيانات وترحيلها (بنجاح).
المشكلة الآن هي أنه بمجرد أن يقوم Discourse بإلغاء تشغيل كل شيء وإيقاف تشغيل حاوية S3 / CDN، ستتعطل جميع صورنا التاريخية.
لدي جميع الصور، وأعتقد أنه يمكنني تحميلها جميعًا إلى حاوية S3 الخاصة بنا مع الحفاظ على نفس بنية المجلد. رأيت بعض المواضيع التي تناقش إمكانية استخدام discourse.remap / dbhelper.remap لتحديث الروابط بشكل جماعي على مستوى قاعدة البيانات. أي أفكار حول ذلك ستكون محل تقدير كبير!
لا أستطيع أن أتخيل كيف يمكن أن يحدث ذلك. هل قام متصفحك بفك ضغط وفك أرشيف النسخ الاحتياطي بطريقة ما وحاولت إعادة تجميعه؟
يمكنك أن تطلب من الأشخاص في discourse.org تزويدك بنسخة احتياطية تتضمن التحميلات. هذا ما تريد القيام به. يقومون بتشغيل include_s3_uploads_in_backup (هذا قريب من، ولكن بالتأكيد ليس اسم الإعداد المخفي).
يمكنك أيضًا ابتكار استخدام أدوات S3 لسحبها جميعًا من حاويتهم ودفعها مرة أخرى. هناك عدد قليل من المواضيع حول ذلك. لا أوصي بذلك.
لقد قمت مؤخرًا بترحيل نسخة احتياطية بحجم 100 جيجابايت تقريبًا من CDCK إلى Digital Ocean، وقطعة، وحاوية مساحات، وشبكات توصيل المحتوى bunny.net مقابل 1000 دولار. لقد أسفت لذلك.
هل هذا هو قاعدة البيانات فقط؟
أوه، هل قمت بطريقة ما باستعادة قاعدة البيانات فقط على الرغم من أن لديك الصور في ملف الأرشيف؟
تحتاج إلى استعادة الملف الدقيق الذي قاموا بإنشائه وجعل Discourse يستعيده. الملف الذي يحتوي على قاعدة البيانات والتحميلات. أو يمكنك النظر إلى كود الاستعادة وابتكار القيام يدويًا بالأشياء التي يقوم بها لإعادة تعيين الصور إلى الموقع الجديد. على الرغم من أنني أعتقد أن ريتشارد لديه المهارات والأدوات للقيام بذلك، لا أعتقد أنك تريد القيام بذلك بهذه الطريقة.
لقد أجرينا اختبارًا قبل شهرين وكان كل شيء على ما يرام. أعتقد أنهم تركوا هذا الإعداد المخفي قيد التشغيل، حيث تمكنت هذه المرة من تشغيل نسخة احتياطية بما في ذلك التحميلات من الواجهة الخلفية، على الرغم من أنه بعد حوالي 12 ساعة تلقينا إشعارًا بفشلها. ثم اتصلت بـ Discourse وقالوا إنهم سينشئون النسخة الاحتياطية من جانبهم. بعد ساعتين، بدت النسخة الاحتياطية التي بدأتها تكتمل، على الرغم من أننا تخلصنا من الملف كما نصحت به Discourse. ثم واجهوا مجموعة من المشكلات مع النسخ الاحتياطية التي انتهت مهلتها وعادت بأخطاء، قبل أن يخبرونا في النهاية بوجود ملف كامل. ولكن عندما حاولت استعادة الملف، بعد أن استغرقت عدة ساعات لاستخراج الأرشيف، اشتكى من أن التفريغ مفقود. أكد فحص الملف باستخدام tar -tf عدم وجود تفريغ فيه (بالنظر إلى النسخ الاحتياطية الكاملة الأخرى، فهو عادةً الملف الأول في الأرشيف). نظرًا لأنه كان يوم الأحد، لم أتمكن من التواصل مع Discourse، وقد وعدنا بإكمال الترحيل بحلول صباح الاثنين، لذلك أخذت نسخة احتياطية لقاعدة البيانات فقط (حوالي 7 جيجابايت) واستخدمتها فقط للترحيل.
يحاول Discourse المساعدة، ولكن لا يوجد حقًا سوى قدر ضئيل مما يمكنهم فعله الآن، حيث أكملنا الترحيل وكنا في بيئتنا المستضافة ذاتيًا منذ بعد ظهر يوم الأحد. سيكون الحل الأسهل هو أن يحتفظوا بسلة S3 وشبكة توصيل المحتوى (CDN) الخاصة بنا نشطة (مقابل رسوم) ولكنهم قالوا إن هذا غير ممكن. أعتقد أننا سنضطر إلى فقدان الصور التاريخية بصراحة.
يمكن إصلاح هذا. ما عليك سوى تنزيل محتويات S3 bucket في دليل التحميل المحلي الخاص بك ثم إجراء remap على قاعدة البيانات الخاصة بك، وإعادة كتابة عناوين URL الخاصة بـ CDN و bucket إلى عنوان URL الخاص بالنسخة الخاصة بك.
إعجاب واحد (1)
هناك بعض المشكلات - حجم الصور التي تم تحميلها سيؤدي إلى استنفاد مساحة القرص الصلب (SSD) في خادم VPS الجديد الخاص بنا، وليس لدينا القدرة على إرفاق قرص إضافي. ربما يمكننا أخذ مجموعة فرعية على الرغم من أننا لسنا متأكدين من كيفية عمل ذلك بالنظر إلى بنية الدليل. أيضًا، لقد قمنا بالفعل بتكوين الموقع لاستخدام S3 للتحميلات بدلاً من التخزين المحلي.
حسنًا، إذن انسخ S3 الخاص بهم (أو النسخة الاحتياطية من S3) إلى S3 الخاص بك وأعد تعيينه؟
إعجاب واحد (1)
نعم، هذا ما آمل أن يكون ممكناً!
إعجاب واحد (1)
آه. أفهم. نعم، بمجرد أن تبدأ العمل، فأنت ملتزم. لا يزال من الممكن نقل الملفات إلى S3 قبل حذفها.
كنت دائمًا بحاجة إلى مساحة كافية للاحتفاظ بجميع الصور لإجراء الاستعادة. يمكنك نسخ الصور واحدة تلو الأخرى. هناك أيضًا أدوات ستقوم بنسخ الملفات مباشرة، على ما أعتقد.
نعم، كانت الخطة الأصلية هي استخدام جهاز افتراضي مؤقت على Azure للاستعادة، مع إرفاق قرص كبير، ثم دفعه مرة أخرى إلى S3، وأخذ نسخة احتياطية أخرى بمجرد الانتهاء، وأخيرًا نقله إلى خادم VPS الخاص بنا (محاولةً لخفض التكاليف).
لذا لدي ملف tar.gz يحتوي على جميع التحميلات ويمكنني إدخالها مباشرة في حاوية S3 الخاصة بنا مع الحفاظ على بنية الدليل (أعتقد أن أداة التحميل القياسية من AWS يمكنها القيام بذلك في الوقت الحالي، وإلا فهناك واجهة سطر الأوامر). قد يكون هناك بعض الاعتبارات المتعلقة بالملكية / الأذونات على الرغم من أنه ربما لا.
بعد ذلك، سيكون هناك إعادة التعيين - لست متأكدًا من الفرق بين discourse.remap و dbhelper.remap. سأقوم باختبار كل هذا على تثبيت وهمي مع ملفين أولاً.
إعجاب واحد (1)