كانت استعادة المصدر مباشرة وواضحة، وقد تحقّق منها المستخدم: كان هناك قرص واحد مُعلَّم بالحالة تالف ضمن مصفوفة RAID 5 مكوّنة من أربعة أقراص. أوقف المالك تشغيل ZimaCube، واستبدل ذلك القرص، ثم أعاد تشغيل النظام، واتبع مطالبات التخزين في ZimaOS، وأفاد بأن إعادة البناء بدأت مع تقدير بقاء 13.5 ساعة.
تصف وثائق ZimaOS الحالية سير العمل المُدار نفسه بمزيد من التفصيل: عند تعطل قرص في مصفوفة RAID، تصبح المصفوفة في حالة تدهور، وتظل البيانات قابلة للوصول، وبعد استبدال القرص المتعطل، يوجّه ZimaOS المستخدم خلال عملية إعادة البناء. كما أفاد المصدر القديم بأن مصفوفة RAID 0 أخرى أصبحت للقراءة فقط في الوقت نفسه؛ لكن الوثائق الحالية لا تصف ذلك على أنه السلوك الدائم المعتاد لكل مصفوفة غير مرتبطة.
تأكّد من القرص الفعلي الذي تعطل
قبل سحب أي قرص، طابق حالة التخزين في ZimaOS مع حجرة القرص الفعلية ورقمها التسلسلي. في مصفوفة RAID 5 متدهورة، قد يؤدي إخراج عضو سليم بالخطأ إلى تحويل تعطل قرص واحد إلى انقطاع أكثر خطورة لعدة أقراص.
انسخ البيانات المهمة احتياطيًا قبل إعادة البناء إذا كانت المصفوفة لا تزال قابلة للوصول
تتحمل RAID 5 تعطل عضو واحد، لكن إعادة البناء تقرأ بكثافة من كل قرص سليم متبقٍ. وإذا كان أحد الأقراص الأخرى يعاني من حالة SMART متدهورة أو من قطاعات غير قابلة للقراءة، فستظهر هذه المشكلات بأكبر أثر أثناء إعادة البناء.
إذا كانت المصفوفة قابلة للوصول وكانت البيانات غير قابلة للاستبدال، فانسخ أهم الملفات إلى مساحة تخزين مستقلة قبل بدء إعادة بناء طويلة، متى كان ذلك عمليًا.
استبدل المصدر القرص أثناء إيقاف التشغيل
أوقف المستخدم تشغيل ZimaCube قبل استبدال القرص التالف. ويُعد ذلك الخيار الافتراضي الأكثر أمانًا عندما لا تعتمد صراحةً على سير عمل موثّق للاستبدال أثناء التشغيل.
بعد تثبيت القرص البديل، شغّل الجهاز ودَع ZimaOS يكتشف المصفوفة المتدهورة والقرص الجديد المؤهل.
استخدم مطالبة إعادة البناء في ZimaOS
لم ينشر المستخدم في المصدر أمر إصلاح يدويًا باستخدام mdadm. بل اتبع مطالبات واجهة التخزين، وبدأت إعادة البناء بنجاح.
وتقول إرشادات IceWhale الحالية للتخزين الشيء نفسه: استبدل القرص المتعطل ودَع ZimaOS يوجّهك خلال عملية إعادة البناء.
استخدم سير عمل استعادة التخزين الحالي في ZimaOS.
استخدم قرصًا بديلًا مساويًا للحجم أو أكبر
يجب أن يكون القرص البديل كبيرًا بما يكفي ليتوافق مع بنية أعضاء RAID. وقد يختلف قرصان يُسوَّقان بالسعة الاسمية نفسها قليلًا في عدد القطاعات القابلة للاستخدام، لذا فإن مطابقة الطراز والسعة، متى أمكن، تقلل المفاجآت.
راقب تقدم إعادة البناء وصحة الأقراص
أضاف ZimaOS 1.3.2 والإصدارات الأحدث عرضًا أوضح للتقدم في عمليات إعادة بناء RAID وحساب التكافؤ. أثناء إعادة البناء، تجنّب عمليات إيقاف التشغيل غير الضرورية، وراقب درجات الحرارة وحالة SMART، وخفّف أعباء العمل الثقيلة قدر الإمكان.
تحقّق من المصفوفة بعد الاستعادة
عند انتهاء إعادة البناء، تأكّد من الآتي:
- عودة حالة RAID إلى سليمة؛
- نشاط جميع الأعضاء المتوقعة؛
- قدرة المشاركات والتطبيقات على القراءة والكتابة بصورة طبيعية؛
- فتح الملفات المهمة بصورة صحيحة؛
- كون نسختك الاحتياطية المستقلة محدّثة.
كانت مصفوفة RAID 0 الثانية في المصدر، والتي أصبحت للقراءة فقط، عَرَضًا منفصلًا
أفاد المستخدم بأن كلتا المصفوفتين وُضعتا في وضع القراءة فقط، رغم أن القرص التالف كان ضمن RAID 5 فقط. ولم يوضّح النقاش سبب حماية مصفوفة RAID 0 غير المرتبطة بهذه الطريقة، أو الإجراء الدقيق الذي أعاد إليها صلاحية الكتابة.
لا تفترض أن نظام ZimaOS الحالي سيجعل دائمًا كل مصفوفة للقراءة فقط بعد تعطل RAID واحد.
الأسئلة الشائعة حول استعادة RAID 5
هل بدأ المستخدم في المصدر إعادة بناء RAID 5 بنجاح؟
نعم. بعد استبدال القرص المتعطل واتباع المطالبات، دخلت المصفوفة في وضع الاستعادة مع تقدير بقاء نحو 13.5 ساعة.
هل ينبغي أن أشغّل أوامر mdadm يدويًا أولًا؟
ليس وفق سير العمل المؤكد في المصدر. استخدم مسار إعادة البناء المُدار في ZimaOS، ما لم يزوّدك دعم IceWhale بتعليمات خاصة بإصدارك عبر سطر الأوامر.
هل تُعد RAID 5 نسخة احتياطية؟
لا. تحافظ RAID على الإتاحة عند تعطل قرص واحد، لكنها لا تحمي من الحذف العرضي أو تلف البيانات أو السرقة أو تعطل آخر أثناء إعادة البناء.
