فشل مصفوفة RAID، وتلف مجمع تخزين NAS، وإعادة بناء الأمان¶

عندما يبدأ جهاز تخزين متصل بالشبكة (NAS) بالمنزل أو شركة صغيرة (مثل Synology DiskStation أو QNAP Turbo NAS أو TrueNAS أو خادم Unraid) في إصدار صوت تنبيه باستخدام مؤشر LED باللون الكهرماني ويبلغ عن "Storage Pool Degraded" أو "Volume Crashed،" عادةً ما تحدد النقرة التالية للمالك ما إذا كان سيتم حفظ 20 تيرابايت من الصور العائلية وسجلات الأعمال التي لا يمكن تعويضها أو إتلافها نهائيًا. لعقود من الزمن، تم تعليم المستخدمين أنه عندما يتحول محرك الأقراص في مصفوفة RAID 5 أو RAID 1 إلى اللون الأحمر، فما عليك سوى سحب محرك الأقراص الميت للخارج، وإدخال محرك أقراص فارغ جديد تمامًا، ثم النقر فوق "إصلاح / إعادة بناء."

في مجمعات التخزين الحديثة عالية السعة التي تم إنشاؤها باستخدام محركات أقراص سعة 8 تيرابايت إلى 24 تيرابايت تم شراؤها من نفس دفعة التصنيع، **البدء الأعمى في إعادة بناء RAID في مكانه هو السبب الأول لوفاة مجموعة محركات الأقراص المتعددة غير القابلة للاسترداد **. إن إعادة بناء مجموعة مكونة من 4 محركات أقراص سعة 16 تيرابايت RAID 5 تجبر كل محرك أقراص متقادم متبقي على قراءة 100 بالمائة من قطاعاته دون توقف لمدة تتراوح بين 24 إلى 72 ساعة بأقصى حمل حراري وميكانيكي. عندما يواجه أحد محركات الأقراص الشقيقة الباقية خطأ قراءة غير قابل للتصحيح (URE) أو يعاني من تدهور الرأس في منتصف عملية إعادة البناء، تقوم وحدة تحكم RAID بطرد محرك الأقراص الثاني هذا من المجموعة وتعطل المصفوفة بأكملها. يتطلب النجاة من حالة طوارئ RAID أو ZFS أو Btrfs إيقاف جميع عمليات الكتابة مؤقتًا على الفور، ومراجعة S.M.A.R.T. القياس عن بعد عبر كافة محركات الأقراص الباقية، والنسخ الاحتياطي للمجلدات الهامة قبل لمس طوبولوجيا المصفوفة، وتصوير الأقراص الأعضاء المتدهورة باستخدام GNU ddrescue قبل محاولة إعادة بناء التكافؤ أو تجميع بيانات التعريف للقراءة فقط.

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

