مصفوفة RAID 5 أو RAID 6 المتدهورة مع فشل محرك الأقراص الثاني أثناء إعادة الإنشاء (لماذا لا تقم مطلقًا بتشغيل CHKDSK أو fsck واستنساخ قطاع ddrescue وتجميع mdadm للقراءة فقط)¶

استبدال القرص الصلب الفاشل في حالة متدهورة RAID 5 أو RAID 6 خادم التخزين، Synology DiskStation، QNAP NAS، Linux mdadm مجموعة، أو ديل PERC / حصان Smart Array / إل إس آي MegaRAID وحدة تحكم الأجهزة فقط لمشاهدة رمي محرك الأقراص العضو الثاني المتبقي UNC (خطأ قراءة غير قابل للتصحيح) القطاعات التالفة، Pending Sectors، أو قم بالإسقاط دون اتصال على 42% تعد عملية إعادة بناء التكافؤ** واحدة من أخطر حالات طوارئ التخزين في حوسبة المؤسسات والمختبرات المنزلية. في تكافؤ واحد RAID 5 مصفوفة (N - 1 التسامح مع الخطأ)، تتطلب إعادة بناء XOR الرياضية للقرص البديل قراءة كل قطاع على حدة (LBA 0 إلى LBA النهائي) عبر ** 100 بالمائة من الباقي N - 1 يدفع الأعضاء في وقت واحد **. عندما الحديثة ذات قدرة عالية 8 TB ل 24 TB تخضع محركات أقراص الهيليوم (التي تم شراؤها من نفس دفعة التصنيع وتخضع لساعات حرارية واهتزازات متطابقة) لعملية إعادة بناء تسلسلية متعددة تيرابايت، وهو عيب كامن واحد في الوسائط (URE) أو يؤدي ضعف رأس القراءة على محرك الأقراص الثاني إلى قيام وحدة تحكم RAID بإلغاء عملية إعادة البناء، وطرد محرك الأقراص الثاني كـ Faulty / Crashed، ووضع علامة على مجمع التخزين بالكامل Offline / Crashed / Superblock Event Count Mismatch.

لا داعي للذعر، ولا تجبر على إعادة بناء ثانية أو تشغيل أدوات مساعدة لإصلاح نظام الملفات (fsck, e2fsck, xfs_repairأو ويندوز CHKDSK). حتى عند القيادة الثانية RAID 5 (أو القيادة الثالثة في RAID 6) يتطور 50 ل 5,000 القطاعات السيئة ويتم طردها من المصفوفة، 99.9999 بالمائة من القطاعات الموجودة على محرك الأقراص الثاني "الفاشل" لا تزال قابلة للقراءة بنسبة 100 بالمائة. من خلال إيقاف المصفوفة على الفور، واستنساخ كل قرص عضو غير مستقر قطاعًا تلو الآخر على محركات أقراص احتياطية سليمة باستخدام GNU ddrescue، وتجميع الصور المستنسخة في **Read-Only / --assume-clean وضع التراكب ** (mdadm + dmsetup تراكبات حلقة النسخ عند الكتابة)، يمكنك تحميل نظام الملفات بأمان ونسخ كل ملف تقريبًا سليمًا. للتعرف على مواصفات أجهزة NAS وأعطال وحدة التحكم في الأجهزة، اقرأ الأدلة المصاحبة لدينا إسقاط محرك أقراص RAID 5 أو RAID 6 Synology أو QNAP أو TrueNAS المتعدد, موت بطاقة تحكم RAID واستيراد التكوين الأجنبي، و تدهورت مجموعة NAS RAID وتم استرداد ZFS/Btrfs. إذا كان فشل الخادم الخاص بك يؤثر على أنظمة سلامة الحياة أو البنية التحتية الطبية، فاتصل برقم الطوارئ المحلي (911 في الولايات المتحدة وكندا، 112 في جميع أنحاء الاتحاد الأوروبي، 999 في المملكة المتحدة) أو تحقق من الدليل الخاص بنا أرقام الطوارئ.

افعل هذا الآن¶

