نقوم باستعادة الأجهزة الظاهرية من مخزن بيانات تمت تهيئته بشكل خاطئ. قصة هراء واحد مع نهاية سعيدة

تنويه: المذكرة هي مسلية. الكثافة المحددة للمعلومات المفيدة فيها صغيرة. لقد كتب "لنفسك".

مقدمة غنائية

يتم تفريغ ملف في مؤسستنا على جهاز VMware ESXi 6 الظاهري تحت Windows Server 2016. وهذا ليس مجرد تفريغ. هذا هو خادم لتبادل الملفات بين الأقسام الهيكلية: هناك تعاون ، ووثائق المشروع ، ومجلدات من ماسحات الشبكة. بشكل عام ، هذه هي حياة الإنتاج بأكملها.

وهذه الحاوية من كل حياة الإنتاج بدأت تتدلى. علاوة على ذلك ، يمكن للضيف تعليق نفسه بهدوء ، دون التأثير على الباقي. يمكن أن يتعطل بعد المضيف بأكمله ، وبالتالي ، جميع آلات الضيف الأخرى. يمكنني تعليق نفسي وتعليق خدمات عميل vSphere: أي أن عمليات الضيوف الآخرين على قيد الحياة ، والأجهزة تعمل بشكل صحيح وتستجيب ، ولكن لا يوجد تلف في الملف ولا يتشبث عميل vSphere بالمضيف. بشكل عام ، لا يمكن تحديد أي نظام. يمكن أن يحدث تعليق خلال اليوم أثناء تحميل ضعيف. يمكن في الليل خلال حمولة الصفر. يمكن في الليل أثناء النسخ الاحتياطي التفاضلي والحمل المتوسط. يمكن في عطلة نهاية الأسبوع خلال نسخة احتياطية كاملة والحمل عالية. وكان هناك تدهور واضح في الوضع. في البداية كانت مرة واحدة في السنة ، ثم مرة واحدة كل ستة أشهر. في نهاية صبري ، مرتين في الأسبوع.

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

لقد دهشت وقررت الذهاب في إجازة. بينما كنت في إجازة - لم يكن لتفريغ النفايات تعليق واحد. وعندما ذهب يوم الاثنين إلى العمل - علقت سلة المهملات. احتفظ بنسخة احتياطية كاملة ، وفي النهاية علقها. دفعني هذا الاجتماع الدافئ من العطلة إلى اتخاذ قرار بالسحب الفعلي لمحرك الضيف إلى مضيف آخر.

وعلى الرغم من أنه من المعروف منذ فترة طويلة أنه في اليوم الأول بعد العطلة ، لا يمكن فعل أي شيء خطير ، على الرغم من أنني مهيأة للعمل طوال الطريق إلى العمل ، إلا أن سخطي بالتجميد التالي أدى إلى تفكيري ومزاجي ، ووعدت ...

تم إعادة ترتيب الأقراص المادية إلى مضيف آخر. اتصال ساخن. تظهر الأقراص في إعدادات التخزين في علامة التبويب محركات الأقراص . في علامة التبويب Datastores ، التخزين على محركات الأقراص هذه ليس كذلك. تحديث - لا تظهر. حسنا ، بالطبع ، الدافع الأول هو إضافة التخزين . يخبرك معالج الإضافة بما يدعمه. بالطبع يدعم أيضا VMFS. لم يكن لدي شك. نظرة سريعة على رسائل المعالج في كل خطوة: التالي ، التالي ، التالي ، إنهاء. لم تقترب نظرته حتى من التقاط دائرة صفراء صغيرة عليها علامة تعجب أسفل نافذة إحدى خطوات السيد.

في نهاية المعالج ، ظهر Datastore جديد في القائمة ... ومعه Datastores من الأقراص المادية الأخرى.

أنتقل إلى التنقل في Datastore المضافة حديثًا ، وهو ... فارغ. بالطبع ، لقد دهشت مرة أخرى. 8 صباحًا على مدار الساعة ، أول 15 دقيقة في العمل بعد العطلة ، حتى السكر في القهوة لم يتم تحريكه بعد. وهنا هو عليه. كانت فكرتي الأولى أنني سحبت محرك الأقراص الخاطئ من المضيف "الأصلي". نظرت لمعرفة ما إذا كان مخزن البيانات المطلوب موجودًا في المضيف "الأصلي": لا ، غير موجود. الفكر الثاني كان: "القرف # ب!". لست متأكداً ، لكن يبدو لي أن الفكر الثالث والرابع والخامس على الأقل كان هو نفسه.

لتبديد الشكوك ، قمت بسرعة بتثبيت ESXi جديد على العينة ، وأخذت محرك الأقراص الأيسر ، وبعد قراءة من خلاله ، مرت خطوات المعالج. نعم. عند إضافة مخزن بيانات باستخدام المعالج ، يتم فقد جميع البيانات الموجودة على القرص دون القدرة على استعادة العملية واستعادة البيانات. في وقت لاحق ، قرأت في أحد المنتديات تقييماً لهذا التصميم من قِبل السيد: shitsome حماقة. والآن اتفق حقا.

