أحاول ترحيل نسخة discourse الخاصة بي إلى خادم جديد. نظرًا لأنني محدود بالمساحة على الخادم، أريد أولاً أن\n\n كيف يمكنني إيقاف تحسين الصور بعد تحميل قاعدة البيانات الأولي واستعادتها.\n\nحتى أتمكن من التحقق مما إذا كانت الاستعادة قد نجحت وحذف ملف النسخ الاحتياطي وحذفه.\n\nملف النسخ الاحتياطي الخاص بي حوالي 200 جيجابايت مع إعدادات غير محددة تضمين الصور المصغرة التي تم إنشاؤها في النسخ الاحتياطية. تعطيل هذا سيجعل النسخ الاحتياطية أصغر، ولكنه يتطلب إعادة خبز لجميع المشاركات بعد الاستعادة.\n\nلذلك سأنفد من مساحة القرص إذا احتفظت نسختي بملف النسخ الاحتياطي وبدأت في تحسين الصور.
إذا كنت بحاجة إلى مساحة أكبر، فأنت بحاجة إلى مساحة أكبر.
ولكن ربما ترغب في مزامنة الصور واستعادة قاعدة البيانات فقط. بهذه الطريقة لن يكون لديك نسختان من جميع التحميلات (ولن تضطر إلى إنشاء صور مصغرة مرة أخرى.
شكراً لمحاولتك المساعدة.
لقد حاولت ذلك، لكنني لم أكن متأكداً تماماً لماذا لم ينجح استعادتي بشكل جيد.
مشكلتي الرئيسية هي أن نسختي القديمة عالقة على إصدار PostgreSQL 12 ولم أجد طريقة لترقيته، وحاولت الانتقال إلى نسخة جديدة.
هل تعرف ما إذا كان من الممكن استعادة قاعدة البيانات فقط إلى تثبيت جديد؟
عندما حاولت، بدأت النسخة في إرجاع رمز الخطأ 500 وكان علي أن أبدأ من جديد.
ما سأفعله هو اتباع نقل موقع Discourse إلى VPS آخر باستخدام rsync باستثناء عدم نسخ ملفات postgres.
ثم قم بعمل نسخة احتياطية لقاعدة البيانات فقط واستعدها. ستقوم بعمل rsync للنسخة الاحتياطية أيضًا واستعادتها من سطر الأوامر.
هل هذه نسخة قديمة جدًا، على ما أعتقد؟ هل بدا الاستعادة ناجحة؟
إعجاب واحد (1)
شكراً للمساعدة.
نعم، ولكن لاستعادة مباشرة باستخدام واجهة الويب والإجراء المتوقع، تحتاج إلى مساحة حرة تزيد عن 4 أضعاف حجم ملف النسخ الاحتياطي الخاص بك.
إليك الطريقة:
- تحميل ملف النسخ الاحتياطي (أو استخدام rsync في
/var/discourse/shared/standalone/backups/default) - بمجرد بدء عملية الاستعادة، يتم نسخ ملف النسخ الاحتياطي.gz إلى
/var/discourse/shared/standalone/tmp/restores/ - أثناء الاستعادة، يتم فك ضغط ملف النسخ الاحتياطي في مجلد
/var/discourse/shared/standalone/tmp/restores/ - من مجلد tmp، يتم نسخ الملفات المحملة باستخدام rsync إلى مكانها الأصلي ويتم إدخال تفريغ قاعدة البيانات SQL في قاعدة بيانات pg.
كيف نجحت في الاستعادة.
أثناء عملية الاستعادة، بمجرد أن يقوم discourse بنسخ الملف من مجلد الاستعادة إلى temp، قمت بحذف ملف النسخ الاحتياطي الأصلي الذي تم تحميله عبر ssh.
مرة أخرى، عندما انتهى discourse من إدخالات SQL وبدأ rsync في نسخ الملفات غير المضغوطة من مجلد tmp إلى /var/discourse/shared/standalone/uploads/، قمت يدويًا بحذف ملف bakupxxx.tar.gz في مجلد temp عبر ssh دون مقاطعة عملية الاستعادة.
بمجرد أن أصبح مثيلي عبر الإنترنت وانتهى rsync، قمت بتنفيذ:
rm -rf /var/discourse/shared/standalone/tmp/restores/default/*
إذا قمت بعمل نسخة احتياطية كبيرة، فقد تبدو عملية الاستعادة الخاصة بك متوقفة ويبدأ المثيل عبر الويب في إرجاع رمز خطأ 500 (حدث لي مرتين)، يمكنك التحقق من عملية الاستعادة عن طريق الدخول إلى التطبيق
cd /var/discourse
./launcher enter app
ps aux | grep restore
أيضًا، نظرًا لأن استعادة قاعدة البيانات الخاصة بي استغرقت وقتًا طويلاً
cd /var/discourse
./launcher enter app
watch -n 10 “sudo -u postgres psql discourse -c "SELECT now(), state, query FROM pg_stat_activity WHERE state != ‘idle’;””
ساعدني في مراقبة تقدم استعادة قاعدة البيانات، لمعرفة ما إذا كانت الاستعادة لا تزال قيد التشغيل.
هذا حل رائع! إذا وجد أي شخص آخر هذا، أعتقد أن إجراء استعادة قاعدة البيانات فقط كان سيعمل ويكون أسهل قليلاً، ولكن يسعدني أنك تمكنت من حل المشكلة!
إعجاب واحد (1)