1. ** قم بإيقاف أي إعادة بناء تكافؤ نشط أو تنظيفه على الفور وإيقاف تشغيل المصفوفة بشكل نظيف (أو افصل طاقة اللوحة الإلكترونية المعززة SATA/SAS إذا كان محرك الأقراص يصدر أصوات نقر أو كشط ميكانيكية) **:
2. ** لماذا يؤدي السماح بإعادة البناء المتوقفة إلى تدمير المصفوفة **: عندما يصل محرك الأقراص العضو إلى تصحيح قطاع تالف (LBA مهلة القراءة) أو لديه رأس قراءة/كتابة مهين (media scratch)، يؤدي ترك وحدة تحكم RAID لإعادة محاولة القطاعات لساعات إلى طحن طبقة الطلاء المغناطيسي المجهري إلى غبار عبر أسطوانة المسار بأكملها، مما يؤدي إلى تحويل ملف قابل للاسترداد 20-sector خلل في تحطم رأس طبق كامل كارثي.
3. ** لا تركض أبدًا CHKDSK /f, fsck -y, e2fsck, btrfs check --repairأو xfs_repair على مصفوفة RAID متدهورة أو غير متزامنة أو نصف مُعاد بناؤها**:
4. ** لماذا CHKDSK و fsck التسبب في تدمير دائم للبيانات بنسبة 100% في RAID غير المتزامن**: إذا انقطع محرك الأقراص 2 يوم الثلاثاء وانقطع محرك الأقراص 3 أثناء إعادة البناء يوم الخميس، فإن mdadm أو RAID الأجهزة Event Counter (Update Time) على هذين المحركين يختلف بآلاف المعاملات. إذا قمت بفرض تجميع مصفوفة باستخدام أجيال محركات أقراص غير متطابقة أو خطوط مفقودة والسماح بذلك fsck أو CHKDSK للكتابة إلى المصفوفة، يرى مدقق نظام الملفات أشجار inode مكسورة بسبب خطوط RAID غير المتوافقة، يحذف الملايين من إدخالات الدليل الصالحة إلى lost+found، ويستبدل خطوط البيانات الجيدة بتماثل تالف عبر كل قرص في المصفوفة.
5. ** لا تنقر أبدًا "Create Array", "Initialize"أو "Clear Configuration" في BIOS RAID الأجهزة، وتشغيل أبدا mdadm --create بدون --assume-clean والنسخ عند الكتابة (COW) تراكب الحلقة **:
6. تشغيل معيار mdadm --create (بدون --assume-clean ومطابقة حجم القطعة بالضبط، والتخطيط، وإزاحة البيانات) يبدأ على الفور في كتابة خطوط تكافؤ جديدة عبر جميع الأقراص، مما يؤدي إلى تدمير الكتلة الفائقة لنظام الملفات وأشجار B في حالة وجود معلمة واحدة (512K مقابل 64K قطعة، left-symmetric مقابل left-asymmetricأو 2048s مقابل 262144s إزاحة البيانات) خطأ حتى من قبل قطاع واحد.
7. ** قم بتسمية كل فتحة للقرص الصلب الفعلي (Bay 0 / Bay 1 / Bay 2 / Bay 3 والرقم التسلسلي) مع علامة أو شريط دائم قبل سحب محرك أقراص واحد خارج الهيكل **:
8. اكتب رقم الحاوية والرقم التسلسلي الدقيقين على الملصق العلوي لكل محرك أقراص. معرفة أمر الخليج الفعلي والتحقق منه mdadm --examine توفر البيانات الوصفية ساعات من إعادة بناء ترتيب الشريط لاحقًا.
9. ** قم باستنساخ قطاع (محركات) الأقراص الفاشلة قطاعًا تلو الآخر إلى محركات أقراص جديدة سليمة تستخدم GNU ddrescue (مع ملف خريطة) عبر منافذ SATA/HBA المباشرة باللوحة الأم قبل محاولة تجميع RAID**:
10. لا تحاول مطلقًا تجميع مصفوفة RAID أو تركيبها باستخدام محرك الأقراص المحتضر فعليًا نفسه. قم بتوصيل محرك الأقراص الفاشل بجهاز غير RAID SATA/AHCI أو LSI IT-Mode منفذ HBA على محطة عمل إنقاذ Linux، وتعطيل التثبيت التلقائي لنظام التشغيل، وتشغيل ddrescue -f -n /dev/sdX /dev/sdY rescue_driveX.map لذلك يتم إخلاء القطاعات السريعة الصحية في الممر الأول قبل ملامسة مناطق القطاعات السيئة.
11. ** قم بتجميع محركات الأقراص المستنسخة Read-Only وضع (mdadm --assemble --readonly أو باستخدام dmsetup / losetup ذاكرة الوصول العشوائي/تراكبات الملفات)**:
12. عن طريق وضع نسخة قابلة للكتابة (COW) أعلى كل قرص عضو مستنسخ، يمكنك اختبار تركيب المصفوفة وإعادة تشغيلها ext4 أو XFS مجلة، أو حتى اختبار إعادة بناء افتراضية ** مع ضمان عدم تعديل أي بايت على الإطلاق على نسخ القرص الأساسية **.

شجرة القرار: إنقاذ صفيف RAID 5 أو RAID 6 عند فشل محرك أقراص ثانٍ أثناء إعادة البناء¶

اتبع سير عمل استرداد تخزين الطب الشرعي لاستعادة المصفوفة الخاصة بك دون فقدان شريط واحد على قيد الحياة:

