خرابی ماشین مجازی یکی از جدیترین مشکلاتی است که میتواند زیرساخت IT یک شرکت، سازمان یا دیتاسنتر را درگیر کند. امروز بسیاری از سرویسهای مهم مثل نرمافزارهای مالی، دیتابیسها، فایلسرورها، سیستمهای اتوماسیون اداری، وبسرورها، نرمافزارهای سازمانی و سرویسهای داخلی روی پلتفرمهایی مثل VMware، Hyper-V، ESXi، Proxmox یا VirtualBox اجرا میشوند. به همین دلیل، خرابی یک ماشین مجازی فقط به معنی از کار افتادن یک سیستم ساده نیست؛ بلکه میتواند باعث توقف کامل یک سرویس حیاتی، قطع دسترسی کاربران، اختلال در فرآیندهای کاری و حتی از دست رفتن اطلاعات مهم شود.
وقتی خرابی ماشین مجازی اتفاق میافتد، مسئله اصلی فقط روشن شدن دوباره VM نیست. موضوع مهمتر این است که اطلاعات داخل ماشین مجازی سالم باقی بماند و بدون آسیب بیشتر قابل بازیابی باشد. در بسیاری از پروندهها، فایلهای اصلی VM مثل VMDK، VHD، VHDX، VMX، AVHDX، Snapshot یا Datastore دچار مشکل میشوند و اگر کاربر یا مدیر شبکه بدون بررسی تخصصی اقدام کند، احتمال از بین رفتن اطلاعات بیشتر میشود.
در چنین شرایطی، بهترین کار این است که قبل از هر اقدام، وضعیت توسط متخصص بررسی شود. اگر ماشین مجازی بالا نمیآید، فایل VMDK باز نمیشود، Hyper-V خطای مسیر فایل میدهد، Datastore در ESXi نمایش داده نمیشود یا RAID زیر ماشین مجازی دچار مشکل شده، بهتر است ابتدا مسیر ریکاوری ماشین مجازی بهصورت تخصصی بررسی شود.
خرابی ماشین مجازی یعنی چه؟
خرابی ماشین مجازی به وضعیتی گفته میشود که VM بهدرستی روشن نمیشود، فایلهای آن قابل شناسایی نیستند، سیستمعامل داخل ماشین مجازی بوت نمیشود، Snapshot یا Checkpoint مشکل پیدا کرده یا Datastore از دسترس خارج شده است. این خرابی ممکن است فقط مربوط به نرمافزار داخل VM نباشد؛ گاهی مشکل از هارد فیزیکی، SSD، RAID، Storage، فایل سیستم میزبان یا حتی کنترلر سرور شروع میشود.
در یک سیستم معمولی، اطلاعات مستقیماً روی هارد یا SSD ذخیره میشود. اما در محیط مجازی، اطلاعات داخل فایلهایی مثل VMDK در VMware یا VHD و VHDX در Hyper-V قرار دارد. این فایلها در واقع هارد دیسک مجازی ماشین هستند. به همین دلیل، خرابی ماشین مجازی میتواند چند لایه مختلف داشته باشد: لایه سختافزار، لایه RAID، لایه Datastore، لایه فایل دیسک مجازی و لایه سیستمعامل داخل VM.
برای مثال، ممکن است یک سرور HP با چند هارد SAS روی RAID 5 کار کند. اگر دو هارد دچار مشکل شوند، ساختار RAID آسیب ببیند، Datastore در ESXi درست Mount نشود و فایل VMDK هم ناقص باشد، مشکل فقط با یک نرمافزار ساده حل نمیشود. در این حالت، ابتدا باید زیرساخت فیزیکی و RAID بررسی شود، سپس وضعیت فایلهای ماشین مجازی تحلیل گردد.
نشانههای مهم خرابی ماشین مجازی
خرابی ماشین مجازی همیشه با یک پیام خطای واضح خودش را نشان نمیدهد. گاهی ماشین مجازی از لیست سرور حذف میشود، گاهی روشن میشود اما سیستمعامل بالا نمیآید، گاهی فایلهای داخل VM دیده نمیشوند و گاهی هم خود Datastore در دسترس نیست.
| نشانه خرابی ماشین مجازی | معنی احتمالی | اقدام درست |
|---|---|---|
| ماشین مجازی روشن نمیشود | خرابی فایل VMDK/VHDX، Snapshot یا فایل سیستم داخل VM | تلاش برای Boot را متوقف کنید و وضعیت VM بررسی شود |
| فایل VMDK یا VHDX باز نمیشود | آسیب به دیسک مجازی یا متادیتای فایل | فایل را Rename، Repair یا Replace نکنید |
| Datastore در ESXi نمایش داده نمیشود | خرابی VMFS، RAID، Storage یا ارتباط LUN | قبل از Mount اجباری، Storage بررسی شود |
| Snapshot حذف یا Merge نمیشود | خرابی Snapshot Chain یا کمبود فضای Datastore | Snapshot را دستی حذف یا Merge نکنید |
| Hyper-V خطای Missing Disk میدهد | مسیر فایل VHDX تغییر کرده یا فایل آسیب دیده | مسیر فایلها و Checkpointها باید تحلیل شود |
| VM بعد از قطع برق بالا نمیآید | احتمال Corruption در فایل سیستم یا دیسک مجازی | روی همان VM تستهای مکرر انجام ندهید |
| سرور بعد از Rebuild بالا نمیآید | احتمال آسیب به RAID یا ترتیب دیسکها | Rebuild مجدد انجام ندهید |
| فایلهای دیتابیس داخل VM باز نمیشوند | خرابی دیتابیس یا فایل سیستم داخلی VM | ابتدا دیسک مجازی و سپس دیتابیس بررسی شود |
اگر یکی از این نشانهها را میبینید، نباید با تستهای متعدد، روشن و خاموش کردن مکرر یا ابزارهای Repair عمومی روی همان Storage کار کنید. در خرابی ماشین مجازی، هر بار نوشتن اطلاعات جدید میتواند بخشی از دادههای قابل بازیابی را از بین ببرد.
چه زمانی باید برای ریکاوری ماشین مجازی اقدام کنیم؟
زمان مناسب برای اقدام، دقیقاً همان لحظهای است که متوجه خرابی ماشین مجازی میشوید. هرچه زودتر جلوی نوشتن اطلاعات جدید گرفته شود، شانس بازیابی بالاتر میرود. اما اقدام سریع به معنی اقدام عجولانه نیست. در این شرایط باید سیستم حفظ شود، نه اینکه با روشهای آزمایشی وضعیت بدتر شود.
اگر ماشین مجازی بالا نمیآید، باید تلاشهای مکرر برای Boot متوقف شود. اگر فایل VMDK یا VHDX خراب است، نباید آن را با نرمافزارهای ناشناس Repair کرد. اگر Snapshot مشکل دارد، نباید بدون بررسی ساختار آن را Merge یا Delete کرد. اگر RAID مشکل دارد، نباید بلافاصله Rebuild انجام داد. اگر Datastore نمایش داده نمیشود، نباید فرمت، Initialize یا Mount اجباری انجام شود.
در چنین مواردی، هدف اصلی این است که ساختار فعلی حفظ شود تا متخصص بتواند علت خرابی ماشین مجازی را دقیق تشخیص دهد. گاهی اطلاعات داخل VM هنوز قابل بازیابی است، اما چند اقدام اشتباه باعث میشود همان اطلاعات سالم هم آسیب ببیند.
دلایل رایج خرابی VM در VMware، Hyper-V و ESXi
خرابی ماشین مجازی دلایل مختلفی دارد. بعضی از آنها نرمافزاری هستند، بعضی سختافزاری و بعضی هم به دلیل خطای انسانی یا مدیریت نادرست زیرساخت رخ میدهند.
| دلیل خرابی | توضیح کوتاه | میزان ریسک |
|---|---|---|
| حذف اشتباه VM | حذف فایلهای اصلی ماشین مجازی از Datastore یا Storage | زیاد |
| خرابی فایل VMDK یا VHDX | آسیب به دیسک مجازی اصلی VM | بسیار زیاد |
| خرابی Snapshot یا Checkpoint | از بین رفتن زنجیره تغییرات ماشین مجازی | بسیار زیاد |
| خرابی Datastore در ESXi | عدم دسترسی به فایلهای VM روی VMFS یا Storage | بسیار زیاد |
| خرابی RAID زیر ماشین مجازی | آسیب به ساختار ذخیرهسازی اصلی سرور | بسیار زیاد |
| قطع برق ناگهانی | ایجاد Corruption در فایل سیستم یا دیتابیس داخل VM | متوسط تا زیاد |
| پر شدن Datastore | توقف عملیات نوشتن و خرابی Snapshot یا فایلهای VM | زیاد |
| حمله باجافزار | رمزنگاری فایلهای VMDK، VHDX یا اطلاعات داخل VM | بسیار زیاد |
حذف اشتباه ماشین مجازی
یکی از رایجترین دلایل خرابی ماشین مجازی، حذف اشتباه VM یا فایلهای وابسته به آن است. در VMware ESXi، گاهی کاربر بهجای Remove from Inventory، گزینه Delete from Disk را انتخاب میکند. در حالت اول فقط ماشین مجازی از لیست نمایش حذف میشود، اما در حالت دوم ممکن است فایلهای اصلی از Datastore پاک شوند.
در Hyper-V هم حذف اشتباه ماشین مجازی، جابهجایی فایلهای VHDX یا حذف Checkpointها میتواند باعث از دست رفتن دسترسی به اطلاعات شود. در این شرایط، اگر بعد از حذف، اطلاعات جدید روی همان Storage نوشته نشده باشد، احتمال بازیابی بیشتر است. اما ادامه کار با همان سرور یا ایجاد VM جدید روی همان فضا میتواند باعث Overwrite شود.
خرابی فایل VMDK یا VHDX
فایل VMDK در VMware و فایلهای VHD یا VHDX در Hyper-V نقش دیسک اصلی ماشین مجازی را دارند. اگر این فایلها آسیب ببینند، ماشین مجازی ممکن است اصلاً روشن نشود یا هنگام Boot خطا بدهد. خرابی فایل VMDK یکی از حساسترین حالتهای خرابی ماشین مجازی است، چون گاهی فایل اصلی داده سالم است اما فایل descriptor یا ساختار متادیتا آسیب دیده است.
در Hyper-V نیز خرابی VHDX یا AVHDX میتواند باعث شود ماشین مجازی مسیر دیسک را نشناسد یا روی Checkpoint گیر کند. در چنین شرایطی، تغییر نام فایلها، Merge دستی یا ساخت VM جدید بدون تحلیل دقیق میتواند خطرناک باشد.
خرابی Snapshot یا Checkpoint
Snapshot در VMware و Checkpoint در Hyper-V ابزار مفیدی برای ثبت وضعیت موقت ماشین مجازی است، اما نباید آن را با بکاپ اشتباه گرفت. Snapshot برای نگهداری طولانیمدت طراحی نشده و اگر مدت زیادی باقی بماند، حجم آن زیاد شود یا هنگام Consolidation مشکلی رخ دهد، ممکن است باعث خرابی ماشین مجازی شود.
خرابی Snapshot میتواند باعث شود VM روشن شود اما اطلاعات ناقص باشد، یا اصلاً بالا نیاید. گاهی آخرین تغییرات مهم داخل فایلهای Delta یا AVHDX ذخیره شده و اگر این فایلها اشتباه Merge یا حذف شوند، دادههای جدید از بین میروند.
خرابی Datastore در ESXi
در محیط VMware ESXi، ماشینهای مجازی معمولاً روی Datastore ذخیره میشوند. این Datastore ممکن است روی RAID داخلی سرور، SAN، NAS، iSCSI یا Fibre Channel قرار داشته باشد. اگر ساختار VMFS آسیب ببیند یا ارتباط Storage قطع شود، ممکن است کل ماشینهای مجازی از دسترس خارج شوند.
در این شرایط، مشکل فقط فایل VMDK نیست. باید مشخص شود خرابی از Datastore است، از RAID است، از کنترلر سرور است یا از هاردهای فیزیکی. برای آشنایی بیشتر با ساختار فنی VMware، میتوان به مستندات رسمی VMware مراجعه کرد، اما در زمان خرابی واقعی، بررسی عملی باید توسط متخصص انجام شود.
خرابی RAID زیر ماشین مجازی
در بسیاری از سازمانها، ماشینهای مجازی روی RAID 5، RAID 6، RAID 10 یا استوریجهای سازمانی قرار دارند. اگر یک یا چند هارد خراب شود یا Rebuild اشتباه انجام شود، فایلهای ماشین مجازی هم آسیب میبینند. در این حالت، قبل از بررسی VM باید وضعیت RAID و سرور تحلیل شود.
یکی از اشتباهات خطرناک این است که کاربر بعد از خرابی یک هارد، سریعاً هارد جدید را جایگزین کند و Rebuild را اجرا کند. اگر هارد دیگری هم بدسکتور داشته باشد یا ترتیب دیسکها اشتباه شود، Rebuild میتواند اطلاعات را بیشتر تخریب کند. در این شرایط، ابتدا باید مسیر بازیابی اطلاعات سرور بررسی شود.
خرابی هارد یا SSD میزبان
گاهی خرابی ماشین مجازی به دلیل خرابی خود هارد یا SSD میزبان است. اگر هارد دچار بدسکتور شدید، خرابی هد، مشکل فریمور یا آسیب فیزیکی باشد، فایلهای VM ممکن است ناقص خوانده شوند. در چنین حالتی، تمرکز فقط روی VMDK یا VHDX کافی نیست و ابتدا باید وضعیت دیسک بررسی شود. برای این موارد، صفحه ریکاوری هارد میتواند مسیر مرتبطتری باشد.
اگر ماشین مجازی روی SSD ذخیره شده باشد، شرایط حساستر میشود. فعال بودن TRIM، خرابی کنترلر، آسیب چیپهای NAND یا مشکلات فریمور میتواند مسیر بازیابی را پیچیدهتر کند. در این حالت، بررسی تخصصی ریکاوری SSD اهمیت زیادی دارد.
قطع برق و خاموش شدن ناگهانی
قطع برق، خاموش شدن ناگهانی سرور یا Restart اجباری میتواند باعث خرابی فایل سیستم داخل VM یا آسیب به فایلهای دیسک مجازی شود. این اتفاق مخصوصاً زمانی خطرناک است که داخل ماشین مجازی دیتابیس، نرمافزار حسابداری، فایلسرور یا سرویس در حال نوشتن اطلاعات فعال باشد.
در چنین شرایطی، ممکن است خود فایل VMDK یا VHDX به ظاهر سالم باشد، اما اطلاعات داخل آن آسیب دیده باشد. بنابراین بررسی باید هم روی سطح دیسک مجازی و هم روی فایل سیستم داخل ماشین مجازی انجام شود.
حملات باجافزاری
در برخی حملات سایبری، مهاجم مستقیماً فایلهای VMDK، VHDX، VMX یا بکاپهای ماشین مجازی را رمزنگاری میکند. گاهی هم باجافزار داخل خود VM اجرا میشود و فایلهای دیتابیس، اسناد، فایلهای اشتراکی یا برنامههای سازمانی را از دسترس خارج میکند.
در این شرایط، نباید بدون تحلیل دقیق اقدام به حذف فایلها، نصب مجدد سیستمعامل یا Restore عجولانه بکاپ کرد. باید ابتدا مشخص شود چه بخشهایی رمزنگاری شدهاند، آیا بکاپ سالم وجود دارد یا نه و آیا امکان استخراج اطلاعات از نسخههای سالمتر وجود دارد.
پر شدن فضای Datastore
پر شدن Datastore یکی از دلایل مهم خرابی ماشین مجازی است. وقتی فضای ذخیرهسازی کامل شود، عملیات نوشتن متوقف میشود و فایلهای Snapshot، Log یا دیسک مجازی ممکن است ناقص شوند. این مسئله در محیطهایی که Snapshotهای طولانیمدت نگهداری میشود، بسیار رایج است.
پر شدن Datastore ممکن است باعث خطا در Consolidation، خاموش شدن VM یا آسیب به فایلهای Delta شود. بنابراین مانیتورینگ فضای Datastore باید یکی از وظایف ثابت مدیر شبکه باشد.
هنگام خرابی ماشین مجازی چه کارهایی نباید انجام دهیم؟
در خرابی ماشین مجازی، مهمترین اصل این است که وضعیت بدتر نشود. خیلی از پروندههایی که در ابتدا شانس بازیابی خوبی دارند، به دلیل چند اقدام اشتباه پیچیده یا حتی غیرقابل بازیابی میشوند.
| کار اشتباه | چرا خطرناک است؟ | نتیجه احتمالی |
|---|---|---|
| روشن کردن مکرر VM | ممکن است روی دیسک مجازی اطلاعات جدید نوشته شود | کاهش شانس ریکاوری |
| اجرای Repair روی VMDK/VHDX | ممکن است ساختار فایل را تغییر دهد | سختتر شدن بازیابی |
| Rebuild عجولانه RAID | ممکن است ترتیب دادهها را بههم بزند | آسیب جدی به فایلهای VM |
| Merge دستی Snapshot | امکان حذف آخرین تغییرات VM وجود دارد | از دست رفتن دادههای جدید |
| Restore بکاپ بدون تست | بکاپ ممکن است ناقص یا قدیمی باشد | از بین رفتن وضعیت فعلی |
| ساخت VM جدید روی همان Datastore | باعث Overwrite شدن اطلاعات حذفشده میشود | کاهش شدید شانس بازیابی |
| جابهجایی هاردهای سرور | ترتیب RAID ممکن است تغییر کند | پیچیدهتر شدن ریکاوری |
| فرمت یا Initialize کردن Storage | ساختار قبلی ذخیرهسازی از بین میرود | خطر از دست رفتن کامل داده |
هرکدام از این اقدامات میتواند باعث Overwrite، تغییر ساختار فایلها یا از بین رفتن آخرین نسخه سالم اطلاعات شود. اگر اطلاعات داخل ماشین مجازی برای شما مهم است، قبل از هر اقدامی باید وضعیت فعلی حفظ شود.
9 هشدار مهم قبل از ریکاوری VM
اولین هشدار این است که روشن کردن مکرر VM همیشه بیخطر نیست. اگر فایل سیستم خراب باشد، هر بار Boot میتواند تغییرات جدیدی روی دیسک ایجاد کند.
دومین هشدار مربوط به Snapshot است. Snapshot بکاپ نیست و مدیریت اشتباه آن میتواند باعث از دست رفتن دادهها شود.
سومین هشدار درباره RAID است. اگر RAID زیر ماشین مجازی خراب شده، Rebuild عجولانه میتواند خطرناک باشد.
چهارمین هشدار این است که فایلهای VMDK و VHDX را نباید بدون گرفتن Image تغییر داد.
پنجمین هشدار مربوط به بکاپ است. بکاپ باید قبل از Restore تست شود، چون ممکن است ناقص، قدیمی یا آلوده باشد.
ششمین هشدار این است که ابزارهای عمومی ریکاوری برای همه سناریوهای VM مناسب نیستند.
هفتمین هشدار مربوط به Datastore است. نوشتن اطلاعات جدید روی Datastore آسیبدیده میتواند شانس بازیابی را کم کند.
هشتمین هشدار درباره دیتابیس داخل VM است. حتی اگر ماشین مجازی روشن شود، ممکن است دیتابیس داخل آن خراب باشد.
نهمین هشدار این است که هدف ریکاوری همیشه روشن کردن VM نیست؛ گاهی استخراج اطلاعات مهم از داخل VM بهترین و امنترین مسیر است.
فرایند تخصصی بررسی خرابی ماشین مجازی در مرکز بازیابی اطلاعات
این بخش برای آموزش انجام ریکاوری توسط کاربر نیست. هدف این است که بدانید در یک مرکز تخصصی، خرابی ماشین مجازی چگونه بررسی میشود و چرا نباید بدون ابزار و تجربه کافی روی VM آسیبدیده کار کرد.
در مرحله اول، وضعیت فعلی سرور و Storage حفظ میشود تا اطلاعات جدید روی دیسکها نوشته نشود. سپس سلامت هاردها، SSDها، RAID Controller، SAN، NAS یا LUN بررسی میشود. اگر مشکل از RAID باشد، ابتدا آرایه باید تحلیل شود و بعد سراغ فایلهای VM رفت.
در مرحله بعد، از دیسکها یا فایلهای مهم Image تهیه میشود. این کار باعث میشود عملیات بازیابی روی نسخه کپی انجام شود، نه روی منبع اصلی. سپس فایلهای ماشین مجازی مثل VMDK، VHDX، VMX، AVHDX، Delta و Snapshot بررسی میشوند.
اگر ساختار دیسک مجازی آسیب دیده باشد، امکان تعمیر یا بازسازی بخشهایی از آن بررسی میشود. در بسیاری از موارد، هدف نهایی این نیست که خود VM حتماً Boot شود؛ بلکه استخراج اطلاعات مهم مثل دیتابیس، فایلهای مالی، اسناد سازمانی یا اطلاعات نرمافزارها اهمیت بیشتری دارد.
اگر داخل ماشین مجازی دیتابیسهایی مثل SQL Server، MySQL یا Oracle وجود داشته باشد، بعد از استخراج اطلاعات، سلامت فایلهای دیتابیس هم باید بررسی شود. برای این موارد، صفحه بازیابی اطلاعات دیتابیس مرتبط است.
تفاوت خرابی ماشین مجازی در VMware، Hyper-V، Proxmox و VirtualBox
هر پلتفرم مجازیسازی ساختار خاص خودش را دارد و خرابی در هرکدام مسیر بررسی متفاوتی دارد.
| پلتفرم مجازیسازی | فایلها و ساختارهای مهم | خطاهای رایج |
|---|---|---|
| VMware / ESXi | VMDK، VMX، flat.vmdk، delta.vmdk، Datastore، VMFS | خرابی VMDK، مشکل Snapshot Chain، خطای Datastore |
| Hyper-V | VHD، VHDX، AVHDX، VMCX، Checkpoint | Missing Disk، خرابی VHDX، مشکل Checkpoint |
| Proxmox | QCOW2، RAW، ZFS، LVM، Ceph | خرابی Storage، مشکل Snapshot، آسیب دیسک مجازی |
| VirtualBox | VDI، VMDK، VHD | باز نشدن دیسک مجازی، حذف اشتباه فایل VM |
| سرورهای RAID-based | RAID 5، RAID 6، RAID 10، SAS/SATA/SSD | خرابی هارد، Rebuild اشتباه، از بین رفتن آرایه |
در VMware و ESXi، معمولاً با فایلهای VMDK، VMX، flat.vmdk، delta.vmdk، Snapshot و Datastore سروکار داریم. خرابی VMFS، مشکل Snapshot Chain یا حذف فایل Descriptor میتواند باعث بالا نیامدن ماشین مجازی شود.
در Hyper-V، فایلهای VHD، VHDX، AVHDX، VMCX و Checkpoint اهمیت زیادی دارند. در این محیط، خرابی Checkpoint یا جابهجایی فایل VHDX میتواند باعث خطای مسیر فایل یا Missing Disk شود. برای مطالعه ساختار Hyper-V میتوان به مستندات رسمی Microsoft Hyper-V مراجعه کرد.
در Proxmox، نوع Storage بسیار مهم است. ممکن است ماشین مجازی روی ZFS، LVM، Ceph، QCOW2 یا RAW ذخیره شده باشد. هرکدام از این ساختارها مسیر بررسی متفاوتی دارند. برای آشنایی کلی با این پلتفرم، مستندات رسمی Proxmox VE منبع معتبری است.
در VirtualBox، بیشتر با فایلهای VDI، VMDK یا VHD روبهرو هستیم. این پلتفرم بیشتر در محیطهای تستی و شخصی دیده میشود، اما خرابی فایل دیسک مجازی در آن هم میتواند باعث از دست رفتن اطلاعات شود.
چرا ریکاوری ماشین مجازی از ریکاوری هارد معمولی حساستر است؟
در ریکاوری هارد معمولی، معمولاً با یک دیسک و یک فایل سیستم سروکار داریم. اما در خرابی ماشین مجازی، چندین لایه روی هم قرار گرفتهاند. ممکن است یک فایل VMDK چند ترابایتی روی RAID قرار داشته باشد، آن RAID روی چند هارد فیزیکی ساخته شده باشد، فایل VMDK داخل Datastore ذخیره شده باشد و داخل آن هم یک سیستمعامل با دیتابیس و نرمافزارهای حساس وجود داشته باشد.
این یعنی خرابی در هر لایه میتواند روی لایههای دیگر اثر بگذارد. اگر مشکل از هارد باشد و فقط فایل VMDK بررسی شود، نتیجه کامل نیست. اگر مشکل از Snapshot باشد و فقط سیستمعامل داخل VM بررسی شود، خطا تشخیص داده نمیشود. اگر مشکل از دیتابیس باشد و فقط VM روشن شود، ممکن است اطلاعات اصلی همچنان آسیب دیده باشد.
به همین دلیل، ریکاوری ماشین مجازی نیاز به شناخت همزمان سختافزار، RAID، Storage، فایل سیستم، مجازیسازی و بازیابی اطلاعات دارد.
خدمات ریکاوری ماشین مجازی در امدادسیستم
امدادسیستم خدمات تخصصی بازیابی اطلاعات را برای هارد، SSD، سرور، RAID، دیتابیس و ماشینهای مجازی ارائه میدهد. اگر ماشین مجازی شما حذف شده، فایل VMDK یا VHDX باز نمیشود، ESXi دیتاستور را نمایش نمیدهد، Hyper-V خطای مسیر فایل میدهد یا سرور مجازی بعد از خرابی RAID بالا نمیآید، بهتر است قبل از هر اقدام، وضعیت توسط کارشناس بررسی شود.
در ریکاوری ماشین مجازی، هدف فقط روشن کردن VM نیست. هدف اصلی، حفظ و بازیابی اطلاعات مهم شماست. گاهی روشن کردن ماشین مجازی خراب میتواند دادهها را بیشتر تخریب کند. به همین دلیل، ابتدا ساختار Storage، RAID، فایلهای VM، Snapshotها و سیستمعامل داخل ماشین مجازی بررسی میشود و سپس امنترین مسیر انتخاب میگردد.
چگونه از خرابی دوباره ماشین مجازی جلوگیری کنیم؟
برای کاهش ریسک خرابی ماشین مجازی، باید چند اصل مهم رعایت شود. Snapshot را بهعنوان بکاپ دائمی استفاده نکنید. Snapshot برای تغییرات کوتاهمدت مناسب است، نه نگهداری طولانیمدت. بکاپها باید بهصورت منظم تهیه شوند و مهمتر از آن، باید دورهای تست شوند.
سلامت RAID، هاردهای سرور، SSDها، کنترلر و فضای Datastore باید مانیتور شود. پر شدن Datastore یکی از دلایل مهم خرابی VM است. استفاده از UPS، بکاپ خارج از سایت، مانیتورینگ سرور، بررسی لاگها و مستندسازی تنظیمات ماشین مجازی هم میتواند ریسک از دست رفتن اطلاعات را کاهش دهد.
جمعبندی
خرابی ماشین مجازی یک مشکل ساده نیست و نباید با آزمون و خطا با آن برخورد کرد. اگر VM بالا نمیآید، فایل VMDK یا VHDX خراب شده، Snapshot مشکل دارد، Datastore از دسترس خارج شده یا RAID زیر ماشین مجازی آسیب دیده، بهترین کار این است که قبل از هر اقدام، وضعیت حفظ و توسط متخصص بررسی شود.
در بسیاری از موارد، اگر بعد از خرابی ماشین مجازی اقدام اشتباه انجام نشود، امکان بازیابی اطلاعات وجود دارد. اما روشن کردن مکرر VM، Rebuild اشتباه، Restore عجولانه یا دستکاری فایلهای دیسک مجازی میتواند شانس ریکاوری را کاهش دهد.
آیا ماشین مجازی حذف شده قابل بازیابی است؟
بله، در بسیاری از موارد اگر بعد از حذف، اطلاعات جدید روی همان Storage نوشته نشده باشد، امکان بازیابی ماشین مجازی وجود دارد. میزان موفقیت به نوع حذف، وضعیت Datastore، سلامت RAID و کامل بودن فایلهای VMDK یا VHDX بستگی دارد.
اگر فایل VMDK خراب شود چه باید کرد؟
نباید فایل VMDK را با ابزارهای عمومی Repair کرد یا تغییر نام داد. ابتدا باید ساختار فایل، Snapshotها، Datastore و وضعیت Storage بررسی شود. در بسیاری از موارد، امکان استخراج اطلاعات از داخل VMDK وجود دارد.
آیا Snapshot همان بکاپ است؟
خیر. Snapshot جایگزین بکاپ نیست. Snapshot فقط وضعیت موقت ماشین مجازی را نگه میدارد و اگر طولانیمدت باقی بماند یا هنگام حذف و ادغام دچار خطا شود، میتواند خودش باعث خرابی VM شود.
بعد از خرابی VM چه کار نکنیم؟
ماشین مجازی را چند بار روشن نکنید، RAID را Rebuild نکنید، فایلهای VMDK یا VHDX را دستکاری نکنید، Snapshot را Merge نکنید و روی Datastore اطلاعات جدید ننویسید.
آیا فقط اطلاعات داخل VM قابل بازیابی است؟
بله. همیشه لازم نیست خود ماشین مجازی دوباره Boot شود. گاهی بهترین روش این است که دیسک مجازی در محیط امن بررسی شود و فقط فایلهای مهم، دیتابیسها یا اطلاعات سازمانی از داخل آن استخراج گردد.
هزینه ریکاوری ماشین مجازی چطور مشخص میشود؟
هزینه به نوع خرابی، حجم اطلاعات، نوع پلتفرم، وضعیت RAID یا Storage، تعداد هاردها و میزان آسیب فایلهای VM بستگی دارد. بعد از بررسی اولیه، امکان اعلام هزینه دقیقتر وجود دارد.