بازیابی ماشین های مجازی از یک Datastore که به اشتباه مقداردهی اولیه شده است. داستان یک حماقت با پایان خوش

سلب مسئولیت: یادداشت برای اهداف سرگرمی است. تراکم خاص اطلاعات مفید در آن کم است. نوشته شده بود "برای خودم"

مقدمه غزلی

فایل dump در سازمان ما بر روی یک ماشین مجازی VMware ESXi 6 با ویندوز سرور 2016 اجرا می‌شود. و این فقط یک زباله‌دان نیست. این یک سرور تبادل فایل بین بخش‌های ساختاری است: همکاری، اسناد پروژه و پوشه‌هایی از اسکنرهای شبکه وجود دارد. به طور کلی، تمام عمر تولید اینجاست.

و این ظرف تمام عمر تولید شروع به آویزان کرد. علاوه بر این، میهمان می توانست بی سر و صدا خود را بدون تأثیرگذاری بر دیگران حلق آویز کند. او می‌توانست کل میزبان و بر این اساس، همه ماشین‌های مهمان دیگر را از بین ببرد. می‌توانم خودم را آویزان کنم و سرویس‌های کلاینت vSphere را آویزان کنم: یعنی فرآیندهای مهمانان دیگر زنده هستند، ماشین‌ها به درستی کار می‌کنند و پاسخ می‌دهند، اما شستشوی فایل وجود ندارد و vSphere Client به میزبان نمی‌چسبد. به طور کلی هیچ سیستمی قابل شناسایی نیست. یخ زدگی ممکن است در طول روز در یک بار کم رخ دهد. آنها می توانستند این کار را در شب و بدون بار انجام دهند. می تواند در شب هنگام پشتیبان گیری دیفرانسیل و بار متوسط. می تواند در آخر هفته ها در هنگام پشتیبان گیری کامل و بار بالا. و تنزل آشکاری از وضعیت وجود داشت. ابتدا سالی یک بار بود، سپس هر شش ماه یک بار. در پایان صبر من - دو بار در هفته.
من مشکل حافظه داشتم اما آنها به من اجازه ندادند که انباشت زباله را حتی در آخر هفته ها متوقف کنم و Memtest را اجرا کنم. منتظر تعطیلات اردیبهشت بودیم. در تعطیلات اردیبهشت، Memtest را اجرا کردم و ... هیچ خطایی پیدا نشد.

تعجب کردم و تصمیم گرفتم به تعطیلات بروم. زمانی که در تعطیلات بودم، حتی یک بار هم در محل زباله‌دانی نبود. و وقتی دوشنبه برای اولین روز سر کار برگشتم، یک انبوه زباله وجود داشت. من یک نسخه پشتیبان کامل را تحمل کردم و بلافاصله پس از تکمیل آن آویزان شدم. چنین استقبال گرمی از تعطیلات مرا به این تصمیم سوق داد که دیسک‌ها را با دستگاه مهمان به سمت میزبان دیگری بکشم.

و اگرچه از مدتها قبل شناخته شده بود که شما نمی توانید در اولین روز پس از تعطیلات کار جدی انجام دهید ، اگرچه من خودم را آماده می کردم تا تمام مسیر کار را انجام ندهم ، عصبانیت من از یخ زدگی دیگر هم روحیه ام را به هم زد. از سرم نذر می کند...

دیسک های فیزیکی به میزبان دیگری منتقل شده اند. اتصال داغ. در تنظیمات ذخیره سازی در برگه درایو دیسک ها ظاهر می شوند روی زبانه انبارهای داده روی این دیسک ها فضای ذخیره سازی وجود ندارد. تازه کردن - ظاهر نمی شود خوب، البته، اولین انگیزه - ذخیره سازی را اضافه کنید. Add Wizard توضیح می دهد که چه چیزی را پشتیبانی می کند. البته از VMFS نیز پشتیبانی می کند. من شک نداشتم. نگاهی سریع به پیام‌های جادوگر در هر مرحله: بعدی، بعدی، بعدی، پایان. چشم حتی نتوانست دایره کوچک زرد رنگ را با علامت تعجب در پایین پنجره یکی از پله های استاد بگیرد.

در پایان جادوگر، Datastore تازه در لیست ظاهر شد... و به همراه آن Datastores از دیسک های فیزیکی باقیمانده.

من به پیمایش در Datastore تازه اضافه شده ادامه می‌دهم و... خالی است. البته من دوباره در حیرت فرو رفتم. ساعت 8 صبح است، 15 دقیقه اول سر کار بعد از تعطیلات، هنوز شکر قهوه ام را هم نزدم. و اینجاست. اولین فکر این بود که من دیسک اشتباهی را از میزبان "بومی" بیرون کشیدم. من نگاه کردم تا ببینم آیا Datastore مورد نیاز در میزبان "بومی" وجود دارد یا خیر: نه، وجود نداشت. فکر دوم این بود: "لعنتی!" من مطمئن نیستم، اما به نظر من فکر سوم، چهارم و حداقل پنجم یکسان بود.

برای رفع شک و تردید، من به سرعت یک ESXi جدید را برای آزمایش نصب کردم، دیسک سمت چپ را گرفتم و با خواندن آن، مراحل جادوگر را طی کردم. آره. وقتی یک Datastore را با استفاده از جادوگر اضافه می‌کنید، تمام داده‌های روی دیسک بدون توانایی برگرداندن عملیات و بازیابی داده‌ها از بین می‌رود. بعداً در یکی از انجمن ها ارزیابی این طرح توسط یک استاد را خواندم: مزخرفات مزخرف. و من واقعا موافق بودم.