flowchart TD
    Start["فشل RAID 5 (محرك الأقراص الثاني) أو RAID 6 (محرك الأقراص الثالث) / انقطاع الاتصال أثناء إعادة الإنشاء"] --> StopNow["الخطوة 1: إلغاء إعادة البناء فورًا وإيقاف تشغيل المصفوفة (منع تسجيل القرص عند فشل محرك الأقراص)"]

    StopNow --> SoundCheck{"هل أصدر محرك الأقراص الفاشل نقرات عالية أو أصوات تنبيه أو أصوات طحن؟"}

    SoundCheck -->|"نعم: اصطدام/احتكاك ميكانيكي بالرأس"| CleanRoom["توقف: لا تقم بتشغيل محرك الأقراص هذا مرة أخرى. أرسل فقط محرك الأقراص الذي فشل ميكانيكيًا (بالإضافة إلى محرك أقراص صحي واحد كمرجع شريطي) إلى معمل غرف الأبحاث لتصوير نسخة منه"]

    SoundCheck -->|"لا: يدور بسلاسة، فشل بسبب القطاعات السيئة (UNC / في انتظار / المهلة)"| LabelDrives["الخطوة 2: قم بتسمية كل محرك أقراص برقم خليجه الدقيق والرقم التسلسلي -> الاتصال بمحطة عمل Linux عبر Direct SATA / IT-Mode HBA"]

    LabelDrives --> InspectMeta["قم بتشغيل 'mdadm --examine /dev/sd*' و'smartctl -a /dev/sd*' على كافة محركات الأقراص (سجل وقت التحديث، عداد الأحداث، الدور، حجم القطعة، التخطيط، إزاحة البيانات)"]

    InspectMeta --> CloneDrives["الخطوة 3: استنساخ كل محرك الأقراص المتدهور/القطاع السيئ إلى محرك احتياطي سليم باستخدام 'ddrescue -f -n' (التمرير السريع أولاً، ثم اكشط التمرير باستخدام ملف Mapfile)"]

    CloneDrives --> PickFreshest["حدد محركات الأقراص N-1 (RAID 5) أو N-2 (RAID 6) باستخدام عداد 'الأحداث' الأعلى/الأحدث (لا تخلط أبدًا بين محرك أقراص قديم تم إسقاطه ومحركات الأقراص الجديدة)"]

    PickFreshest --> CowOverlay["الخطوة 4: إنشاء تراكبات حلقة القراءة فقط / 'dmsetup' للنسخ عند الكتابة (COW) على محركات الأقراص المستنسخة بحيث لا يمكن تعديل النسخ الأصلية"]

    CowOverlay --> AssembleRO["قم بتشغيل 'mdadm --assemble --force --readonly' على أجهزة التراكب -> تركيب نظام الملفات للقراءة فقط ('mount -o ro,noload') -> نسخ جميع البيانات الهامة إلى وحدة التخزين الخارجية"]

المرحلة الأولى: فهم سبب فشل محرك الأقراص الثاني أثناء إعادة بناء RAID (XOR Parity Math & Event Counters)¶

لفهم سبب تعطل المصفوفة في منتصف عملية إعادة الإنشاء ولماذا لا تزال بياناتك قابلة للاسترداد، افحص كيفية القيام بذلك RAID 5 و RAID 6 العمل في الواقع على القرص.

1. كيف XOR أعمال إعادة بناء التكافؤ ولماذا 1 القطاع السيئ يجهض عملية إعادة البناء بأكملها¶

في محرك 4 RAID 5 مصفوفة (Drive A, Drive B, Drive C, Drive D)، يتم تقسيم البيانات إلى أجزاء ذات حجم ثابت (عادةً 64 KB أو 512 KB) مخططة عبر الأقراص، حيث تحتوي قطعة واحدة في كل صف على تكافؤ XOR (P): $\(\text{التكافؤ } P = A \oplus B \oplus C\)$ إذا Drive C فشل تمامًا وقمت بإدراج فراغ Replacement Drive C_new، يجب على وحدة تحكم RAID إعادة بناء كل شريط عليه C_new عن طريق حساب: $\(C_{\text{reconstructed}} = A \oplus B \oplus P\)$ - ** ماذا يحدث عندما Drive B يضرب واحد غير قابل للقراءة 4 KB القطاع (UNC خطأ) في 42% من إعادة البناء **: - لحساب تلك واحدة 4 KB منع على C_new، يجب أن تحتوي وحدة التحكم على قراءة صالحة من Drive A, Drive B، و Drive D. - متى Drive B إرجاع الأجهزة Read Error (Sense Key 03h / 11h Unrecovered Read Error) بعد 7 ثواني (TLER / ERC timeout)، غالبًا ما تتم برمجة وحدات تحكم RAID للمستهلكين والمؤسسات بسلوك افتراضي كارثي: بدلاً من تخطي هذا السلوك الفردي 4 KB القطاع، وتسجيل كتلة صفر، والانتهاء من الآخر 99.9999% من إعادة البناء، علامات وحدة تحكم RAID Drive B مثل FAILED / OFFLINE ويجهض عملية إعادة البناء بأكملها. - في تلك اللحظة، تحتوي الصفيف الخاص بك على محركي أقراص تم وضع علامة "فشل" عليهما (Drive C الذي كان فقط 42% أعيد بناؤها، و Drive B الذي في الواقع 99.99998% القطاعات الصحية وفقط 12 القطاعات السيئة).

