أهم تصحيح في هذا المصدر هو أن المصفوفة لم تبقَ مصنفة مؤكدًا على أنها RAID تعطل فيه «قرص واحد». فبعد أن أقلع المستخدم باستخدام كل قرص على حدة، كان كلا القرصين قابلًا للاستخدام بشكل مستقل. وأدت إعادة توصيل القرصين معًا إلى ظهور [UU] في /proc/mdstat، ما يعني أن كلا عضوي RAID 1 كانا موجودين ومتزامنين في تلك اللحظة.
ثم توسّع النقاش ليشمل عدم استقرار SATA/الوصلة/الطاقة، وأعطال USB/الشاشة، وعمليات الإقلاع في الوضع الطارئ، وأخطاء NFS، وعودة ZimaOS إلى فتحة النظام الأخرى. تم استرداد البيانات، لكن المصدر لا يثبت سببًا نهائيًا واحدًا. لا تحوّل الأمر إلى دليل بسيط من نوع «استبدل القرص X».
لا تنقر على «كسر» أو «تهيئة» ما دام الاسترداد ممكنًا
كانت أول نصيحة من المجتمع صحيحة من ناحية السلامة: إذا كانت البيانات مهمة وكانت الحالة الحقيقية للمصفوفة غير معروفة، فقد تجعل إجراءات واجهة المستخدم المدمرة عملية الاسترداد أكثر صعوبة. انسخ البيانات القابلة للقراءة احتياطيًا أولًا.
عمل كل قرص عند اختباره منفردًا
فصل صاحب المنشور القرصين واحدًا تلو الآخر، وقال إن كل قرص أتاح نظامًا/مسار بيانات قابلًا للاستخدام. وقد أضعف ذلك فورًا افتراض أن أحد القرصين قد تعطل فعليًا.
إعادة توصيل كلا القرصين نتج عنها مصفوفة md بحالة [UU] سليمة
أظهرت الحالة المنشورة md0 : active raid1 ... [2/2] [UU]. عند تلك النقطة، اعتبرت طبقة Linux md أن كلا العضوين موجود.
ولهذا تحوّل النقاش لاحقًا نحو استقرار الكابلات ومنافذ SATA ووحدة التحكم والمحوّل/اللوحة الخلفية والطاقة، بدلًا من الاكتفاء ببيانات RAID الوصفية.
قد يتنكر عدم استقرار SATA/الطاقة في صورة عطل في RAID
أفاد المصدر لاحقًا بوجود أعطال أوسع أثرت في سلوك SATA وUSB والشاشة. وشملت اقتراحات المجتمع استبدال كابلات SATA، وتجربة منافذ مختلفة، وتجنب المقسمات/المحوّلات الهامشية، وإجراء اختبارات إجهاد مع مراقبة عمليات إعادة ضبط الإدخال/الإخراج.
كانت تلك تشخيصات من المجتمع، وليست عيبًا في الأجهزة أكدته IceWhale.
كانت مشكلات الوضع الطارئ وNFS اللاحقة طبقة منفصلة
بعد تغيير الكابلات وإعادة التشغيل، دخل النظام في الوضع الطارئ وظهرت أعطال مرتبطة بـ NFS وRPC. ولم تُسفر محاولات المجتمع لمسح حالة NFS أو تعطيل NFS عن إصلاح مؤكد.
لا تستنتج أن NFS تسبب في تعذّر الوصول إلى RAID في البداية؛ فقد ظهر لاحقًا في نظام كان يعاني بالفعل من عدم استقرار أوسع.
عاد النظام أيضًا إلى فتحة ZimaOS الأخرى
أفاد المستخدم بأنه أقلع من الكتلة/الفتحة B بدلًا من A. يستخدم ZimaOS الحالي فتحتين للنظام للاسترداد، لذا قد يشير التراجع إلى فشل إحدى فتحتي النظام في اجتياز فحوصات السلامة/الإقلاع، لا إلى فقدان بيانات المستخدم الموجودة على RAID.
راجع نموذج الاسترداد الحالي ذي الفتحتين في ZimaOS.
يحتوي ZimaOS الحالي على سير عمل رسمي لإصلاح RAID 1
أضاف ZimaOS 1.4.4 إصلاح RAID1 للمصفوفات المتدهورة/التالفة، وأصلح مشكلة عدم توفر الأقراص المستخدمة سابقًا أثناء الاسترداد.
استخدم ميزة إصلاح RAID1 الرسمية قبل تطبيق أوامر mdadm اليدوية القديمة التي تُجري تغييرات.
بيانات RAID الوصفية أكثر مرونة في إصدارات ZimaOS الأحدث
أضاف ZimaOS 1.6.0 آلية لحفظ بيانات RAID الوصفية، صُممت لإعادة التعرّف تلقائيًا على المصفوفة الأصلية وتركيبها بعد إعادة تثبيت نظام التشغيل أو استبدال الجهاز. وهذا يحسّن مسار الاسترداد مقارنةً بالفترة التي يتناولها المصدر، وهي إصدارات 1.5.x.
ترتيب الاسترداد الحالي الأكثر أمانًا
- لا تقم بتهيئة المصفوفة أو تفكيكها.
- حدّد طُرز الأقراص وأرقامها التسلسلية وحالة RAID الحالية باستخدام تشخيصات للقراءة فقط.
- انسخ البيانات التي يمكن الوصول إليها احتياطيًا فورًا.
- افحص الكابلات والمنافذ والطاقة وSMART وسجلات إدخال/إخراج النواة وإعادة الضبط.
- استخدم واجهة إصلاح RAID الحالية عندما تكون المصفوفة متدهورة فعلًا.
- تعامل مع استرداد فتحة نظام التشغيل بشكل منفصل عن استرداد بيانات RAID.
وصل مسار الاسترداد في النهاية إلى خيارات إعادة ضبط/استرداد ZimaOS
تعني حالة md [UU] أن عضوي RAID 1 كليهما كانا موجودين في تلك اللحظة
بعد إعادة توصيل القرصين، أظهر المصدر أن المصفوفة نشطة وتضم عضوين و [UU]. كان ذلك دليلًا قويًا على أن المرآة نفسها أُعيد تجميعها بنجاح في تلك اللحظة.
لا يوضح سبب ظهور المصفوفة سابقًا على أنها غير قابلة للوصول، أو سبب استمرار عدم استقرار SATA/USB/الشاشة لاحقًا.
التشخيصات للقراءة فقط أكثر أمانًا من أوامر إصلاح mdadm اليدوية
طلب المجتمع معلومات حول المصفوفة/الحالة قبل اقتراح التغييرات. وهذا هو الترتيب الصحيح: حدّد الأجهزة التي تنتمي إلى المصفوفة، وما إذا كانت نشطة/متدهورة، وما الذي تُبلغه النواة، قبل إضافة الأعضاء أو إزالتهم أو إعادة إنشاء بيانات التعريف.
لا تنسخ mdadm --createأو أمر التجميع الإجباري أو مسح الكتلة الفائقة من حالة Linux أخرى إلى RAID الذي يحتوي على النسخة الوحيدة من بياناتك.
انسخ البيانات المهمة مرة واحدة عند إمكانية قراءة المصفوفة
تمكّن مستخدم المصدر من استعادة الوصول. عند هذه النقطة، ينبغي أن تكون الأولوية لنسخ البيانات التي لا يمكن استبدالها إلى وحدة تخزين مستقلة قبل مواصلة التجارب بالكابلات أو وحدات التحكم أو فتحات النظام أو NFS أو إعادة التثبيت.
يوفر RAID 1 تكرارًا، لكن عدم استقرار المضيف/وحدة التحكم قد يجعل كلا العضوين غير متاحين في الوقت نفسه.
عند ظهور مشكلات SATA وUSB والعرض معًا، وسّع نطاق التشخيص
لم تعد الأعراض اللاحقة تشير إلى حالة واضحة لفشل قرص واحد. قد يشير الكشف المتقطع عن SATA، وسلوك USB، ومشكلات الشاشة/الإقلاع إلى الكابلات أو الطاقة أو وحدة التحكم أو البرامج الثابتة للوحة الأم أو عدم استقرار آخر في المنصة.
اختبر طاقة وكابلات معروفة بسلامتها، وبسّط إعداد الأجهزة قبل إعادة بناء RAID مرارًا.
استرداد فتحة النظام واسترداد RAID منفصلان
يمكن لـ ZimaOS الإقلاع من فتحات نظام بديلة لاسترداد نظام التشغيل. يمكن أن يؤدي الرجوع إلى الفتحة B إلى إصلاح مشكلة في فتحة نظام التشغيل أو تجاوزها، لكنه لا يصلح مصفوفة متدهورة بحد ذاته.
استخدم نموذج استرداد نظام ZimaOS الحالي عندما تكون فتحة نظام التشغيل أيضًا غير سليمة.
افصل أقراص البيانات عند إعادة تثبيت نظام التشغيل إذا دعت خطة الاسترداد إلى ذلك
أوصى مجتمع المصدر بعزل أقراص RAID أثناء إعادة تثبيت نظام التشغيل بشكل نظيف لتقليل احتمال اختيار محرك الأقراص الخطأ أو تعديله. إذا قدم دعم IceWhale الحالي خطة لإعادة التثبيت، فضع علامة على كل قرص واحفظ بيانات تعريف التخزين والنسخ الاحتياطية أولًا.
الأسئلة الشائعة حول استرداد RAID 1
هل كان أحد القرصين تالفًا نهائيًا بشكل مؤكد وفقًا للمصدر؟
لا. عمل كلا القرصين لاحقًا بشكل مستقل، وظهرت المصفوفة [UU] عند إعادة التوصيل.
هل حدّد المصدر سببًا جذريًا نهائيًا واحدًا؟
لا. تداخلت مشكلات RAID، وعدم استقرار SATA/الطاقة، وبدء تشغيل NFS، وفتحات نظام التشغيل.
هل يتضمن ZimaOS الحالي إصلاحًا لـ RAID1؟
نعم. أضافت IceWhale سير عمل رسميًا لإصلاح RAID1 في الإصدار 1.4.4.
