تنصل: المذكرة هي لأغراض الترفيه. الكثافة المحددة للمعلومات المفيدة فيه منخفضة. لقد كتب "لنفسي".
مقدمة غنائية
يعمل تفريغ الملفات في مؤسستنا على جهاز ظاهري VMware ESXi 6 يعمل بنظام التشغيل Windows Server 2016. وهذا ليس مجرد تفريغ للقمامة. هذا هو خادم تبادل الملفات بين الأقسام الهيكلية: يوجد تعاون ووثائق المشروع ومجلدات من الماسحات الضوئية للشبكة. بشكل عام، كل الحياة الإنتاجية هنا.
وبدأت هذه الحاوية التي تحتوي على جميع مراحل الإنتاج في التعلق. علاوة على ذلك، يمكن للضيف أن يشنق نفسه بهدوء دون التأثير على الآخرين. يمكنه القضاء على المضيف بأكمله، وبالتالي، جميع آلات الضيوف الأخرى. يمكنني أن أشنق نفسي وأعلق خدمات عملاء vSphere: أي أن عمليات الضيوف الآخرين لا تزال حية، وتعمل الأجهزة بشكل صحيح وتستجيب، ولكن لا توجد غسالة ملفات ولا يتشبث عميل vSphere بالمضيف. بشكل عام، لا يمكن تحديد أي نظام. يمكن أن يحدث التجميد أثناء النهار أثناء الحمل المنخفض. يمكنهم القيام بذلك في الليل أثناء عدم التحميل. يمكن أن يكون في الليل أثناء النسخ الاحتياطي التفاضلي ومتوسط الحمل. يمكن أن يكون ذلك في عطلات نهاية الأسبوع أثناء النسخ الاحتياطية الكاملة والتحميل العالي. وكان هناك تدهور واضح للوضع. في البداية كان ذلك مرة واحدة في السنة، ثم مرة واحدة كل ستة أشهر. في نهاية صبري - مرتين في الأسبوع.
كان لدي مشكلة في الذاكرة. لكنهم لم يسمحوا لي بإيقاف كومة القمامة حتى في عطلات نهاية الأسبوع وتشغيل Memtest. كنا ننتظر عطلة مايو. خلال عطلة مايو، قمت بتشغيل Memtest ولم يتم العثور على أي أخطاء.
لقد اندهشت وقررت الذهاب في إجازة. بينما كنت في إجازة، لم يكن هناك توقف واحد في مكب النفايات. وعندما عدت إلى العمل في اليوم الأول يوم الاثنين، كان هناك كومة قمامة. لقد تحملت نسخة احتياطية كاملة وعلقت مباشرة بعد الانتهاء منها. دفعني هذا الترحيب الحار من الإجازة إلى اتخاذ قرار بسحب الأقراص فعليًا باستخدام جهاز الضيف إلى مضيف آخر.
وعلى الرغم من أنه من المعروف منذ فترة طويلة أنه لا يمكنك القيام بأي شيء جدي في اليوم الأول بعد الإجازة، على الرغم من أنني كنت أجهز نفسي لعدم العمل طوال الطريق إلى العمل، إلا أن سخطي من التجميد الآخر قد عكّر مزاجي ونفسيتي. وعود من راسي...
تم نقل الأقراص الفعلية إلى مضيف آخر. اتصال ساخن. في إعدادات التخزين في علامة التبويب محركات الأقراص تظهر الأقراص. على علامة التبويب مخازن البيانات لا يوجد تخزين على هذه الأقراص. تحديث - لا تظهر. حسنًا، بالطبع، الدافع الأول - إضافة تخزين. يشرح معالج الإضافة ما يدعمه. بالطبع فهو يدعم أيضًا VMFS. لم أشك في ذلك. نظرة سريعة على رسائل المعالج في كل خطوة: التالي، التالي، التالي، إنهاء. ولم تقترب العين حتى من رؤية الدائرة الصفراء الصغيرة التي تحمل علامة التعجب أسفل نافذة إحدى درجات السيد.
في نهاية المعالج، ظهر مخزن البيانات الجديد في القائمة... ومعه مخازن البيانات من الأقراص الفعلية المتبقية.
أنتقل إلى التنقل عبر مخزن البيانات المُضاف حديثًا، وهو... فارغ. بالطبع، لقد عدت إلى الدهشة. إنها الثامنة صباحًا، أول 8 دقيقة في العمل بعد الإجازة، ولم أقم حتى بتقليب السكر في قهوتي بعد. وهي كذلك. كان الفكر الأول هو أنني قمت بسحب القرص الخطأ من المضيف "الأصلي". لقد بحثت لمعرفة ما إذا كان مخزن البيانات المطلوب موجودًا في المضيف "الأصلي": لا، لم يكن موجودًا. الفكرة الثانية كانت: "اللعنة!" لست متأكدا، ولكن يبدو لي أن الفكرة الثالثة والرابعة والخامسة على الأقل كانت هي نفسها.
لتبديد الشكوك، قمت بسرعة بتثبيت ESXi جديد للاختبار، وأخذت القرص الأيسر، وبعد قراءته بالفعل، اتبعت خطوات المعالج. نعم. عند إضافة مخزن بيانات باستخدام المعالج، يتم فقدان كافة البيانات الموجودة على القرص دون القدرة على التراجع عن العملية واستعادة البيانات. قرأت لاحقًا في أحد المنتديات تقييمًا لهذا التصميم بواسطة أستاذ: حماقة سخيفة. وأنا وافقت حقا.
ابتداء من السادس، تدفقت الأفكار في اتجاه أكثر بناءة. نعم. تستغرق عملية التهيئة بضع ثوانٍ حتى بالنسبة لقرص سعة 3 تيرابايت. إذن هذا هو التنسيق عالي المستوى. هذا يعني أنه تمت إعادة كتابة جدول الأقسام ببساطة. لذا فإن البيانات لا تزال موجودة. لذا، سنبحث الآن عن بعض الأشكال غير المنسقة.
أقوم بتمهيد الجهاز من صورة التمهيد Strelec... واكتشفت أن برامج استرداد الأقسام تعرف كل شيء باستثناء VMFS. على سبيل المثال، يعرفون تخطيط قسم Synology، ولكن ليس VMFS.
البحث في البرامج ليس أمرًا مطمئنًا: في أفضل الأحوال، يعثر GetDataBack وR.Saver على أقسام NTFS ذات بنية دليل مباشر وأسماء ملفات حية. لكن هذا لا يناسبني. أحتاج إلى ملفين vmdk: مع قرص النظام وقرص ملف المهملات.
وبعد ذلك أفهم أنه يبدو أنني سأقوم الآن بتثبيت Windows وطرحه من نسخة احتياطية للملفات. وفي نفس الوقت أتذكر أنه كان لدي جذر DFS هناك. وأيضًا نظام حقوق الوصول إلى مجلدات الأقسام وهو واسع النطاق تمامًا من حيث النطاق والتداعيات. ليس خيارا. الخيار الوحيد المقبول للوقت هو استعادة حالة النظام والقرص بالبيانات وجميع الحقوق.
مرة أخرى جوجل والمنتديات وKB'shki ومرة أخرى بكاء ياروسلافنا: لا يوفر برنامج VMware ESXi آلية لاستعادة البيانات. جميع سلاسل المناقشة لها نهايتان: تم استرداد شخص ما باستخدام برنامج DiskInternals VMFS Recovery باهظ الثمن، أو تم مساعدة شخص ما من قبل متخصص في البرامج للترويج لخدماته بشكل نشط أدوات-vmfs и dd. لا يعد خيار شراء ترخيص DiskInternals VMFS Recovery مقابل 700 دولار خيارًا. إن السماح لشخص خارجي من "منطقة العدو المحتمل" بالوصول إلى بيانات الشركة ليس خيارًا أيضًا. ولكن تم البحث في Google عن إمكانية قراءة أقسام VMFS أيضًا بواسطة UFS Explorer.
استرداد DiskInternals VMFS
تم تنزيل النسخة التجريبية وتثبيتها. نجح البرنامج في رؤية قسم VMFS الفارغ:
وضع إلغاء الحذف (المسح السريع) لقد عثرت أيضًا على مخزن بيانات متهالك يحتوي على مجلدات من الأجهزة الافتراضية التي تحتوي على أقراص بداخلها:
أظهرت المعاينة أن الملفات حية:
تم تثبيت القسم في النظام بنجاح، ولكن لسبب غير معروف، احتوت المجلدات الثلاثة على نفس الجهاز الظاهري. وطبعا بحسب القانون ليس الخسة هي المطلوبة.
ثلاثة خطوط من العارانتهت محاولة قفل البرنامج بلا خجل بالفشل. لكن UFS Explorer مغلق.
لدي موقف سلبي للغاية تجاه سرقة البرمجيات. لا أشجع بأي حال من الأحوال استخدام وسائل لتجاوز الحماية ضد الاستخدام غير المرخص.
لقد كنت في وضع كارثي ولم أكن فخوراً على الإطلاق بالإجراءات التي لجأت إليها.
مستكشف UFS
أظهر فحص القرص وجود 7 عقد. تزامن عدد العقد "بشكل مدهش" مع عدد ملفات *-flat.vmdk التي اكتشفها VMFS Recovery:
أظهرت المقارنة بين أحجام الملفات وأحجام العقد أيضًا تطابقًا مع البايت. في الوقت نفسه، تمت استعادة أسماء ملفات *-flat.vmdk، وبالتالي انتمائها إلى الأجهزة الافتراضية.
بشكل عام، تتكون أقراص vmdk من وجهة نظر ESXi من ملفين: ملف بيانات (<اسم الجهاز>-flat.vmdk) وملف تخطيط القرص "المادي" (<اسم الجهاز>.vmdk). إذا قمت بتحميل ملف *-flat.vmdk إلى Datastore من جهاز محلي، فلن يتعرف عليه ESXi كملف قرص صالح. تحتوي قاعدة معارف VMware على مقالة حول كيفية إنشاء ملف واصف القرص يدويًا: ، ولكن لم يكن علي القيام بذلك، لقد قمت ببساطة بنسخ محتويات الملفات المقابلة من منطقة معاينة محتوى الملف في DiskInternals VMFS Recovery:
بعد 4 ساعات من إلغاء تحميل عقدة سعة 2,5 تيرابايت من UFS Explorer و20 ساعة من التحميل في مخزن بيانات برنامج Hypervisor، تم توصيل ملفات القرص المعطوبة بالجهاز الظاهري الذي تم إنشاؤه حديثًا. التقطت الأقراص. ولم يلاحظ أي فقدان للبيانات.
المصدر: www.habr.com