هل يمكن لـ Plex الانتقال بين ARM وx86 دون فقدان بياناته؟
تعامل مع نقل Plex من ARM إلى x86 أو من x86 إلى ARM باعتباره ترحيلًا للحالة واختبارًا لتوافق الميزات، وليس مجرد نسخ أعمى.
قد تكون قاعدة البيانات والبيانات الوصفية قابلة للنقل، لكن الملفات التنفيذية وميزات تحليل الوسائط والتسريع العتادي وافتراضات المسارات قد تختلف بين المنصات. أبقِ الخادم الأصلي حتى يجتاز الخادم الجديد فحوصات المكتبة وحالة المشاهدة والبيانات الوصفية والتشغيل والميزات. لا تحذف المصدر لمجرد أن الخدمة الجديدة بدأت العمل.
انقل مجموعة الحالة كاملة، وليس ملفًا واحدًا مناسبًا
تشمل حالة Plex ما هو أكثر من قاعدة بيانات مكتبة واحدة. فنسخ ملف واحد فقط قد يحافظ على جزء من السجل، بينما يجبر البيانات الوصفية أو الفهارس الأخرى على إعادة البناء.
يضمن النقل الآمن الحفاظ على دليل بيانات خادم Plex بالكامل، بما في ذلك البيانات الوصفية والإعدادات وحالة العرض، بدلًا من نسخ قاعدة بيانات المكتبة فقط.
انسخ دليل حالة Plex بالكامل بعد إيقاف الخادم، مع الحفاظ على الملكية وبنية الملفات. اترك المصدر دون تغيير حتى يجتاز المضيف الجديد عملية تحقق كاملة.
حافظ على ثبات مسارات الوسائط أو أعد تعيينها بشكل متعمد
لا تجعل قابلية نقل قاعدة البيانات سلاسل المسارات قابلة للنقل تلقائيًا. فقد يؤدي اختلاف نقطة التحميل أو أسلوب المسارات في نظام التشغيل إلى جعل السجلات الصحيحة تشير إلى وسائط غير متاحة.
أنشئ خريطة للمسارات قبل التشغيل وقارن بين جذور الوسائط القديمة والجديدة. وإذا أدى تغيير البنية أيضًا إلى تغيير نظام التشغيل، فتعامل مع ترجمة المسارات كخطوة ترحيل مستقلة.
اختبر عنصرًا واحدًا من كل مكتبة قبل إجراء فحص واسع. وتقلل عمليات التحميل المستقرة ضمن تخطيط بيانات الحاويات المستمر عدد العناصر المتغيرة أثناء تبديل البنية.
تحقق من الميزات الخاصة بالبنية بشكل منفصل
قد يختلف تحويل الترميز العتادي وبعض وظائف التحليل والميزات المعتمدة على برامج التشغيل، حتى عندما تعمل حالة المكتبة الأساسية. لا تستنتج تكافؤ الميزات من نجاح تسجيل الدخول.
لا تضمن حالة Plex المشتركة تطابق الميزات بين البنى؛ إذ قد تستمر اختلافات التحليل بين ARM وx86 حتى بعد ترحيل قاعدة البيانات ومسارات الوسائط بنجاح.
أنشئ قائمة تحقق للتشغيل المباشر، وتحويل الترميز، ومسار HDR/الترجمة، وميزات التحليل، والوصول عن بُعد. ويجب التعامل مع فشل ميزة ما على البنية الجديدة فقط باعتباره عملًا متعلقًا بالتوافق، لا فقدانًا للبيانات.
حافظ على نقطة للرجوع إلى الحالة السابقة حتى يثبت الاستخدام الطبيعي
يكون الترحيل آمنًا عندما يظل بالإمكان استعادة الخادم القديم إذا كشف المضيف الجديد عن مشكلة متأخرة. فبضع دقائق من التصفح الناجح لا تكفي لإيقاف المصدر نهائيًا.
شغّل المضيف الجديد خلال يوم عادي، وأجرِ تغييرًا في المكتبة، وإعادة تشغيل، واختبارًا للنسخ الاحتياطي والاستعادة. وإذا غيّرت البنية الحالة المخزنة بطريقة لا يستطيع المضيف القديم إعادة استخدامها بأمان، فاستعد من نسخة ما قبل الترحيل بدلًا من التبديل المتكرر بين الدليلين المباشرَين.
لا توقف المضيف القديم نهائيًا إلا بعد اجتياز الخادم الجديد لهذه الاختبارات والتحقق من نسخة احتياطية حديثة.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكن لـ Jellyfin مشاركة وحدة معالجة رسومات أو مسرّع بأمان مع حاوية أخرى؟
مشاركة وحدة معالجة الرسومات (GPU) مشروطة: تحقّق من ظهور الجهاز ودعم برنامج التشغيل، ثم شغّل كلا الحملين وراقب التحوّل إلى بديل برمجي.
كيفية معرفة ما إذا كان خطأ Jellyfin ناتجًا عن العميل أم الخادم
يكون خطأ Jellyfin من جهة العميل عندما يحدث مع جهاز واحد؛ ويكون من جهة الخادم عندما تفشل عدة عملاء عبر المسار نفسه وتتوافق السجلات.
كيفية تهيئة ذاكرة التخزين المؤقت والتخزين المؤقت في Jellyfin
افصل بين الحالة الدائمة وذاكرة التخزين المؤقت القابلة لإعادة البناء وتخزين التحويل المؤقت، ثم تحقّق من السعة والأذونات باستخدام اختبار تشغيل فعلي.
