متى ينبغي إعادة بناء تثبيت Plex بدلًا من إصلاحه؟

أعِد بناء Plex فقط عندما لا تعود حالة التطبيق القديمة مصدرًا موثوقًا للتعافي. إذا كانت هوية الخادم وإعداداته وقاعدة بياناته ومسارات التخزين لا تزال معروفة، فأصلح أصغر طبقة متعطلة أولًا؛ وإذا فشل الإصلاح لكن توجد نسخة احتياطية موثّقة، فاستعدها قبل البدء من جديد.

إعادة التثبيت لا تعني تلقائيًا إعادة البناء. فقد يؤدي استبدال حزمة Plex أو حاويته إلى ترك قاعدة البيانات والإعدادات الدائمة دون تغيير، بينما تعني إعادة البناء الحقيقية التخلي عن تلك الحالة أو إعادة ضبطها عمدًا. اتخذ القرار بناءً على حالة البيانات الدائمة، لا على مدى الإحباط الذي يسببه العطل الحالي.

حدّد الإصلاح والاستعادة وإعادة البناء قبل الاختيار

استخدم ثلاث كلمات مختلفة لثلاثة إجراءات مختلفة. يغيّر الإصلاح أصغر مكوّن تالف مع الحفاظ على حالة Plex الحالية. أما الاستعادة فتستبدل الحالة التالفة بنسخة احتياطية سليمة ومعروفة. وتنشئ إعادة البناء حالة Plex جديدة، مع تقبّل احتمال الحاجة إلى إعادة إنشاء بعض المكتبات والبيانات الوصفية والتفضيلات وحالة المشاهدة أو ترحيلها، فضلًا عن هوية الخادم.

هذا التمييز مهم لأن إعادة تثبيت الملفات الثنائية للتطبيق قد تترك حالة Plex كما هي. وتذكر Western Digital أن عملية إلغاء التثبيت الموثّقة على My Cloud تترك مكتبات Plex وقاعدة بياناته في مكانها؛ أما إعادة الضبط فتتطلب خطوة منفصلة لحذف الحالة.

قبل اختيار إعادة البناء، حدّد الطبقة المعطلة فعليًا: الحزمة أو الحاوية، أو تعريف وقت التشغيل، أو وحدة التخزين المركّبة، أو الأذونات، أو التفضيلات، أو قاعدة بيانات المكتبة. لا يعالج التثبيت الجديد سوى بعض هذه الطبقات، لذا قد يؤدي استخدامه كاستجابة أولى إلى إخفاء العطل الحقيقي من دون إزالته.

ابدأ بالإصلاح عندما تظل حالة Plex الأصلية موثوقة

ابدأ بالإصلاح عندما يفتح Plex الخادم المتوقع، ويكون مسار بيانات التطبيق ممتلئًا، وتكون قاعدة البيانات موجودة، ويكون العطل ضيق النطاق بما يكفي لإعادة إنتاجه. ومن الأمثلة على ذلك قاعدة بيانات تالفة لا يزال لها مسار استعادة قابل للقراءة، أو فهرس معطّل، أو خطأ واحد في الإعدادات يمكن التراجع عنه.

يوضح دليل عملي حديث سير عمل لإصلاح قاعدة البيانات يوقف Plex، ويشغّل أداة الإصلاح، ثم يعيد تشغيل الخادم بدلًا من التخلص من التثبيت بالكامل. والمبدأ المفيد هو الحفاظ على الحالة الحالية مع اختبار إمكانية جعل الطبقة التالفة صالحة مرة أخرى.

لا تعتمد الإصلاح إلا عندما تعود هوية الخادم نفسها، وتفتح المكتبات النموذجية، وتعمل عمليات البحث وحالة المشاهدة بصورة طبيعية، ولا يعيد التشغيل المنضبط العطل. إذا أبلغت أداة الإصلاح عن فشل أو ظلت قاعدة البيانات غير صالحة، فتوقف عن تكرار التعديل نفسه وانتقل إلى مسار الاستعادة.

انتقل إلى الاستعادة عندما يتعذر على الإصلاح إعادة قاعدة بيانات صالحة

لا يعني فشل الإصلاح تلقائيًا ضرورة إعادة البناء. إذا كانت لديك نسخة احتياطية موثّقة من فترة سبقت التلف، فاستعد تلك النسخة في موقع معزول أو يمكن التراجع عنه بوضوح، واختبرها قبل حذف الحالة الحالية.

تتعامل مقالة عملية عن استعادة قاعدة بيانات Plex مع استعادة نسخة احتياطية من قاعدة البيانات باعتبارها مسار التعافي التالي بعد فشل الإصلاح. ويحافظ ذلك على قدر أكبر من الخادم الأصلي مقارنة بإعادة البناء النظيفة عندما تكون النسخة الاحتياطية نفسها سليمة.

