إذا بدا ترحيل البيانات في ZimaOS عالقًا عند نسبة منخفضة أثناء نقل البيانات إلى RAID أُنشئت حديثًا، فتحقق أولًا من إعادة بناء RAID وتجنب مقاطعة الترحيل عشوائيًا. قد تبدو واجهة الترحيل متجمدة حتى بينما تواصل طبقة التخزين إعادة المزامنة في الخلفية.
في الحالة المصدرية، ظل الترحيل عند 6% وأصبحت واجهة الويب صعبة الاستخدام، لكن cat /proc/mdstat أظهر أن مصفوفة RAID1 لم تكن قد قطعت سوى نحو نصف الطريق في إعادة مزامنة بطيئة جدًا. هذا عبء عمل على التخزين، وليس دليلًا على تعطل مهمة الترحيل نفسها.
لماذا قد يبدو ترحيل البيانات متجمدًا أثناء إعادة مزامنة RAID
يؤدي إنشاء مصفوفة RAID أو إعادة بنائها إلى عمليات قراءة وكتابة مستمرة عبر الأقراص المكوِّنة لها. وإذا بدأت عملية ترحيل بيانات كبيرة في الوقت نفسه، فسيتنافس العمليان على عرض نطاق القرص وزمن استجابة الإدخال والإخراج.
يشير دليل ترحيل البيانات في ZimaOS الحالي إلى أن الترحيل يستولي على الواجهة أثناء تشغيله وينقل فئات كاملة مثل صور Docker وبيانات تطبيقات Docker ومجلدات المستخدمين. لذلك قد تستغرق المهام الكبيرة وقتًا أطول بكثير من التقدير الظاهر في الواجهة عندما تكون مصفوفة الوجهة مشغولة.
الخطوة 1: تحقق من حالة إعادة بناء RAID من الطرفية
شغّل:
cat /proc/mdstat
بالنسبة إلى RAID md في Linux، ابحث عن مصطلحات مثل إعادة المزامنة, الاسترداد، أو نسبة مئوية للتقدم. تُظهر مصفوفة RAID1 السليمة المكونة من قرصين كلا العضوين عادةً على أنهما [UU]. إذا كانت إعادة المزامنة نشطة، فسجّل النسبة ووقت الانتهاء التقديري والسرعة.
ما الذي يعنيه الوقت التقديري الطويل جدًا؟
قد ينتج الوقت التقديري الطويل للوصول عن الأقراص البطيئة، أو مشكلات في وصلة USB/SATA، أو أعباء عمل متنافسة، أو إعادة مزامنة md المحدودة السرعة عمدًا. ولا يعني ذلك بحد ذاته أن المصفوفة معطلة. تحقق مرة أخرى بعد 10–30 دقيقة وتأكد من أن النسبة تتحرك.
الخطوة 2: تأكد من أن النظام لا يزال ينفذ عملًا مفيدًا
إذا /proc/mdstat يتقدم بمرور الوقت، فهذا يعني أن طبقة التخزين تعمل. لا تحتاج إلى تثبيت iotop لمجرد إثبات ذلك. يُعد ZimaOS نظام تشغيل بأسلوب الأجهزة المخصصة، لذا فإن إضافة حزم المضيف باستخدام أساليب توزيعات Linux التقليدية ليست مسار استكشاف الأخطاء وإصلاحها المفضل.
يمكنك أيضًا التحقق مما إذا كانت الملفات لا تزال قابلة للوصول من عميل آخر. في الحالة المصدرية، ظل الوصول إلى البيانات من الكمبيوتر وتطبيق الهاتف يعملًا، حتى مع بقاء شاشة الترحيل على الويب عند 6%.
الخطوة 3: لا توقف Docker أو تُنهِ عملية الترحيل أولًا
قد يؤدي إيقاف Docker إلى إزالة الخدمات التي تعتمد عليها واجهة الويب في ZimaOS، مما يجعل النظام يبدو أسوأ مع بقاء مشكلة التخزين دون حل. كما أن إيقاف عملية الترحيل أثناء النسخ قد يترك بعض الفئات في الموقع القديم وأخرى في الموقع الجديد.
انتظر حتى تكتمل استعادة RAID النشطة، ما لم تتوقف المصفوفة عن التقدم تمامًا أو تُظهر الأقراص أخطاءً واضحة في الأجهزة.
متى ينبغي أن تشك في أن الترحيل عالق فعلًا؟
تحقّق أكثر إذا ظلت كل هذه الشروط صحيحة لفترة طويلة:
- لا تتغير النسبة المئوية للترحيل؛
-
/proc/mdstatلا يظهر أي إعادة بناء نشطة أو أن النسبة المئوية لا تتقدم مطلقًا؛ - نشاط القرص شبه معدوم؛
- تتوفر في الوجهة مساحة حرة كافية؛
- لا توجد أي انقطاعات واضحة في الشبكة أو الطاقة.
عند هذه النقطة، اجمع إصدار ZimaOS الدقيق، ونوعي التخزين المصدر والوجهة، وفئة الترحيل، وحالة RAID، وأي سجلات ذات صلة قبل إعادة التشغيل.
استخدم سير عمل ترحيل البيانات الحالي
يضع ZimaOS الحالي هذه الميزة ضمن الإعدادات ← ترحيل البيانات. يمكن للأداة نقل صور Docker وبيانات تطبيقات Docker ومجلدات المستخدمين على مستوى الفئة. إذا كنت بحاجة إلى نقل تطبيق واحد فقط، فاستخدم سير عمل مسار تخزين التطبيق بدلًا من ترحيل جميع التطبيقات معًا.
يوضح دليل ترحيل البيانات كيف يختلف الترحيل المُدار عن نقل المجلدات يدويًا.
كيفية منع المشكلة نفسها في المرة القادمة
دع RAID التي أُنشئت حديثًا تُكمل المزامنة قبل بدء ترحيل كبير لبيانات التطبيقات أو بيانات المستخدمين. تأكد من أن الوجهة سليمة وبها مساحة حرة كافية، ثم رحّل فئة واحدة في كل مرة. يقلل ذلك من عمليات الإدخال والإخراج المتنافسة ويجعل عزل الأعطال أسهل.
احتفظ أيضًا بنسخة احتياطية حديثة من البيانات التي لا يمكن تعويضها. تُعد مزامنة RAID وترحيل البيانات عمليتي تخزين، ولا ينبغي اعتبار أي منهما نسخة احتياطية.
الأسئلة الشائعة
هل يمكنني إعادة تشغيل ZimaOS إذا ظل ترحيل البيانات عالقًا عند 6%؟
ليس كخطوة أولى. تحقّق أولًا من نشاط RAID والتخزين. إذا كانت المصفوفة تعيد المزامنة بنشاط، فاتركها حتى تكتمل ما لم يوجد سبب متعلق بالأجهزة أو بالسلامة لإيقافها.
لماذا يقول تقدير الترحيل دقائق بينما يستغرق ساعات؟
لا يمكن للتقدير أن يأخذ في الحسبان بالكامل إعادة بناء RAID البطيئة، أو الأقراص المحمّلة بشدة، أو الأعداد الكبيرة من الملفات الصغيرة. قِس التقدم الفعلي بدلًا من الاعتماد على التقدير الأولي.
هل تعني [UU] أن RAID1 سليمة؟
بالنسبة إلى مصفوفة md RAID1 مكوّنة من عضوين، [UU] يعني أن العضوين المتوقعين موجودان. ولا يعني أن إعادة المزامنة اكتملت بالفعل، لذا افحص أيضًا سطر التقدم.
هل ينبغي أن أثبّت iotop على ZimaOS؟
عادةً لا، ليس لتشخيص هذه الحالة. /proc/mdstat يجيب بالفعل عمّا إذا كانت مصفوفة RAID البرمجية تعيد البناء، كما أن تجنّب إجراء تعديلات غير ضرورية على حزم المضيف يجعل استكشاف الأخطاء وإصلاحها أبسط.