1. **لا تقم مطلقًا بسحب محركات أقراص متعددة "لإعادة تركيبها" أثناء تشغيل NAS أو الخادم، ولا تقم مطلقًا بتبديل محركات الأقراص دون تسمية أرقام فتحاتها الدقيقة. ** قبل لمس درج محرك أقراص واحد، استخدم أداة صنع العلامات أو العلامات وقم بوضع علامة على الجزء العلوي الفعلي لكل محرك أقراص برقم الفتحة الدقيق الخاص به (Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). على الرغم من أن نظام Linux الحديث mdadmو LVM و ZFS بتخزين كتل UUID الفائقة على كل قرص، وغالبًا ما تربط وحدات تحكم RAID للأجهزة (Dell PERC وHP Smart Array وBroadcom/LSI MegaRAID) بيانات تعريف التكوين بأرقام فتحات لوحة الكترونية معززة SAS/SATA الفعلية.
2. **لا تنقر على الفور على "إصلاح" أو "إعادة بناء" على مصفوفة RAID 5 / SHR-1 متدهورة إذا لم يكن لديك نسخة احتياطية خارجية محدثة. ** بينما تكون المصفوفة أحادية التكافؤ (RAID 5 أو Synology SHR-1 أو ZFS RAIDZ1) في الوضع المتدهور (محرك أقراص واحد ميت، ومحركات الأقراص المتبقية متصلة بالإنترنت)، لا تزال جميع ملفاتك قابلة للقراءة بنسبة 100 بالمائة في الوقت الحالي. قم بتوصيل محرك أقراص ثابت USB 3.0 خارجي مباشرةً بوحدة التخزين المتصلة بالشبكة (NAS) وانسخ مجلداتك الأكثر أهمية والتي لا يمكن استبدالها من المجموعة المتدهورة قبل إخضاع محركات الأقراص الباقية لاختبار التحمل الوحشي لمدة 48 ساعة لإعادة بناء التكافؤ.
3. ** لا تنقر أبدًا على "تهيئة القرص" أو "إنشاء تجمع جديد" أو "مسح التكوين" أو تشغيل fsck -y / btrfs check --repair على مصفوفة معطلة.** عند خروج محركي أقراص من مصفوفة RAID 5 في وقت واحد (غالبًا ما يكون ذلك نتيجة لانخفاض قصير في إمداد الطاقة أو انتهاء مهلة SATA بدلاً من الموت الفعلي الفعلي)، فإن واجهة NAS GUI ستضع علامة على مجمع التخزين على أنه "تحطم" وتعرض عليك تهيئة وحدة التخزين أو إعادة إنشائها. تؤدي التهيئة إلى كتابة كتل كبيرة وأصفار جديدة عبر خطوط التكافؤ، مما يؤدي إلى تدمير البيانات القابلة للاسترداد. وبالمثل، تشغيل btrfs check --repair على وحدة تخزين Btrfs التالفة مشهورة في مجتمع Linux kernel لتدميرها لشجرة النطاق بشكل يتعذر استرداده.
4. **أوقف جميع حاويات Docker، والأجهزة الافتراضية، وخوادم وسائط Plex، وتسجيلات كاميرات المراقبة، وعمليات RAID Scrubs المجدولة على الفور. ** كل عملية كتابة إلى مصفوفة متدهورة تزيد من خطر حدوث فجوة كتابة متماثلة أو دفع محرك أقراص ثانوي هامشي فوق الحافة. قم بتسجيل الدخول إلى واجهة الويب NAS أو محطة SSH وأوقف جميع خدمات الخلفية ومهام الإدخال/الإخراج العالية.
5. إذا كان أي محرك أقراص في NAS يصدر أصوات نقر إيقاعية أو طرق أو طحن أو صرير، فقم بإيقاف تشغيل NAS بشكل نظيف الآن. تعرض محرك النقر أو الطحن لعطل فعلي في رأس القراءة/الكتابة (راجع فشل القرص الصلب واستعادة البيانات). سيؤدي تركها تدور داخل حاوية NAS إلى تحويل الأطباق المغناطيسية إلى غبار في غضون دقائق.
6. **تحقق مما إذا كان "فشل NAS" هو في الواقع مجرد لوحة أم NAS ميتة أو وحدة طاقة خارجية. ** إذا لم يتم تشغيل Synology أو QNAP أو Asustor NAS فجأة على الإطلاق، أو يومض مؤشر الطاقة الأزرق الخاص به إلى ما لا نهاية (مثل خطأ إشارة الساعة Intel Atom C2000 الشهير)، ** من المؤكد تقريبًا أن محركات الأقراص الثابتة والبيانات الخاصة بك جيدة بنسبة 100 بالمائة **. يمكنك ترحيل محركات الأقراص هذه إلى NAS بديل أو تركيبها للقراءة فقط على أي كمبيوتر سطح مكتب Ubuntu Linux باستخدام منافذ SATA القياسية.

flowchart TD
    A["تنبيه NAS / تقارير صفيف RAID بحالة متدهورة أو معطلة"] --> B{"هل تصدر أي محركات أقراص أصوات نقر ميكانيكي أو طحن أو كشط؟"}
    B -->|"نعم: تحطم الرأس الجسدي"| C["قم بإيقاف تشغيل NAS على الفور، وقم بتسمية كل محرك أقراص برقم الخليج الخاص به، ثم قم بإزالة محرك النقر"]
    B -->|"لا: عملية صامتة"| D{"ما هي حالة تجمع التخزين؟"}
    D -->|"متدهور (فشل محرك أقراص واحد، ولا يزال المجلد قابلاً للقراءة)"| E["أوقف جميع عمليات الكتابة في Docker/VM/Surveillance ولا تنقر فوق 'إعادة الإنشاء' بعد"]
    E --> F["تحقق من S.M.A.R.T. السمات (المعرف 5، 187، 197، 198) على كافة محركات الأقراص الباقية"]
    F --> G["قم بتوصيل محرك أقراص USB خارجي وانسخ الملفات المهمة من المجموعة المتدهورة أولاً"]
    G --> H{"هل تُظهر أي محركات أقراص باقية قطاعات سيئة (المعرف 5 / 197 > 0)؟"}
    H -->|"نعم: فشل محرك الأقراص الثاني"| I["قم بإيقاف تشغيل كل محرك أقراص واستنساخه باستخدام GNU ddrescue قبل محاولة إعادة البناء"]
    H -->|"لا: البقاء على قيد الحياة يؤدي إلى صحة 100%"| J["أدخل محرك CMR البديل (لا SMR أبدًا) وقم بتشغيل إعادة بناء التكافؤ"]
    D -->|"تعطلت / غير متصل (انقطعت محركات أقراص متعددة)"| K["لا تقم بتهيئة أو تشغيل fsck/btrfs --repair; قم بإيقاف تشغيل الطاقة وقم بتسمية كافة فتحات محرك الأقراص"]
    C --> L["استنساخ جميع محركات الأقراص الأعضاء المتدهورة إلى محركات أقراص صحية باستخدام ملفات GNU ddrescue + Mapfiles"]
    K --> L
    L --> M["أعد تجميع محركات الأقراص المستنسخة في وضع القراءة فقط عبر Linux mdadm/LVM أو zpool import -o readonly=on أو UFS Explorer RAID"]