ينجح مسار الاستعادة عندما يتمكن Plex من فتح الحالة المستعادة، والتعرّف على المكتبات ومسارات الوسائط المتوقعة، وتحمل إعادة تشغيل أخرى من دون تكرار خطأ قاعدة البيانات. وإذا كانت كل النسخ الاحتياطية المتاحة غير قابلة للقراءة أو ناقصة أو تحتوي أصلًا على التلف نفسه، يصبح تجاوز عتبة إعادة البناء أقرب.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

أعِد البناء عندما يكون مصدر الحالة مفقودًا أو لم يعد موثوقًا

أعِد البناء عندما لا يعود بالإمكان الوثوق بالمصدر الدائم الذي كنت ستصلحه أو تستعيده. وقد يعني ذلك فقدان مجلد بيانات التطبيق، أو عدم وجود نسخة احتياطية قابلة للاستخدام، أو تعذر إصلاح قاعدة البيانات أو استعادتها، أو إظهار الاختبارات المتكررة أن الحالة المستعادة تعود فورًا إلى العطل نفسه غير القابل للتعافي.

قد تكون إعادة البناء أيضًا خيارًا مقصودًا عندما يحتوي التثبيت القديم على عمليات ترحيل غير مؤكدة امتدت لسنوات، وتفضّل هوية خادم جديدة على الاستمرار في حمل حالة مجهولة. والمقايضة حقيقية: فالحالة النظيفة تزيل السجل التالف، لكنها تزيل أيضًا افتراض بقاء البيانات الوصفية والتفضيلات والعلاقات القديمة تلقائيًا.

لا تعتبر تكرار التلف دليلًا على أن قاعدة بيانات Plex النظيفة هي المشكلة الوحيدة. فإذا أصبحت الحالة المعاد بناؤها تالفة مرة أخرى، فتحرَّ عن نظام الملفات، وجهاز التخزين، وفقدان الطاقة المفاجئ، واستقرار الذاكرة، وغيرها من الأسباب الأساسية. لا تستطيع إعادة بناء التطبيق أن تجعل طبقة تخزين الحالة غير الموثوقة جديرة بالثقة.

لا تُعد البناء بسبب عطل في الحاوية أو وحدة التخزين أو الأذونات

قد تجعل حاوية لا تبدأ، أو وحدة وسائط مركّبة فارغة، أو خطأ في الأذونات، أو اسمًا مستعارًا مفقودًا للشبكة، Plex يبدو معطّلًا بالكامل بينما تظل حالته الدائمة سليمة. هذه أعطال في وقت التشغيل أو التبعيات، وليست دليلًا على ضرورة التخلص من قاعدة بيانات المكتبة.

يحافظ سير عمل ZimaSpace الخاص بـ استعادة حاوية واحدة على وحدات التخزين والتبعيات السليمة، مع استبدال طبقة الخدمة المتعطلة فقط. وهذا هو النموذج الأكثر أمانًا عندما تكون حالة Plex سليمة لكن البيئة المحيطة بوقت التشغيل قد تغيّرت.

إذا أدت إعادة توصيل وحدة التخزين أو الهوية أو الشبكة أو تعريف الحاوية الصحيح إلى إعادة الخادم الأصلي، فتوقف عند هذا الحد. فإعادة البناء ستضيف أعمال ترحيل من دون إصلاح مشكلة مثبتة في الحالة الدائمة. ولا تنتقل إلى الاستعادة أو إعادة البناء إلا عندما يتبع العطل حالة التطبيق نفسها.

حافظ على الأدلة ونقطة تعافٍ قبل البدء من جديد

قبل إعادة البناء الحقيقية، احتفظ بشجرة بيانات التطبيق القديمة، ونسخ قواعد البيانات الاحتياطية، والتفضيلات، وتعريف النشر، والسجلات، والخطأ الدقيق الذي دفعك إلى التوقف عن الإصلاح. حتى الحالة التالفة قد تحتوي على سجل المشاهدة أو البيانات الوصفية أو تفاصيل الإعدادات المفيدة أثناء الترحيل أو مراجعة ما بعد العطل.

أنشئ الخادم الجديد بجوار نقطة التعافي المحفوظة بدلًا من الكتابة فوقها في مكانها، متى سمحت مساحة التخزين بذلك. أضف مكتبة نموذجية واحدة، وتحقق من قاعدة البيانات الجديدة، ثم رحّل فقط الحالة التي تثق بها عمدًا. يجعل ذلك خيار «البدء من جديد» قابلًا للتراجع حتى تثبت أن الخادم الجديد يحل العطل الأصلي فعلًا.

القرار النهائي بسيط: أصلح ما دامت الحالة الحالية موثوقة، واستعد عندما تتمكن نسخة سليمة ومعروفة من استبدال الحالة التالفة، وأعِد البناء فقط عندما لا ينتج أي من المسارين خادمًا صالحًا يمكن التحقق منه بصورة متكررة. واحتفظ بالأدلة السابقة حتى يصمد التثبيت النظيف أمام الاستخدام العادي وإعادة التشغيل وإنشاء نسخة احتياطية جديدة.