لماذا يتعذر على أنظمة Linux استرداد البيانات في بعض الأحيان؟

لماذا يمكنك استخدام جهاز كمبيوتر يستند إلى Linux أو قرص مضغوط Live Linux لاسترداد البيانات التي تعذر على Windows القيام بها?

تأتي جلسة الأسئلة والأجوبة اليوم مقدمة من SuperUser-a subdivision of Stack Exchange ، وهي مجموعة مجتمعية مدفوعة من مواقع Q & A.

السؤال

يريد قارئ SuperUser Philip Allgaier معرفة سبب تمكنه من استرداد البيانات باستخدام قرص مضغوط Live Linux الذي تم الإبلاغ عنه على أنه غير قابل للاسترداد في Windows:

خلفية: في وقت سابق من هذا العام ، واجهت مشكلة في محرك أقراص SSD يتعرف عليه Windows بعد الآن. ولكن في نهاية المطاف فعلت parted ماجيك 2012-10-10 للتمهيد. انظر هذا الموضوع محلول. تمسكني سؤال واحد من تلك اللحظة ...

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

• هل هم فقط تجاهل أي مؤشرات محتملة أن شيئا قد يكون خاطئا?

• هل هناك أي أسباب ملموسة على الإطلاق?

• كان من الحظ أن هذه البيئة بالذات كانت قادرة على الحصول على استجابة SSD فقط لفترة محدودة?

في حين أنه من المؤكد أنه كان من الممكن أن يكون الحظ ، فمن المحتمل أن يكون هناك أكثر من بضعة عوامل تلعب. دعونا التحقيق.

الاجابة

يقدم المساهم في SuperUser Eike بعض التفسيرات المحتملة ، باستثناء الحظ فقط ، لقدرته على حفظ البيانات:

عادة ما يأتي هذا إلى ما يتم الوصول إليه بالضبط ، وكيف ، بالضبط ، فشل الجهاز. على سبيل المثال ، إذا كان SSD المعني غير قادر على استرداد ، على سبيل المثال ، القطاع 5 وسيبدأ في التوقف بمجرد أن يقرأ أي شيء القطاع 5 ، قد يكون الفرق ببساطة بسبب ما يمكن للأنظمة المختلفة الوصول إليه تلقائيًا بمجرد التعرف على قرص جديد.