فهم سبب فشل عمليات إعادة بناء RAID: اعتراضات "Sibling Drive Batch" و"SMR Drive".¶

لاتخاذ قرارات آمنة أثناء حالة طوارئ NAS، يجب عليك فهم المصيدتين الماديتين اللتين تقتلان مصفوفات RAID أثناء الاسترداد:

الفخ 1: فشل الدفعة المرتبطة وأخطاء القراءة غير القابلة للتصحيح (URE)¶

يشتري معظم مالكي NAS جميع محركات الأقراص الثابتة الأربعة أو الستة في نفس اليوم من نفس بائع التجزئة. تأتي محركات الأقراص هذه من نفس خط تجميع المصنع، وتشترك في مراجعات البرامج الثابتة المتطابقة، وتدور في نفس بيئة اهتزاز الهيكل، وتتراكم نفس عدد ساعات التشغيل بالضبط. * عندما يموت محرك 1 بعد 38000 ساعة من التشغيل، يتم تشغيل محركات الأقراص 2 و3 و4 أيضًا لمدة 38000 ساعة من التآكل. * إذا قمت بإدخال محرك أقراص بديل جديد في Bay 1 ثم قمت بالنقر فوق Rebuild في مصفوفة RAID 5، فيجب على وحدة التحكم NAS قراءة كل قطاع على حدة عبر محركات الأقراص 2 و3 و4 لإجراء XOR-حساب كتل التكافؤ المفقودة للخليج 1. * إذا كان Drive 3 يؤوي بهدوء 14 قطاعًا تالفًا غير قابل للقراءة (القطاعات المعلقة الحالية، معرف S.M.A.R.T. 197) في مجلد قديم لم تفتحه منذ عامين، فإن عملية إعادة البناء ستصطدم أولاً بهذه القطاعات التالفة في الساعة 19. في العديد من بطاقات RAID للأجهزة ونواة NAS الأقدم بدون التحكم في استرداد الأخطاء SCT (TLER)، يؤدي توقف القراءة لعدة ثوانٍ إلى قيام وحدة التحكم بوضع علامة ** على Drive 3 كـ "فشل/خطأ،"** إسقاط محرك أقراص ثانٍ من مصفوفة RAID 5 أحادية التكافؤ وتعطل وحدة التخزين بأكملها.

الفخ 2: لا تقم مطلقًا بإدخال محرك أقراص SMR (التسجيل المغناطيسي المغطى) في صفيف RAID أو ZFS¶

عند شراء محرك أقراص ثابتة بديل في حالات الطوارئ من متجر إلكترونيات محلي لإعادة بناء NAS، تحقق من أن محرك الأقراص البديل يستخدم CMR (التسجيل المغناطيسي التقليدي)، ولا يستخدم أبدًا SMR (التسجيل المغناطيسي المغطى). * محركات الأقراص الثابتة لسطح المكتب ذات الميزانية المحدودة (مثل Western Digital Red non-Plus القياسي) EFAX تستخدم الطرازات التي تتراوح سعتها من 2 تيرابايت إلى 6 تيرابايت، ومحركات الأقراص المكتبية Seagate Barracuda Compute، والعديد من محركات أقراص USB الخارجية الرخيصة التي يقوم المستخدمون "بإخراجها" من العلب البلاستيكية) SMR مُدار بواسطة محرك الأقراص، حيث تتداخل المسارات المغناطيسية مثل ألواح السقف. * أثناء الكتابة المتواصلة على RAID أو ZFS بسعة متعددة تيرابايت، تمتلئ ذاكرة التخزين المؤقت للوسائط الداخلية لمحرك SMR بالكامل خلال 30 دقيقة. بمجرد امتلاء ذاكرة التخزين المؤقت، يتوقف محرك SMR لمدة 10 إلى أكثر من 30 ثانية أثناء قراءة النطاقات الخشبية بالكامل وإعادة كتابتها داخليًا، أو إرجاع ATA IDNF (Sector ID Not Found) مهلة. * لينكس mdadm، Synology DSM، وخاصة ** ZFS (zed)** قم بتفسير أكشاك SMR التي تبلغ مدتها 20 ثانية على أنها محرك أقراص ثابت ميت، ** يتم طرد محرك الأقراص البديل الجديد تمامًا خارج المصفوفة ** في منتصف عملية إعادة البناء. قم دائمًا بشراء محركات الأقراص CMR NAS/Enterprise (مثل WD Red Plus / WD Red Pro أو Seagate IronWolf / IronWolf Pro / Exos أو Toshiba N300 / MG Enterprise).