2. لماذا Event Counters (Update Time) تحديد محركات الأقراص التي يجب عليك استخدامها للاسترداد¶

في كل مرة أ RAID 5 أو RAID 6 يقوم المصفوفة بكتابة البيانات أو تغيير الحالة (مثل انقطاع محرك الأقراص)، وبيانات تعريف RAID (mdadm superblock أو الأجهزة DDF البيانات الوصفية) بزيادات 64 بت Events counter على كافة محركات الأقراص النشطة حاليًا.

قارن mdadm --examine إخراج 4 محركات أقراص نموذجية RAID 5 كارثة حيث sdb فشل بالأمس ‏(Events: 10450) و sdc تسربت أثناء إعادة البناء اليوم (Events: 10892):

• القاعدة الذهبية لاسترداد RAID من الجدول أعلاه:
• لاحظ ذلك /dev/sda (10892)، /dev/sdc (10890)، و /dev/sdd (10892) جميعها متطابقة تقريبًا Events عدادات من Today 14:22.
• بمجرد استنساخنا /dev/sdc على محرك أقراص صحي باستخدام ddrescue (استعادة 99.9999% من قطاعاتها وإلغاء ملء القطاعات الثمانية غير القابلة للقراءة)، يمكننا التجميع القسري /dev/sda + Cloned /dev/sdc + /dev/sdd (تجاهل النصف المعاد بناؤه /dev/sdb تماما). يمنحنا هذا المزيج المكون من 3 محركات ** ثباتًا بنسبة 100 بالمائة، وتدهورًا يصل إلى الثانية RAID 5 مصفوفة** بدون تمزيق للخطوط.

المرحلة 2: استنساخ القطاع خطوة بخطوة لمحرك الأقراص الفاشل GNU ddrescue¶

قبل أن تلمس mdadm أو أي أداة تجميع RAID، يجب عليك استنساخ محرك (محركات) الأقراص الذي ألقى أخطاء قراءة على محركات أقراص بديلة سليمة ذات سعة بايت مساوية أو أكبر.

الخطوة 1: قم بإعداد بيئة إنقاذ Linux وتعطيل التجميع التلقائي¶

1. قم بتشغيل محطة عمل Linux (أو قم بتشغيل الخادم الخاص بك من محرك أقراص USB مباشر مثل SystemRescue system-rescue.org أو Ubuntu Live Server) مع محركات الأقراص المتصلة بـ منافذ SATA القياسية للوحة الأم أو LSI HBA في IT Mode (تمرير غير RAID).
2. منع Linux من محاولة تجميع مصفوفة RAID المعطلة أو تركيبها تلقائيًا عند التمهيد:
3. عند تشغيل SystemRescue أو Ubuntu Live، تحقق cat /proc/mdstat. إذا تم تجميع Linux تلقائيًا بشكل جزئي md الجهاز في الخلفية، قم بإيقافه على الفور في الوضع الآمن للقراءة فقط قبل التصوير:

   mdadm --stop /dev/md*
   

4. حدد كل محرك أقراص حسب الطراز الدقيق والرقم التسلسلي وحجم البايت (لا تخمن أبدًا /dev/sdX الحروف، لأن Linux يعيد تعيين أحرف محركات الأقراص عبر عمليات إعادة التشغيل):

   lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE
   

   اكتب الذي /dev/sdX يتوافق مع محرك الأقراص المصدر الفاشل (على سبيل المثال، /dev/sdcمسلسل WCC4E12345) والتي /dev/sdY هو محرك الهدف الفارغ الجديد (على سبيل المثال، /dev/sdfمسلسل ZGG9988776).

الخطوة 2: تشغيل المرحلة الثانية GNU ddrescue بروتوكول الاستنساخ (استخدم دائمًا ملف Mapfile)¶

لا تستخدم المعيار أبدًا dd (dd if=/dev/sdc of=/dev/sdf) على محرك أقراص RAID فاشل: قياسي dd إما أن يتم الإجهاض عند أول قطاع تالف أو يقوم بتغيير إزاحة الإخراج إذا sync تم تكوينه بشكل خاطئ، ولا توجد ذاكرة للقطاعات التي نجحت. GNU ddrescue (gddrescue package) يستخدم ملف خريطة حالة ذكي متعدد التمريرات:

1. الممر 1: استنساخ سريع بدون تجريف (-n العلم) لإنقاذ 99.99% من القطاعات الصحية أولاً:

   ddrescue -f -n -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
   