با شروع از ششم، افکار در جهت سازنده تر جریان یافت. خوب. مقداردهی اولیه حتی برای یک دیسک 3 ترابایتی چند ثانیه طول می کشد. بنابراین این قالب بندی سطح بالایی است. این بدان معناست که جدول پارتیشن به سادگی بازنویسی شده است. بنابراین داده ها هنوز وجود دارد. بنابراین، اکنون ما به دنبال برخی از فرمت‌ها و voila خواهیم بود.

من دستگاه را از تصویر بوت Strelec بوت می کنم ... و متوجه شدم که برنامه های بازیابی پارتیشن همه چیز را به جز VMFS می دانند. به عنوان مثال، آنها طرح پارتیشن Synology را می دانند، اما VMFS را نمی دانند.

جستجو در میان برنامه‌ها اطمینان‌بخش نیست: در بهترین حالت، GetDataBack و R.Saver پارتیشن‌های NTFS را با ساختار دایرکتوری زنده و نام فایل‌های زنده پیدا می‌کنند. اما این به من نمی خورد من به دو فایل vmdk نیاز دارم: با دیسک سیستم و دیسک فایل زباله.

و سپس می فهمم که به نظر می رسد اکنون ویندوز را نصب کرده و از یک فایل پشتیبان تهیه می کنم. و در همان زمان به یاد می آورم که من یک ریشه DFS در آنجا داشتم. و همچنین سیستمی از حقوق دسترسی به پوشه‌های بخش که از نظر وسعت و عواقب کاملاً وحشی است. یک گزینه نیست. تنها گزینه قابل قبول زمان، بازگرداندن وضعیت سیستم و دیسک با داده ها و کلیه حقوق است.

باز هم گوگل، انجمن ها، KB'shki و دوباره گریه یاروسلاونا: VMware ESXi مکانیزم بازیابی اطلاعات را ارائه نمی دهد. همه موضوعات بحث دو پایان دارند: شخصی با استفاده از DiskInternals VMFS Recovery گران قیمت بازیابی شده است، یا شخصی توسط یک متخصص نرم افزار که به طور فعال خدمات خود را تبلیغ می کند کمک می کند. vmfs-tools и dd. گزینه خرید مجوز DiskInternals VMFS Recovery به قیمت 700 دلار یک گزینه نیست. اجازه دادن به یک خارجی از "سرزمین یک دشمن بالقوه" برای دسترسی به داده های شرکت نیز یک گزینه نیست. اما در گوگل سرچ شد که پارتیشن های VMFS توسط UFS Explorer نیز قابل خواندن است.

DiskInternals VMFS Recovery

نسخه آزمایشی دانلود و نصب شد. برنامه با موفقیت پارتیشن خالی VMFS را دید:

حالت حذف حذف (اسکن سریع) من همچنین یک Datastore کهنه با پوشه‌های ماشین‌های مجازی با دیسک‌های داخل پیدا کردم:

پیش نمایش نشان داد که فایل ها زنده هستند:

نصب پارتیشن در سیستم موفقیت آمیز بود، اما به دلایلی نامعلوم، هر سه پوشه حاوی یک ماشین مجازی بودند. البته طبق قانون، پست چیزی نیست.

سه خط شرمتلاش برای قفل کردن بی شرمانه نرم افزار با شکست انجامید. اما UFS Explorer قفل شد.

من نگرش بسیار منفی نسبت به سرقت نرم افزار دارم. من به هیچ وجه استفاده از وسایلی را برای دور زدن حفاظت در برابر استفاده غیرمجاز تشویق نمی کنم.

من در وضعیت فاجعه باری قرار داشتم و به اقداماتی که به آن متوسل شده بودم اصلاً افتخار نمی کردم.

UFS Explorer

اسکن دیسک وجود 7 گره را نشان داد. تعداد گره ها به طور شگفت انگیزی با تعداد فایل های *-flat.vmdk شناسایی شده توسط VMFS Recovery همزمان بود:

مقایسه اندازه فایل و اندازه گره نیز مطابقت با بایت را نشان داد. در همان زمان، نام فایل های *-flat.vmdk و بر این اساس، تعلق آنها به ماشین های مجازی بازیابی شد.

به طور کلی، دیسک‌های vmdk از دیدگاه ESXi از دو فایل تشکیل شده‌اند: یک فایل داده (<machine name>-flat.vmdk) و یک فایل طرح‌بندی دیسک «فیزیکی» (<machine name>.vmdk). اگر یک فایل *-flat.vmdk را از یک ماشین محلی در Datastore آپلود کنید، ESXi آن را به عنوان یک فایل دیسک معتبر نمی شناسد. پایگاه دانش VMware مقاله ای در مورد نحوه ایجاد دستی یک فایل توصیف کننده دیسک دارد: kb.vmware.com/s/article/1002511، اما من مجبور نبودم این کار را انجام دهم، فقط محتویات فایل های مربوطه را از ناحیه پیش نمایش محتوای فایل در DiskInternals VMFS Recovery کپی کردم:

پس از 4 ساعت تخلیه یک گره 2,5 ترابایتی از UFS Explorer و 20 ساعت بارگذاری در Datastore Hypervisor، فایل های دیسک خراب به ماشین مجازی تازه ایجاد شده متصل شدند. دیسک ها برداشتند. هیچ از دست دادن داده مشاهده نشد.

منبع: www.habr.com