مصفوفة التشخيص: مستويات RAID، والتسامح مع الخطأ، وقواعد البقاء¶

فرز خطوة بخطوة لمجموعة NAS "المتدهورة" (فشل محرك أقراص واحد، ولا يزال الوصول إلى البيانات متاحًا)¶

إذا كان NAS الخاص بك يصدر صوت تنبيه بسبب فشل 1 محرك الأقراص في RAID 1 أو RAID 5 أو SHR-1 أو RAID 6 أو RAIDZ، فاتبع هذا التسلسل الدقيق قبل استبدال القرص:

الخطوة 1: تدقيق S.M.A.R.T. السمات الموجودة على جميع محركات الأقراص SURVIVING أولاً¶

افتح ** مدير التخزين -> HDD/SSD -> المعلومات الصحية -> S.M.A.R.T. السمة ** (في Synology/QNAP) أو تشغيل smartctl -a /dev/sdX عبر SSH على كل محرك صحي/متصل لا يزال متبقيًا في المجمع. أنظر إلى RAW_VALUE عمود لهذه السمات الأربع الحاسمة: * المعرف 5 (Reallocated_Sector_Ct): يجب أن يكون مثاليا 0. إذا كان محرك الأقراص الباقي يحتوي على عشرات أو مئات من القطاعات المعاد تخصيصها، فإن سطح طبقه أو رؤوسه تتدهور بشكل كبير. * المعرف 187 (Reported_Uncorrect): يجب أن يكون 0. * المعرف 197 (Current_Pending_Sector): حرجة. أي رقم أكبر من 0 يعني أن محرك الأقراص الباقي يحتوي حاليًا على قطاعات غير قابلة للقراءة تنتظر التسبب في حدوث عطل في اللحظة التي تحاول فيها إعادة بناء RAID قراءتها. * المعرف 198 (Offline_Uncorrectable): يجب أن يكون 0.

قاعدة القرار: * إذا ظهرت جميع محركات الأقراص الباقية 0 في المعرفات 5 و187 و197 و198، يمكنك إجراء نسخ احتياطي آمن لمجلداتك الهامة على محرك أقراص USB خارجي ثم المتابعة باستخدام واجهة المستخدم الرسومية NAS العادية الإصلاح / إعادة البناء باستخدام محرك أقراص بديل CMR سليم. * في حالة ظهور أي محرك أقراص باقي في مجموعة RAID 5 / SHR-1 / RAIDZ1 أحادية التكافؤ Current_Pending_Sector > 0 أو تصعيد Reallocated_Sector_Ct، ** لا تقم بإجراء عملية إعادة البناء **. انسخ جميع البيانات الموجودة على NAS المتدهورة إلى محركات أقراص USB خارجية فورًا بينما لا تزال وحدة التخزين مثبتة؛ إذا كانت وحدة التخزين تعاني من مشكلة بالفعل، فقم بإيقاف تشغيل NAS واستنساخ محركات الأقراص الأعضاء الفاشلة على جهاز كمبيوتر Linux باستخدام GNU ddrescue أولا.

الإنقاذ خطوة بخطوة عند "تعطل" وحدة تخزين RAID / NAS (انقطاع محركات أقراص متعددة)¶

ماذا لو استيقظت ووجدت وحدة التخزين RAID 5 NAS المكونة من 4 فتحات تقول "Storage Pool 1: Crashed" لأن Drive 2 فشل ليلة الثلاثاء وDrive 4 انسحب صباح الأربعاء؟