2. -f: يسمح بالكتابة مباشرة لحظر الجهاز /dev/sdf (** تحقق من ذلك ثلاث مرات /dev/sdc هو المصدر و /dev/sdf هو الهدف الفارغ **).
3. -n (--no-scrape): يحكي ddrescue للقفز فورًا فوق أي منطقة قطاع بطيئة أو سيئة دون الضغط على رأس القراءة، وإنقاذ كل الجيجابايت السليمة بأقصى سرعة (150 to 250 MB/s) قبل أن تتدهور صحة محرك الأقراص.
4. /root/raid_bay3_sdc.map: يحفظ التقدم الدقيق للقطاع كل 30 ثانية. حتى لو كان محرك الأقراص الفاشل مقفلاً ويتطلب دورة طاقة، قم بإعادة تشغيل نفس الأمر بالضبط باستخدام .map يستأنف الملف في القطاع المحدد حيث توقف.
5. الممر 2: كشط عكسي/تشذيب مستهدف (-d -r1) لاستعادة القطاعات التالفة الهامشية:
6. بمجرد انتهاء تمرير 1 (pct rescued: 99.99%)، قم بتخفيض مهلة أمر kernel SCSI بحيث يفشل كل قطاع تالف بسرعة (5 seconds بدلا من الانتظار 30 to 180 seconds لكل قطاع):

   echo 5 > /sys/block/sdc/device/timeout
   

7. قم بتشغيل Pass 2 مع الوصول المباشر إلى القرص (-d) ومحاولة واحدة (-r 1):

   ddrescue -f -d -r 1 -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
   

8. ** اغلاق، افصل الفشل الأصلي /dev/sdc قم بالقيادة، ثم ضعه بأمان على الرف**: من هذه النقطة فصاعدًا، ستعمل حصريًا مع نسختك الصحية (/dev/sdf) ومحركات الأعضاء الأصحاء الأخرى.

المرحلة 3: تجميع RAID آمن للقراءة فقط باستخدام النسخ عند الكتابة (COW) تراكبات و mdadm¶

الآن بعد أن أصبح لديك نسخ سليمة للقرص، **لا تقم بتشغيله أبدًا mdadm --assemble --force مباشرة على محركات الأقراص الأولية دون الحاجة إلى النسخ عند الكتابة (COW) تراكب أو --readonly العلم **. لماذا؟ لان --force يعيد كتابة كتل RAID الفائقة على محركات الأقراص، وإذا كانت مجلة نظام الملفات (ext4 / XFS) يتم إعادة تشغيله تلقائيًا عند التثبيت باستخدام مجموعة محركات الأقراص الخاطئة، فهو يغير نسخك بشكل دائم.

الخطوة 1: فحص بيانات تعريف RAID عبر جميع محركات الأقراص الأعضاء (mdadm --examine)¶

تشغيل mdadm --examine على كل محرك أقراص عضو (أو قسم، على سبيل المثال، /dev/sda1 أو /dev/sda3 على محركات أقراص Synology/QNAP NAS) واحفظ الإخراج في ملف نصي:

mdadm --examine /dev/sd[a,b,d,f]* > /root/raid_metadata_audit.txt
cat /root/raid_metadata_audit.txt

الخطوة 2: إنشاء نسخة عند الكتابة غير مدمرة (COW) تراكبات مخطط الجهاز (overlay-create)¶

لضمان السلامة بنسبة 100 بالمائة حتى لو قمت بتجميع المصفوفة بالقوة وتشغيلها mount، ** لا تتم كتابة أي بايت على الإطلاق على محركات الأقراص الثابتة الفعلية لديك **، قم بإنشاء نسخة مدعومة بحلقة dm-snapshot تراكبات النسخ عند الكتابة في /tmp (أو على محرك أقراص مؤقت خارجي):

# Create a small sparse COW file + loop device for each member partition (e.g., sda3, sdf3, sdd3)
mkdir -p /root/cow
for dev in sda3 sdf3 sdd3; do
    truncate -s 20G /root/cow/${dev}.cow
    loop_base=$(losetup --find --show --read-only /dev/${dev})
    loop_cow=$(losetup --find --show /root/cow/${dev}.cow)
    sz=$(blockdev --getsz /dev/${dev})
    echo "0 $sz snapshot $loop_base $loop_cow P 8" | dmsetup create ovl_${dev}
done

الخطوة 3: فرض تجميع المصفوفة على أجهزة التراكب وتثبيتها للقراءة فقط¶

1. ** تجميع الطازجة N - 1 تراكب الأجهزة باستخدام --assemble --force**:

   mdadm --assemble --force --verbose /dev/md99 /dev/mapper/ovl_sda3 /dev/mapper/ovl_sdf3 /dev/mapper/ovl_sdd3
   