عندما يكتشف Windows قرصًا جديدًا ، فإنه سيقرأ جدول الأقسام ويحاول تلقائيًا فتح أي نظام ملفات يعرف كيفية قراءته. إذا كان أي من التركيبات / المكوّنات التي يتم قراءتها أثناء عملية "التركيب" هذه تؤدي إلى تشغيل SSD الخاطئ لديك ، فإن الفرق مع توزيع linux المحدد هذا هو ببساطة أنه قد لا يقوم تلقائيًا بتركيب جميع الأقسام المعنية ، أو ربما ، عند التركيب ، ما عليك سوى قراءة مجموعة فرعية مختلفة من القطاعات (يختلف تطبيق NTFS في Linux كثيرًا عن النظام الموجود في Windows - في حين أن تنسيق القرص هو نفسه ، فالأمر متروك لنظام التشغيل الذي يراه ضروريًا للقراءة. قد يقرأ Windows نسخًا ثانوية من MFT ، أو قد يبدأ بتقليل بعض البيانات وقد يكون ذلك هو الفرق .وبنك Ubuntu في قارب مماثل - لا يتم توجيهه نحو الاسترداد من الصندوق ، فإنه سيحاول تحميل أي نظام ملفات يجد على وسائل الإعلام المكتشفة حديثًا تلقائيًا ، ولهذا السبب فإن التوزيعات المتخصصة الموجهة نحو الاستعادة هي رهان أفضل ، لأنها لا تفعل سوى ما تطلبه صراحةً في مقابل القيام بالأشياء تلقائيًا.

بالطبع ، قد تكون ببساطة محظوظًا أيضًا. أنا لا أعرف ما يكفي عن وضع فشل SSD ليقول.

لينكس عموما لا يتجاهل مؤشرات أن هناك شيئا خطأ. سيتلقى نفس أخطاء SCSI من مجموعة SATA كما سيقوم Windows - إذا نظرت إلى سجل kernel ، على قرص خاطئ سترى الكثير من رسائل الخطأ. يعتمد ذلك على ما هي البرامج الوصول الفعلي إلى القرص ما سيحدث بعد ذلك. إذا كانت البرامج موجهة نحو الاسترداد ، فقد تحاول إعادة قراءة نفس القطاع لعدد محدود من المرات ، قد تتخطاها ، الخ. عادةً ما يكون أفضل رهان هو الحصول على صورة لمحرك الأقراص مع قراءة عدد كبير من القطاعات بشكل نظيف قدر الإمكان ، و ثم حاول استعادة بياناتك من تلك الصورة (إجراء أي تحليل مباشر على محرك الأقراص فكرة سيئة عادةً نظرًا لأن حالته قد تتدهور وفقط لأنك تمكنت من قراءة شيء ما مرة واحدة ، فهذا لا يعني أنك ستتمكن من قراءته مرة أخرى .)

الزميل المشارك AthonSfere ، يقدم تأديلاً آخر للأمور:

الكثير منه هو الطريقة التي تعالج بها البيئة نظام الملفات ، و ACLs أو القرص الصلب.

ستفعل Windows كل ما في وسعها لوحدها لتطيع قوائم ACL الخاصة بها ، والقطاعات التي تم وضع علامة عليها بأنها سيئة أو فارغة. لذلك سيتم التعامل مع أقسام NTFS أو Fat التي تم إنشاؤها والمحافظة عليها في Windows وكذلك Windows MBRs بواسطة Windows كما قام Windows بتعليمها.

أيضا ، إذا كان محرك الأقراص يفشل كلما زاد استخدامه ، فمن المرجح أن يواجه مشكلة كبيرة وسوف تتعطل البيئة. ثم كيف يعالج نظام التشغيل الذي يدخل حيز التشغيل ، ويندوز سوف BSOD أو إعادة التشغيل ، فإن عملية التمهيد ويندوز رمي رسائل MBR ، في عداد المفقودين رسائل الملف (NTDLR.dll مفقود أو فاسد) والتوقف ، لأن هذه الملفات السيئة مطلوبة.

عند استخدام قرص مباشر ، فأنت لا تعتمد على أي من هذا. يتم تجاوز MBR تالف بسبب قيامك بالتمهيد من القرص. ليست هناك حاجة لقطاع سيئة تالفة NTDLR.dll. كل شيء على القرص. يمكنك بعد ذلك محاولة القراءة. إذا واجهت قطاعاً "خالياً" أو بتاً سيئاً ، فإن هذه البيئة تتعامل معه على الرغم من أنه تمت برمجته للقيام بذلك. من المرجح أن يحافظ Ubuntu على سلوكيات نظام التشغيل العادية وأن يستمر في ما يحدث على الأرجح. القطاع فارغ ، افعل شيئًا آخر. هذا القطاع هو سيء ، والبقاء بعيدا ، لا تقرأ مرة أخرى لا تكتب أو أنها سوف تسبب مشاكل.

ومع ذلك ، ستحتاج منصة الاسترداد لقراءة جميع البيانات. تشير علامات الملف إلى أن الملف يجب أن يكون على 0،5 ، 13 ... إذا كان نظام الملفات 13 تقارير مفقودًا ، فتجاهل العنوان الفارغ واقرأ الملف على أي حال ، أو اقرأ القطاع التالف قدر المستطاع وحاول الاسترداد.

أيضا ، يمكن لـ Windows CAN القيام بهذا مع تطبيقات الطرف الثالث ، يمكن لـ Recuva العثور على الكثير من هذه الملفات "المفقودة" ، لأحد. لكنك لا تريد أن تكون في بيئة قد تكتب مرة أخرى إلى القرص وتتسبب في فقدان دائم حقيقي.

لقد قمت بتبسيط هذا ، وأضفت بعض التفسير ، ولكن يجب أن تملأ بعض الفراغات لما تطلبه.

هل لديك شيء تضيفه إلى الشرح؟ الصوت قبالة في التعليقات. هل ترغب في قراءة المزيد من الإجابات من مستخدمي Stack Exchange الآخرين المحترفين بالتكنولوجيا؟ تحقق من موضوع المناقشة الكامل هنا.

http://superuser.com/questions/586666/why-can-linux-systems-sometime-recover-data-windows-cant-any-concrete-reasons