بدءا من السادس ، تدفقت الأفكار بطريقة بناءة. حسنا. يستغرق التهيئة بضع ثوانٍ حتى بالنسبة لمحرك أقراص 3 تيرابايت. لذلك هذا هو تنسيق رفيع المستوى. لذلك ، تمت إعادة كتابة جدول الأقسام ببساطة. وبالتالي فإن البيانات لا تزال هناك. لذلك الآن دعونا نبحث عن بعض unformat وفويلا.

أقوم بتحميل السيارة من صورة التمهيد لـ Strelec ... واكتشفت أن برامج استرداد الأقسام معروفة للجميع باستثناء VMFS. على سبيل المثال ، يعرفون تخطيط القسم الخاص بـ Synology ، لكن VMFS لا يعرف ذلك.

تعداد البرامج غير مريح: في أحسن الأحوال ، يجد GetDataBack و R.Saver أقسام NTFS مع بنيات الدليل المباشر وأسماء الملفات الحية. لكن هذا لا يناسبني. أحتاج ملفين vmdk: مع قرص النظام وصندوق القمامة.

ثم أفهم ذلك ، على ما يبدو ، الآن سأقوم بتثبيت Windows وإخراج نسخة احتياطية من الملف. وفي الوقت نفسه أتذكر أن لدي جذر DFS هناك. وأيضًا نظام تخزين متفرّع تمامًا في حقوق الوصول إلى مجلدات الوحدات. ليس خيارا. الخيار الوحيد المقبول للوقت هو استعادة حالة النظام والقرص بالبيانات وجميع الحقوق.

googling مرة أخرى ، منتديات ، KB'shki ومرة ​​أخرى تبكي Yaroslavna: VMware ESXi لا يوفر آلية لاستعادة البيانات. جميع مواضيع المناقشة لها نهائيتان: استعاد شخص ما مساعدة من DiskInternals VMFS Recovery غير الرخيص أو شخص كان يروج بنشاط لخدماته بمساعدة من أدوات vmfs و dd . خيار شراء ترخيص DiskInternals VMFS Recovery بمبلغ 700 دولار ليس خيارًا. إن قبول شخص خارجي من "أراضي خصم محتمل" لبيانات الشركة ليس خيارًا أيضًا. ولكن تم غوغل أن أقسام VMFS يمكن أن تقرأ أيضا UFS Explorer.

DiskInternals VMFS الانتعاش

تم تنزيل الإصدار التجريبي وتثبيته. شاهد البرنامج بنجاح قسم VMFS فارغ:



في وضع الحذف (المسح السريع) ، عثرت أيضًا على مخزن بيانات رث مع مجلدات الجهاز الظاهري مع وجود أقراص في الداخل:



أظهرت المعاينة أن الملفات مباشرة:



كان تثبيت القسم في النظام ناجحًا ، ولكن لسبب ما ، كان للمجلدات الثلاثة نفس الجهاز الظاهري. بالطبع ، فإن قانون الخلاص ليس هو المطلوب.

مستكشف UFS

أظهر مسح القرص وجود 7 عقد. تزامن عدد العقد "بطريقة مذهلة" مع عدد ملفات * -flat.vmdk المكتشفة بواسطة VMFS Recovery:



أظهرت مقارنة أحجام الملفات وأحجام العقدة أيضًا تطابقًا يصل إلى البايت. في الوقت نفسه ، تمت استعادة أسماء ملفات * -flat.vmdk ، وبالتالي ، ينتمون إلى الأجهزة الافتراضية.



بشكل عام ، من وجهة نظر ESXi ، تتكون أقراص vmdk من ملفين: ملف بيانات (<اسم الجهاز> -flat.vmdk) وملف تقسيم القرص الفعلي (<اسم الجهاز> .vmdk). إذا قمت بتحميل ملف * -flat.vmdk من الجهاز المحلي إلى Datastore ، فلن يتعرف ESXi على أنه ملف قرص صالح. توجد مقالة في قاعدة معارف VMware حول كيفية إنشاء ملف واصف للقرص يدويًا: kb.vmware.com/s/article/1002511 ، لكن لم يكن لديّ ، لقد قمت بنسخ محتويات الملفات المقابلة من منطقة معاينة محتويات الملف في DiskInternals VMFS Recovery :



بعد 4 ساعات من تفريغ عقدة 2.5 تيرابايت من UFS Explorer و 20 ساعة من التحميل في برنامج Datastore hypervisor ، تم توصيل ملفات القرص الفاشلة بجهاز ظاهري تم إنشاؤه حديثًا. اختار عجلات تصل. لم يلاحظ أي فقدان البيانات.