2. لماذا نترك محرك الأقراص القديم/المعاد بناؤه نصفًا (sdb3): الإجبار mdadm للتجميع مع 3 محركات أقراص محدثة (sda3مستنسخة sdf3، و sdd3) يجلب /dev/md99 متصل بالإنترنت في الوضع النظيف المتدهور ([U_UU]) باستخدام الأحدث بالضبط Events الدولة، في حين ddrescue تم إنقاذ البيانات بالفعل من sdf3.
3. **تفعيل LVM (vgchange) إذا كان NAS أو الخادم الخاص بك يستخدم LVM أعلى RAID (Synology SHR، QNAP، Proxmox، Ubuntu) **:

   pvscan
   vgscan
   vgchange -ay
   lvs
   

   (إذا كان Synology NAS الخاص بك يستخدم Btrfs على LVM أو Synology Hybrid RAID، سوف ترى الآن /dev/vg1000/lv أو /dev/vg1/volume_1 تظهر.)
4. قم بتثبيت نظام الملفات في وضع القراءة فقط الصارم وقم بإخلاء ملفاتك الهامة على الفور:

   mkdir -p /mnt/raid_rescue
   # For ext4:
   mount -o ro,noload /dev/md99 /mnt/raid_rescue
   # (Or if noload refuses due to dirty journal, mount the COW overlay normally so the journal replays into the disposable COW file)
   mount -o ro /dev/md99 /mnt/raid_rescue
   # For Btrfs (Synology NAS):
   mount -t btrfs -o ro,usebackuproot,nologreplay /dev/vg1000/lv /mnt/raid_rescue
   

5. ** انسخ المجلدات الأكثر أهمية لديك أولاً باستخدام rsync إلى محرك أقراص احتياطية خارجي**:

   rsync -avP --ignore-errors /mnt/raid_rescue/ /mnt/external_backup_usb/
   

المرحلة 4: إنقاذ وحدات تحكم RAID للأجهزة (Dell PERC, LSI MegaRAID, HP Smart Array, Adaptec) وحمامات ZFS / Btrfs¶

ماذا لو لم تتم إدارة المصفوفة الخاصة بك بواسطة Linux mdadm، ولكن بواسطة بطاقة وحدة تحكم RAID للأجهزة (Dell PERC H730/H740/H755, Broadcom / LSI MegaRAIDأو HP Smart Array) الذي يبلغ الآن Virtual Disk Offline أو Foreign Configuration Found بعد تعطل محرك الأقراص الثاني أثناء إعادة البناء؟

1. بطاقات RAID للأجهزة (Dell PERC, LSI MegaRAID, HP Smart Array)¶

1. ** لا تنقر أبدًا "Clear Foreign Configuration" أو "Initialize Virtual Disk"**:
2. في ديل PERC / إل إس آي MegaRAID BIOS (Ctrl+R أو HII الأداة المساعدة لتكوين UEFI)، Clear يمسح بيانات تعريف RAID من محركات الأقراص، و Initialize الكتابة فوق خطوط البيانات.
3. إذا انقطع اتصال محرك الأقراص السليم لفترة وجيزة بسبب كابل لوحة الكترونية معززة مفكك أو انتهاء المهلة، Import Foreign Configuration محاولات لإعادة محرك الأقراص مرة أخرى؛ ومع ذلك، إذا سقط محرك أقراص واحد منذ أسابيع وسقط محرك آخر اليوم، فإن استيراد كليهما أو فرض محرك الأقراص القديم على الإنترنت عبر وحدة التحكم BIOS يمكن أن يؤدي إلى إتلاف المصفوفة.
4. ** الطريقة الآمنة لإعادة بناء البرامج لـ RAID للأجهزة (DDF البيانات الوصفية / dmraid / R-Studio / UFS Explorer)**:
5. يتم تخزين بطاقات RAID للأجهزة بشكل قياسي SNIA DDF (Disk Data Format) البيانات الوصفية في القطاعات النهائية في نهاية كل محرك أقراص ثابتة، وشريط البيانات عبر محركات الأقراص بدءًا من القطاع 0 (أو بعد إزاحة رأس صغيرة) باستخدام المعيار 64 KB, 128 KB, 256 KBأو 512 KB أحجام القطع (Left-Asymmetric أو Left-Symmetric).
6. بدلاً من المقامرة باستخدام BIOS المدمر لبطاقة RAID:
   1. قم بتسمية جميع محركات الأقراص حسب رقم الفتحة وقم بتوصيلها بمنفذ SATA ** قياسي / غير RAID IT-Mode HBA** على محطة عمل الاسترداد.
   2. استنساخ محرك القطاع السيئ باستخدام GNU ddrescue كما هو موضح في المرحلة الثانية.
   3. افتح محركات الأقراص المستنسخة في UFS Explorer RAID Recovery أو R-Studio Technician، أو تجميعها للقراءة فقط في Linux باستخدام dmsetup / mdadm --build: تكتشف هذه الأدوات تلقائيًا LSI / PERC / HP ترتيب الشريط، حجم القطعة (64K/512K)، والتدوير المتماثل في ذاكرة القراءة فقط بنسبة 100 بالمائة دون السماح لبطاقة RAID الخاصة بالأجهزة بكتابة بايت واحد على محركات الأقراص لديك.