لماذا يمكن بالفعل استرداد معظم "حالات فشل محركي الأقراص": ما لم يتعرض منزلك لضربة صاعقة أو تم إسقاط NAS على مجموعة من السلالم، فإن محركي الأقراص الصلبة الميكانيكيين لا يتعرضان أبدًا لاصطدامات رأسية كارثية في نفس الثانية بالضبط. بدلاً من ذلك، ما حدث بالفعل هو تسلسلي: 1. محرك الأقراص 2 طور بعض القطاعات السيئة وتم طرده من المصفوفة قبل أيام أو ساعات (تارك المصفوفة تعمل في الوضع المتدهور على محركات الأقراص 1 و3 و4). 2. لاحقًا، واجه Drive 4 قطاعًا واحدًا غير قابل للقراءة* (أو مهلة قصيرة لـ SATA) أثناء قيام NAS بتشغيل عملية تنظيف الخلفية. نظرًا لأن المصفوفة لم تعد تحتوي على تكرار لإصلاح هذا القطاع التالف على Drive 4، فقد قام برنامج تشغيل RAID بطرد Drive 4 أيضًا ووضع علامة على المجموعة بأكملها Crashed.

في هذا السيناريو، يحتوي Drive 4 على أحدث وأحدث عداد لأحداث الغارة (Events العد) وهو سليم بنسبة 99.9999%، في حين أن Drive 2 قديم قليلاً ("قديم").

كيفية استرداد Synology أو QNAP أو Linux المعطل mdadm صفيف بأمان على جهاز كمبيوتر يعمل بنظام التشغيل Linux¶

الخطوة 1: قم بإيقاف تشغيل NAS، وقم بتسمية كل حاوية محرك أقراص، وقم بتوصيل محركات الأقراص بجهاز كمبيوتر مكتبي يعمل بنظام Ubuntu Linux Live USB¶

1. اغلاق NAS. قم بتسمية كل محرك أقراص (Bay 1, Bay 2, Bay 3, Bay 4).
2. قم بتوصيل محركات الأقراص بمنافذ SATA باللوحة الأم (أو بطاقة HBA مثل LSI 9211-8i/9300-8i في وضع تكنولوجيا المعلومات؛ وتجنب محاور USB الرخيصة التي يتم قطع اتصالها تحت الحمل) على كمبيوتر مكتبي تم تشغيله في Ubuntu Linux Live USB.
3. افتح محطة وتفقد تخطيط القسم و mdadm الكتل الفائقة ** بشكل صارم في وضع التشخيص للقراءة فقط **:

# List all connected drives and partitions without mounting anything
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE

# Inspect the Linux Software RAID (mdadm) superblock metadata on the data partitions
# Note: On Synology DSM, Partition 1 is Root OS, Partition 2 is Swap, and Partition 3 (or 5) is your User Data array (e.g., /dev/sda3, /dev/sdb3, /dev/sdc3, /dev/sdd3)
sudo mdadm --examine /dev/sd[a-d]3

الخطوة 2: اقرأ Events عداد و Array State الإخراج من mdadm --examine¶

ننظر عن كثب في إخراج sudo mdadm --examine /dev/sd[a-d]3 لكل محرك: * ستظهر لك خطوط مثل: * /dev/sda3: Events : 48210, Array State : A.AA (A = نشط، . = مفقود) * /dev/sdb3 (المحرك 2، خرج أولاً): Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (محرك 4، خرج أخيرًا): Events : 48209, Array State : A.AA * لاحظ ما Events يخبرك العداد: ** محركات الأقراص 1 و 3 و 4 (sda3, sdc3, sdd3) تقع ضمن حدث واحد عن بعضها البعض (48210 مقابل 48209)**، أثناء القيادة 2 (sdb3) سقط في وقت سابق بكثير في الحدث 47950. * قاعدة هامة: في مصفوفة RAID 5 ذات 4 محركات أقراص، تحتاج فقط إلى 3 محركات أقراص لإعادة بناء 100 بالمائة من البيانات. يجب عليك تجميع المصفوفة باستخدام 3 أحدث محركات الأقراص (sda3, sdc3، و sdd3) و اترك محرك الأقراص القديم (sdb3). إذا قمت عن طريق الخطأ بفرض التجميع باستخدام محرك الأقراص القديم (sdb3)، فإن البيانات التعريفية لنظام الملفات منذ يومين لن تتطابق مع خطوط البيانات الحالية الموجودة على محركات الأقراص الأخرى وستؤدي إلى إتلاف المجلدات الخاصة بك.

الخطوة 3: استنساخ أي محرك أقراص به قطاعات تالفة باستخدام GNU ddrescue أولا¶

