إذا أُعيد تثبيت ZimaOS وظهرت مصفوفة RAID 1 موجودة على شكل أقراص غير مستخدمة، فلا تنقر فورًا على إنشاء RAID. فقد تؤدي إعادة إنشاء المصفوفة أو تهيئتها إلى تدمير البيانات التي لا تزال موجودة على أقراص العضوية.
ينبغي أن يكون مسار الاسترداد الأول هو طريقة ZimaOS الرسمية الحالية: استعادة الملف المحفوظ local-storage.db من تثبيت النظام السابق. يوثّق الدليل المجتمعي وراء هذه الصفحة إجراءً احتياطيًا أكثر تدخّلًا للحالة الأصعب التي لم تُنسخ فيها قاعدة البيانات احتياطيًا. اختُبر هذا الإجراء الاحتياطي على ZimaOS 1.6.1، لكنه يتضمن عمليات RAID مدمّرة ولا ينبغي النظر فيه إلا بعد نسخ البيانات المصدرية والتحقق منها بشكل مستقل.
الخيار الأول: استعادة local-storage.db
يحتفظ ZimaOS بمعلومات تكوين التخزين في:
/ZimaOS-HD/.casaos/db/local-storage.dbيوصي دليل الاسترداد الرسمي الحالي بتنزيل هذا الملف قبل إعادة تثبيت النظام، ثم إعادته إلى الدليل نفسه بعد تثبيت ZimaOS الجديد وإعادة التشغيل.
الاسترداد الرسمي لـ RAID في ZimaOS بعد إعادة التثبيت
إذا كان لا يزال بإمكانك الوصول إلى قرص النظام القديم، فحاول استرداد قاعدة البيانات هذه قبل لمس أقراص عضوية RAID.
لماذا قد تظل مصفوفة البيانات سليمة
يستخدم ZimaOS تقنية RAID البرمجية في Linux. يمكن لأقراص العضوية الاحتفاظ ببيانات RAID الوصفية حتى عندما لا يعود تثبيت ZimaOS الجديد يحتوي على قاعدة بيانات التخزين القديمة. ولهذا قد تبدو الأقراص موجودة فعليًا بينما لا تعود واجهة المستخدم تتعرّف على التجميعة الأصلية.
قدّم ZimaOS 1.6 أيضًا تحسينات في استرداد بيانات RAID الوصفية وسلوك إعادة التعرّف، لذا لا ينبغي افتراض أن مشكلة ظهرت أصلًا على نظام واحد ستحدث بالطريقة نفسها في كل إصدار أحدث.
لا تنشئ RAID جديدًا قبل اتخاذ قرار بشأن الاسترداد
إذا كانت الأقراص تحتوي على بيانات تحتاج إليها، فتجنّب ما يلي:
- تهيئة أيٍّ من قرصي العضوية؛
- إنشاء RAID جديد فوق الأقراص نفسها؛
- تشغيل
wipefsأوmdadm --zero-superblockسابق لأوانه؛ - التخمين بشأن أي جهاز هو
/dev/sdXما الجهاز؟
قبل تنفيذ أي عمل للاسترداد، حدّد الأقراص حسب الطراز والرقم التسلسلي والسعة، بدلًا من الاعتماد على أحرف الأجهزة فقط.
تحقّق من بيانات RAID الوصفية للقراءة فقط
استخدم مؤلف الدليل المجتمعي الفحص للقراءة فقط أولًا للتأكد من أن عضوي RAID 1 لا يزالان ينتميان إلى المصفوفة نفسها.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL
mdadm --examine /dev/sda
mdadm --examine /dev/sdbبالنسبة إلى RAID 1 سليم، يجب أن يُبلغ كلا العضوين عن معرّف UUID نفسه للمصفوفة وبيانات وصفية متوافقة لـ RAID. إذا كان أحد العضوين مفقودًا أو متدهورًا أو يُبلغ عن بيانات وصفية مختلفة، فتوقّف واطلب المساعدة في الاسترداد بدلًا من اتباع وصفة عامة لإعادة البناء.
جمّع المصفوفة القديمة وثبّتها في وضع القراءة فقط
للاسترداد المتقدم، يقلل التجميع في وضع القراءة فقط من احتمال تعديل المصدر أثناء التحقق من إمكانية الوصول إلى الملفات:
mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb
mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraidثم افحص نظام الملفات:
df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*أسماء الأجهزة أعلاه أمثلة فقط. لا تلصقها كما هي أبدًا ما لم تتأكد من أنها تطابق أجهزتك.
أنشئ نسخة نقل كاملة قبل أي خطوة مدمّرة
استخدم سير العمل الأصلي محرك أقراص خارجيًا بنظام ext4 بسعة تكفي لاحتواء جميع بيانات RAID المستخدمة. وبالنسبة إلى بيانات التطبيقات على Linux، يُعد ext4 مفيدًا لأنه يحافظ على الملكية والأذونات والروابط وقوائم التحكم بالوصول والسمات الموسعة المعتادة.
النسخ النموذجي بأسلوب الأرشفة هو:
rsync -aHAX --info=progress2 /DATA/oldraid/ /DATA/offload/شغّل عملية النسخ في tmux أو استخدم طرفية أخرى مستمرة إذا كان انقطاع اتصال SSH سيؤدي بخلاف ذلك إلى إيقاف العملية.
تحقّق من النسخة الاحتياطية قبل المتابعة
لا تعتمد فقط على سطر انتهاء rsync. قارِن عدد الملفات وافحص أحجام المجلدات الرئيسية:
find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l
du -sh /DATA/oldraid/*
du -sh /DATA/offload/*بالنسبة إلى البيانات التي لا يمكن تعويضها، يُفضَّل وجود نسخة احتياطية مستقلة ثانية. فـ RAID ليس نسخة احتياطية بحد ذاته.
الحل الأخير: نقل البيانات، وإزالة البيانات الوصفية القديمة لـ RAID، وإعادة الإنشاء من الواجهة
كان مؤلف الإجراء الأصلي في المجتمع يريد إعادة المصفوفة المستردة إلى إدارة واجهة ZimaOS العادية. وكانت طريقته كحل أخير هي:
- تحقّق من المصفوفة القديمة في وضع القراءة فقط؛
- انسخ جميع البيانات إلى محرك أقراص خارجي؛
- تحقّق من النسخة؛
- أوقف مصفوفة md القديمة؛
- أزل البيانات الوصفية القديمة لـ RAID؛
- أنشئ RAID 1 جديدًا باستخدام واجهة التخزين في ZimaOS؛
- استعد الملفات المنسوخة؛
- تحقّق من البيانات المستعادة.
يدمّر هذا الإجراء عمدًا البيانات الوصفية القديمة لـ RAID. بعد تنفيذ هذه الخطوة، تصبح النسخة المنقولة مصدر الاسترداد لديك. لا تستخدم هذا الأسلوب إذا كانت النسخة غير مكتملة أو إذا لم تكن متأكدًا من هوية الجهاز.
الأمر غير القابل للعكس في سير العمل الأصلي
الإجراء الذي استخدمه المجتمع:
mdadm --zero-superblock /dev/sda /dev/sdbهذا ليس أمرًا لاستكشاف الأخطاء وإصلاحها. فهو يزيل البيانات الوصفية لـ RAID من الأقراص المحددة. وقد يتسبب مسار جهاز خاطئ في فقدان كبير للبيانات.
لهذا السبب، لا توصي هذه الصفحة بتشغيله لمجرد أن واجهة ZimaOS لا تتعرّف على RAID. استعد local-storage.dbتحقّق من سلوك الاسترداد الحالي في ZimaOS، واتصل بالدعم أولًا عندما تحتوي المصفوفة على بيانات مهمة.
لماذا إعادة إنشاء المصفوفة من خلال واجهة ZimaOS؟
كان هدف سير العمل المصدر هو الانتهاء بمجموعة تخزين تُدار بصورة طبيعية بواسطة ZimaOS، بدلًا من جهاز md مُجمّع يدويًا بشكل دائم خارج واجهة التخزين.
بعد تفريغ البيانات القديمة بأمان وإعادة ضبط الأقراص عمدًا، استخدم واجهة التخزين الحالية لإنشاء RAID 1 ودَع المزامنة الأولية تكتمل.
استعد الملفات إلى المجموعة الجديدة
بعد إنشاء المجموعة الجديدة وتركيبها، استعد من قرص التفريغ:
rsync -aHAX --info=progress2 /DATA/offload/ /media/Storage/استبدل /media/Storage باستخدام مسار الوجهة الفعلي الذي يعرضه نظامك.
تحقّق من مجموعة التخزين المستعادة
find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstatأبقِ محرك التفريغ دون تغيير حتى تكتمل مزامنة RAID، وحتى تتحقق من إمكانية الوصول الطبيعية عبر واجهة ملفات ZimaOS والتطبيقات التي تعتمد على البيانات.
انسخ local-storage.db احتياطيًا قبل إعادة التثبيت التالية
أسهل عملية استرداد هي تلك التي أُعدّ لها مسبقًا. احتفظ بنسخة حديثة من:
/ZimaOS-HD/.casaos/db/local-storage.dbخارج محرك النظام. توفّر الوثائق الرسمية الآن إجراء استعادة مباشرًا باستخدام هذا الملف.
أي مسار استرداد ينبغي أن تختار؟
| الحالة | الإجراء المفضّل |
|---|---|
| لقد نسخت نسخة احتياطية من local-storage.db | استخدم الطريقة الرسمية لاستعادة قاعدة البيانات |
| لا يزال قرص النظام القديم قابلًا للقراءة | استرد local-storage.db قبل تعديل أقراص RAID |
| لا توجد نسخة احتياطية لقاعدة البيانات، وتبدو البيانات الوصفية لـ RAID سليمة | أوقف الإجراءات المدمّرة واطلب الدعم أو مشورة الاسترداد |
| لديك نسخة تفريغ كاملة تم التحقق منها، وتريد عمدًا إنشاء مصفوفة نظيفة تُدار عبر الواجهة | فكّر في طريقة التفريغ/إعادة الإنشاء/الاستعادة التي يقترحها المجتمع |
| تُظهر أعضاء RAID بيانات وصفية غير متطابقة أو متدهورة | توقّف واستخدم إرشادات استرداد متخصصة |
الأسئلة الشائعة حول استرداد RAID في ZimaOS
هل تؤدي إعادة تثبيت ZimaOS تلقائيًا إلى محو بيانات RAID؟
لا. إعادة تثبيت قرص النظام تختلف عن تهيئة أقراص أعضاء RAID. قد يُفقد تكوين التخزين، بينما تبقى بيانات RAID الوصفية والبيانات على الأقراص الأعضاء.
هل ينبغي أن أنقر على «إنشاء RAID» إذا ظهرت الأقراص القديمة على أنها غير مستخدمة؟
ليس قبل أن تتأكد من عدم وجود بيانات حالية تحتاج إلى استردادها. قد يكون إنشاء RAID جديد مدمّرًا.
ما أكثر طرق الاسترداد أمانًا إذا كنت قد نسخت نسخة احتياطية من local-storage.db؟
استخدم الإجراء الرسمي الحالي لـ ZimaOS لاستعادة قاعدة البيانات تلك ثم أعد التشغيل.
هل تصفير الكتلة الفائقة لـ mdadm آمن؟
إنها مدمّرة عمدًا لبيانات RAID الوصفية. استخدمها فقط كجزء من خطة استرداد تم التحقق منها، بعد نسخ البيانات بأمان إلى مكان آخر.