2. ترو ناس / زد إف إس (RAID-Z1 / RAID-Z2) و Synology Btrfs فرك / فشل Resilver¶

إذا كان مجموعتك تستخدم OpenZFS (RAID-Z1 أو RAID-Z2) على TrueNAS أو Proxmox ويلقي محرك الأقراص الثاني CKSUM / READ الأخطاء أثناء أ zpool replace ريسيلفر: 1. لماذا يتعامل ZFS مع القطاعات السيئة أثناء عملية إعادة الإرسال بشكل أفضل من RAID للأجهزة، وعندما يظل مقفلاً: - على عكس بطاقات RAID للأجهزة الساذجة التي تسقط قرصًا كاملاً على قطاع واحد تالف، تستمر ZFS في إعادة صياغة الماضي المترجم READ الأخطاء ويسجل فقط مسارات الملفات التالفة المحددة في zpool status -v. - ومع ذلك، إذا توقف محرك الأقراص الفاشل الثاني عن ناقل SATA/SAS (I/O timeout / تحطيم الرأس) أو يسقط دون اتصال بالإنترنت تمامًا (UNAVAIL / FAULTED)، يدخل المسبح SUSPENDED الدولة (pool I/O is currently suspended). 2. ** كيفية إنقاذ أ SUSPENDED أو FAULTED ZFS RAID-Z1 / RAID-Z2 بركة : - قم بإيقاف تشغيل الطاقة بشكل نظيف، وقم باستنساخ محرك الأقراص الفاشل على قرص بديل سليم باستخدام GNU ddrescue -f -n (تتضمن تسميات قسم ZFS الملف الدقيق vdev المعرف الفريد العمومي (GUID) في بداية القرص ونهايته، لذلك يتعرف ZFS تلقائيًا على نسخة القطاع الخام باعتبارها النسخة الأصلية vdev عضو). - افصل محرك الأقراص الذي يموت فعليًا، واترك ddrescue استنساخ متصل، واستيراد تجمع ZFS في ** وضع القراءة فقط الصارم (readonly=on) دون بدء معاملة الكتابة أو استئناف إعادة الفضة:

zpool import -o readonly=on -f -R /mnt/zfs_rescue tank

الأسئلة المتداولة¶

لماذا قلت أبدا لتشغيل CHKDSK أو fsck عندما تتصاعد مجموعة RAID الخاصة بي مع وجود أخطاء في نظام الملفات بعد سقوط محرك الأقراص؟¶

على محرك أقراص ثابت واحد مستقل، قيد التشغيل CHKDSK أو fsck إصلاح التناقضات البسيطة في الدليل. على أ مجموعة RAID 5 أو RAID 6 متعددة محركات الأقراص التي عانت من سقوط محرك الأقراص المزدوج أو إعادة البناء المتقطعة، غالبًا ما تكون أخطاء نظام الملفات ناتجة عن اختلال شريط RAID أو محرك أقراص عضو قديم يتم فرضه على الإنترنت (يعني كل الثالث أو الرابع 64 كيلو بايت تتم قراءة جزء من البيانات من إنشاء محرك أقراص خاطئ). إذا سمحت CHKDSK /f أو فسك -y يعمل على مصفوفة RAID غير محاذية أو غير متزامنة، ويسيء تفسير ملايين الملفات الصالحة على أنها بيانات تعريف تالفة، ويقتطع أشجار الدليل، ويلقي أجزاء غير مسماة في فقدت + وجدت، ويكتب كتل تكافؤ جديدة عبر جميع محركات الأقراص، مما يجعل من المستحيل رياضيًا إعادة تجميع مجموعة محركات الأقراص الصحيحة بعد ذلك. قم دائمًا بالتركيب عبر للقراءة فقط النسخ عند الكتابة (بقرة) تراكبات أولا.

ماذا لو كان محرك الأقراص البديل المعاد بناؤه جزئيًا (42% كاملة) ومحرك الأقراص الثاني الذي فشل في 42% كلاهما يحتاج إلى البيانات؟ هل يمكنني الجمع بينهما؟¶

نعم. هذا هو إنقاذ RAID الكلاسيكي "Split-Horizon / Hybrid Clone". لنفترض محرك 2 توفي تماما يوم الاثنين، قمت بوضعه محرك جديد 2، وتم إعادة البناء 42% (3,500,000,000 ليرة لبنانية) من قبل محرك 3 تعرض لحادث مميت في الرأس 3,500,000,000 ليرة لبنانية. لاحظ ما لديك بالفعل: من أجل أول 42% من المصفوفة (0% ل 42%), محرك جديد 2 وقد تم بالفعل إعادة بنائها بنسبة 100 بالمائة. لذلك لأول مرة 42% من مجموعة LBA، لديك مجموعة كاملة من الخطوط التي تستخدم محرك 1 + محرك جديد 2 + محرك 4 (علاج تحطمت محرك 3 كالقرص المفقود). وإذا محرك 3 لم يكن لديه سوى التصحيح المحلي للقطاع السيئ في 42% (ويمكن قراءتها من 43% ل 100% عبر com.ddrescue)، تستخدمه محرك الأقراص 1 + محرك الأقراص المستنسخ 3 + محرك الأقراص 4 للباقي 58% من المصفوفة.