قبل التجميع، قم باستنساخ محرك الأقراص الذي تم إسقاطه مؤخرًا (/dev/sdd) (ومن الناحية المثالية جميع محركات الأقراص الأعضاء) إلى محرك أقراص بديل سليم باستخدام ddrescue (انظر فشل القرص الصلب واستعادة البيانات للكامل ddrescue بناء الجملة):

# Clone the dropped drive (/dev/sdd) to a healthy new spare drive (/dev/sde) with a mapfile
sudo ddrescue -f -n /dev/sdd /dev/sde /root/drive4_clone.map
sudo ddrescue -d -f -r3 /dev/sdd /dev/sde /root/drive4_clone.map

الآن افصل الفشل الأصلي /dev/sdd ووضعه بأمان على الرف حتى تتمكن من العمل مع النسخة الصحية (/dev/sde).

الخطوة 4: إعادة تجميع مصفوفة RAID ومجموعة وحدات تخزين LVM ونظام الملفات في وضع القراءة فقط الصارم¶

في أنظمة Synology (SHR / RAID) وQNAP، تحتوي حزمة التخزين على ما يصل إلى ثلاث طبقات: mdadm (غارة) -> LVM2 (إدارة الحجم المنطقي) -> ext4 أو Btrfs (نظام الملفات). فيما يلي تسلسل الأوامر الدقيق لتثبيتها بأمان في وضع القراءة فقط على Ubuntu:

# Install mdadm, lvm2, and btrfs-progs inside the Ubuntu Live environment
sudo apt update && sudo apt install -y mdadm lvm2 btrfs-progs

# Stop any partial auto-assembled md arrays first
sudo mdadm --stop --scan

# Assemble the 3 freshest RAID 5 partitions in READ-ONLY mode (using --force ONLY if the 3rd drive's event count is off by 1-2 events, on the cloned drive)
sudo mdadm --assemble --readonly --run /dev/md127 /dev/sda3 /dev/sdc3 /dev/sde3

# Check that /dev/md127 is now active (even in degraded [UU_U] read-only state)
cat /proc/mdstat

# Activate the LVM Volume Group in read-only mode
sudo vgchange -ay --readonly

# List the discovered Logical Volumes (look for /dev/vg1000/lv or /dev/vg1/volume_1)
sudo lvs

# Create a mount point and mount the Logical Volume strictly READ-ONLY (-o ro,noload for ext4 or -o ro,norecovery for Btrfs)
sudo mkdir -p /mnt/nas_rescue

# For ext4 volumes:
sudo mount -o ro,noload /dev/vg1000/lv /mnt/nas_rescue

# OR for Btrfs volumes (such as Synology Btrfs pools):
sudo mount -o ro,norecovery /dev/vg1000/lv /mnt/nas_rescue

مرة واحدة /mnt/nas_rescue يتصاعد، كافة المجلدات المشتركة NAS الخاصة بك (photo, homes, video, documents) سوف تظهر في الداخل /mnt/nas_rescue/ حتى تتمكن من نسخها مباشرة على محرك أقراص USB احتياطي خارجي.

• **ماذا لو كان Synology NAS الخاص بك يحتوي على "Synology Hybrid RAID (SHR)" بأحجام محرك أقراص مختلطة؟ ** يقوم Synology SHR ببساطة بتقسيم محركات الأقراص الأكبر حجمًا إلى أقسام متعددة (sda5, sda6) وينشئ منفصلة mdadm مصفوفة عبر كل طبقة قسم، ثم تنضم إليها md المصفوفات معًا داخل مجموعة LVM Volume Group واحدة (vg1000). الجري sudo mdadm --assemble --scan --readonly و sudo vgchange -ay يقوم تلقائيًا بدمج وحدات تخزين SHR متعددة الطبقات معًا مرة أخرى على Ubuntu.
• بديل واجهة المستخدم الرسومية التجارية (Windows/macOS/Linux): إذا كنت غير مرتاح لأوامر Linux الطرفية أو لديك مجموعة LVM معقدة وموفرة بشكل رفيع من QNAP، UFS Explorer RAID Recovery أو ReclaiMe Free RAID Recovery يمكنها فحص جميع محركات أقراص NAS المتصلة على جهاز كمبيوتر يعمل بنظام Windows أو Linux في وضع برنامج للقراءة فقط بنسبة 100%، والكشف تلقائيًا عن حجم الشريط، وتدوير التكافؤ، وإزاحات LVM، ونسخ مجلداتك دون الحاجة إلى ذلك. تعديل قطاع واحد على محركات أقراص NAS.

زفس (zpool) وأوامر الإنقاذ في حالات الطوارئ Btrfs¶