لماذا تفشل محركات الأقراص الثانية بشكل متكرر في منتصف عملية إعادة بناء RAID 5؟¶

يجتمع حقيقتان هندسيتان لتكوينهما ريد 5 عمليات إعادة البناء سيئة السمعة بسبب فشل محرك الأقراص المزدوج: (1) شيخوخة الدفعة المتطابقة: يشتري معظم المستخدمين من 4 إلى 8 محركات أقراص ثابتة متطابقة من نفس بائع التجزئة في نفس اليوم (نفس البرامج الثابتة، نفس مجموعة المصنع، نفس دفعة محرك المغزل) وتشغيلهما جنبًا إلى جنب بنفس درجة الحرارة لمدة 35000 ساعة؛ عندما يتآكل محرك الأقراص 1، يكون محرك الأقراص 2 ومحرك الأقراص 3 على بعد أيام من نفس حد التآكل الميكانيكي. (2) أخطاء القراءة الكامنة غير القابلة للتصحيح (URE): تحت التشغيل اليومي العادي، 95% من قطاعات الأرشيف الباردة على القرص الصلب لا تتم قراءتها لعدة أشهر في كل مرة، لذلك تظل القطاعات التالفة الكامنة غير مكتشفة. أ ريد 5 إعادة بناء القوات مستمرة 100% القراءة السطحية لكل قطاع عبر كل محرك أقراص باقي (من 40 إلى 100 تيرابايت من القراءة المستمرة)، ويكشف على الفور أي قطاع سيء كامن تراكم خلال العام الماضي.

كيف أعرف الملفات التي تأثرت بالقطاعات السيئة القليلة غير القابلة للقراءة والتي ddrescue كان لملء الصفر؟¶

GNU ddrescue يتضمن أداة مساعدة للطب الشرعي مضمنة تسمى com.ddrescuelog و ddru_ntfsfindbad / debugfs يقوم بتعيين النطاق الدقيق للقطاع LBA غير المسترد من ملفك .map ملف (الحالة = '-' القطاعات السيئة) من خلال الرياضيات الشريطية RAID مباشرةً إلى جدول inode لنظام الملفات. بمجرد أن تعرف أي 4 كيلو بايت كانت الكتل مملوءة بالصفر أثناء الاستنساخ، يمكنك الاستعلام debugfs (com.icheck و ncheck على تحويلة4) أو btrfs فحص الحل المنطقي الداخلي لطباعة القائمة الدقيقة المكونة من 2 أو 3 أسماء ملفات تتداخل مع تلك القطاعات التالفة، مع التأكد بنسبة 100 بالمائة من اليقين الرياضي من أن كل الملفات الأخرى الموجودة على خادم متعدد التيرابايت الخاص بك غير تالف تمامًا.

أدلة ذات صلة¶

• إسقاط محرك أقراص RAID 5 أو RAID 6 Synology أو QNAP أو TrueNAS المتعدد ولماذا يؤدي فرض إعادة البناء إلى تدمير البيانات
• وفاة بطاقة وحدة تحكم RAID، واستيراد التكوين الخارجي، ولماذا يجب عليك عدم تهيئة الأقراص مطلقًا
• تدهورت مجموعة NAS RAID، وفشل العديد من محركات الأقراص، واسترداد ZFS/Btrfs
• فشل القرص الصلب واستعادة البيانات
• النسخ الاحتياطية للكمبيوتر: استراتيجية 3-2-1 والتعافي من الكوارث
• أرقام الطوارئ حسب البلد

المصادر والتوجيهات الرسمية¶

• لينكس رايد ويكي (raid.wiki.kernel.org/index.php/Linux_Raid & Recovering_a_failed_software_RAID): *النواة الرسمية mdadm بروتوكول الاسترداد، النسخ عند الكتابة على مخطط الجهاز (dm-snapshot) تراكبات، و Events المصالحة المضادة *.
• جنو ddrescue الدليل الهندسي الرسمي (gnu.org/software/ddrescue/manual/ddrescue_manual.html): * عدم الكشط متعدد المراحل (-n) والوصول المباشر (-d) خوارزميات استرداد القطاع لفشل الوسائط المغناطيسية*.
• قاعدة المعرفة الرسمية لـ Synology (kb.synology.com/en-global/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC): * التركيب mdadm + LVM2 + Btrfs / ext4 وحدات تخزين NAS للقراءة فقط على أنظمة Ubuntu Rescue*.
• رابطة صناعة شبكات التخزين (SNIA): تنسيق بيانات قرص RAID الشائع (DDF) مواصفات إمكانية نقل البيانات التعريفية لوحدة تحكم RAID للأجهزة.