تستخدم منصات NAS الحديثة (وحدات تخزين TrueNAS SCALE/CORE وProxmox وUbuntu Server وUnraid وSynology Btrfs) بشكل متزايد أنظمة ملفات النسخ عند الكتابة (CoW) بدلاً من الأنظمة القديمة ext4. إذا كان ** ZFS zpool** أو تجمع Btrfs يرفض التثبيت أو يتسبب في ذعر kernel عند التمهيد بعد انقطاع التيار الكهربائي أو فشل محرك الأقراص، سوف يفشل التثبيت العادي لأن نظام التشغيل يحاول إعادة تشغيل معاملات الكتابة التالفة. يجب عليك استخدام معلمات التراجع عن المعاملات للقراءة فقط.

1. زفس (zpool) الاسترداد في حالات الطوارئ (TrueNAS / Proxmox / Linux ZFS)¶

إذا ينص تجمع ZFS FAULTED, UNAVAILأو يتعطل الخادم (ذعر kernel) في اللحظة التي تحاول فيها استيراده بعد فقدان الطاقة بشكل غير نظيف:

# 1. Inspect all visible ZFS pools on the connected disks without importing them
sudo zpool import

# 2. ALWAYS attempt a Read-Only Import first (prevents ZFS from writing to disks or replaying the ZIL/SLOG)
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 3. What if a normal import causes a kernel panic or says 'damaged pool metadata'?
# Use -F (Rollback/Recovery Mode) with -n (Dry Run ONLY) to see if ZFS can rewind the last few seconds of corrupted Transaction Groups (TXGs):
sudo zpool import -F -n <pool_name>

# 4. Combine Read-Only + Safe Transaction Group Rewind (-F -o readonly=on) so no disk sectors are altered while you copy your data off:
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 5. For heavily damaged pools where Space Map allocation tables are corrupt, disable space map loading prior to read-only import:
echo 1 | sudo tee /sys/module/zfs/parameters/zfs_recover
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

بمجرد تركيبه تحت /mnt/zfs_rescue، انسخ مجموعات البيانات الخاصة بك باستخدام rsync أو zfs send قبل محاولة استيراد التجمع للقراءة والكتابة.

2. استرداد الطوارئ لـ Btrfs (Synology Btrfs / Unraid Cache Pool / Linux Btrfs)¶

بدلاً من ذلك، حاول تركيب أو استخراج حجم Btrfs بترتيب تقدمي صارم، من الفحص الأقل تدخلاً إلى الفحص الأعمق:

# Stage 1: Mount Read-Only without replaying the corrupted Journal Log Tree (fixes 80% of power-loss Btrfs mount failures)
sudo mount -t btrfs -o ro,norecovery /dev/sdX1 /mnt/btrfs_rescue
# (Note: on newer Linux kernels 5.11+, use: -o ro,rescue=nologreplay)

# Stage 2: Mount Read-Only using the backup Root Tree + ignoring bad checksums (for multi-drive or bit-rot corruption)
sudo mount -t btrfs -o ro,rescue=all /dev/sdX1 /mnt/btrfs_rescue
# (On older kernels: sudo mount -t btrfs -o ro,usebackuproot,nologreplay,degraded /dev/sdX1 /mnt/btrfs_rescue)

# Stage 3: If the volume still refuses to mount in the kernel, extract files directly in userspace without mounting using 'btrfs restore'
# First, list available backup tree roots:
sudo btrfs-find-root /dev/sdX1

# Then run 'btrfs restore' (strictly read-only userspace extractor) to dump all files to an external healthy drive:
sudo btrfs restore -v -i -m -S /dev/sdX1 /mnt/external_usb_backup/

حالات الطوارئ الخاصة بوحدة تحكم RAID للأجهزة: "التكوين الخارجي" وبطاقات RAID الميتة¶

تستخدم خوادم المؤسسات (Dell PowerEdge مع بطاقات PERC، أو HPE ProLiant مع Smart Array، أو Lenovo Think System، أو محطات العمل المزودة بوحدات تحكم Broadcom/LSI MegaRAID) بطاقات RAID للأجهزة المزودة بذاكرة NVRAM المدمجة وذاكرة التخزين المؤقت للبطارية/المكثف الفائق (BBU / CacheVault).

1. استيراد التكوين الخارجي مقابل التكوين الواضح (الحرج)¶

عند قطع اتصال محرك الأقراص للحظات أو قيامك بنقل محركات الأقراص إلى هيكل خادم بديل، ستتوقف شاشة التمهيد Dell PERC أو LSI MegaRAID BIOS مؤقتًا وتعلن: "تم العثور على التكوين (التكوينات) الخارجية على المحول." * ** اختر دائمًا Import Foreign Configuration (أو Preview Foreign Configuration -> Import).** تعني العلامة "الخارجية" ببساطة أن وحدة التحكم RAID ترى بيانات تعريف RAID صالحة ومكتوبة على محركات الأقراص الثابتة نفسها (قطاعات تكوين تنسيق بيانات القرص / DDF أو LSI في نهاية محركات الأقراص) والتي تختلف عن حالة NVRAM الحالية للبطاقة. يؤدي الاستيراد إلى قراءة تخطيط المصفوفة مباشرة من محركات الأقراص وإعادة القرص الافتراضي الخاص بك إلى الإنترنت دون فقدان بايت واحد. * ** لا تختار أبدًا Clear Foreign Configuration أو Initialize Virtual Disk.** يؤدي المسح أو التهيئة إلى مسح بيانات تعريف المصفوفة أو تصفير محركات الأقراص. * تحذير الاستثناء: إذا انقطع محرك أقراص واحد منذ ثلاثة أسابيع، فقد واصلت كتابة بيانات جديدة إلى المصفوفة المتدهورة لمدة ثلاثة أسابيع، ثم قمت بتوصيل محرك الأقراص الفردي القديم الذي مضى عليه 3 أسابيع مرة أخرى، لا تقم باستيراد التكوين الأجنبي من محرك الأقراص الفردي القديم هذا فوق محركات الأقراص النشطة السليمة؛ بدلاً من ذلك، استبدل محرك الأقراص القديم أو استنسخه.

2. ماذا لو ماتت بطاقة RAID للأجهزة نفسها؟¶

إذا كانت اللوحة الأم للخادم أو بطاقة وحدة تحكم RAID الخاصة بجهاز PCIe تعاني من عطل إلكتروني ولن يتم تشغيلها: * لست بحاجة إلى شراء نفس المراجعة للوحة الأم، وستظل بياناتك سليمة على محركات الأقراص. * قم بشراء وحدة تحكم RAID بديلة من مجموعة شرائح وحدة التحكم نفسها (على سبيل المثال، يمكن لأي بطاقة LSI/Broadcom MegaRAID SAS 2108/2208/3108 أو Dell PERC H710/H730/H740 قراءة بيانات تعريف DDF من بطاقة PERC قديمة). * قم بتثبيت بطاقة RAID البديلة في جهاز كمبيوتر يعمل، وقم بتوصيل محركات الأقراص ذات العلامات بترتيبها الأصلي، ثم قم بالتمهيد في BIOS الخاص بوحدة التحكم (Ctrl+R أو Ctrl+H أو قائمة UEFI HII)، وحدد استيراد التكوين الخارجي. ستقوم وحدة التحكم بقراءة تخطيط RAID من محركات الأقراص وتثبيت وحدة التخزين الخاصة بك على الفور.

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

أدلة ذات صلة¶

• فشل القرص الصلب واستعادة البيانات
• حذف الملفات عن طريق الخطأ، ومحرك الأقراص المهيأ، واستعادة الصور
• النسخ الاحتياطية للكمبيوتر: استراتيجية 3-2-1 والتعافي من الكوارث
• فشل تمهيد نظام Linux وإصلاح GRUB
• الاستجابة الطارئة لبرامج الفدية والبرامج الضارة
• أرقام الطوارئ العالمية

تم التأكد من المصادر¶

• منظمة Linux Kernel (الدولية): Linux RAID (mdadm) ويكي (raid.wiki.kernel.org)، استرداد برنامج RAID الفاشل، ووثائق Btrfs Kernel (btrfs.readthedocs.io على btrfs rescue و btrfs restore).
• مشروع توثيق OpenZFS (الدولي): zpool import التراجع عن القراءة فقط ومجموعة المعاملات (-F -o readonly=on) مرجع الإدارة.
• شركة Synology Inc. (تايوان/الدولية): مقالة قاعدة معارف Synology الرسمية KB-1079 (كيف يمكنني استخدام جهاز كمبيوتر لاستعادة البيانات عند تعطل Synology NAS الخاص بي باستخدام Ubuntu mdadm و lvm2).
• مشروع جنو / مؤسسة البرمجيات الحرة (الدولية): جنو ddrescue دليل التصوير غير المدمر على مستوى الكتلة لمحركات أقراص أعضاء RAID المتدهورة.
• المعهد الوطني للمعايير والتكنولوجيا (NIST) (الولايات المتحدة): منشور خاص رقم 800-86 وإرشادات موثوقية التخزين حول نوافذ التعرض لإعادة بناء RAID واحتمالات أخطاء القراءة غير القابلة للتصحيح (URE).