بازیابی اضطراری  VMware (Emergency VMware Recovery )

سناریو بحرانی دیتاسنتر + اقدامات فوری ریکاوری

در شرایط اضطراری زمانی که زیرساخت مبتنی بر VMware vSphere دچار خرابی شده و چندین ماشین مجازی (VM) یا کل Datastore از دسترس خارج شده‌اند.

هدف این سند:
جلوگیری از بدتر شدن خرابی + حفظ قابلیت ریکاوری + کاهش Data Loss

1. اولین اصل در خرابی VMware 

 هرگز این کارها را انجام ندهید:

• روشن کردن مجدد VMهای خراب

• Rebuild کردن RAID بدون تحلیل

• Reinstall کردن ESXi

• Mount مجدد Datastore به‌صورت Force

• Delete کردن Snapshot chain

• Copy/Move کردن VMDKها روی همان Storage

 این اقدامات معمولاً باعث Overwrite شدن داده‌های قابل ریکاوری می‌شوند.

2. تشخیص سریع نوع خرابی 

حالت A: Datastore Down

• VMFS / NFS دیده نمی‌شود

• VMها Unavailable هستند

احتمال خرابی Storage Backend (RAID / ZFS / SAN)

حالت B: VM Corruption

• VM روشن نمی‌شود

• VMDK missing یا corrupted

احتمال Snapshot chain یا disk corruption

حالت C: Host Failure

• ESXi down یا reboot loop

• Cluster split

 احتمال مشکل Host یا Storage connectivity

حالت D: Partial VM Loss

• بعضی VMها سالم هستند

• برخی orphan شده‌اند

 احتمال: metadata inconsistency

3. اقدامات فوری 

مرحله 1: Freeze کامل سیستم

• توقف Write روی Storage

• جلوگیری از reboot اضافی

• عدم اجرای Jobهای Backup

مرحله 2: جداسازی Host آسیب‌دیده

• Disconnect کردن ESXi از Cluster

• جلوگیری از Auto-Recovery actions

مرحله 3: بررسی Storage Layer

VMware معمولاً روی یکی از این‌ها اجرا می‌شود:

• RAID Hardware

• ZFS

• SAN / NAS

 اگر Storage خراب باشد، اول باید Storage ریکاوری شود نه VM

4. تحلیل Datastore

اگر VMFS/NFS سالم باشد:

• امکان recover مستقیم VMDK وجود دارد

• VM قابل re-register است

اگر Datastore corrupted باشد:

• نیاز به block-level recovery

• استخراج VMDK از image خام

5. بررسی Snapshot Chain (Critical)

Snapshot در VMware یک زنجیره وابسته است:

• base disk

• delta files

• redo logs

علائم خرابی:

• Cannot open disk

• Parent missing

• Snapshot consolidation failed

در این حالت، حذف اشتباه یک فایل کوچک = از دست رفتن کل VM

6. بازیابی ماشین‌های مجازی (VM Recovery)

روش استاندارد:

1. استخراج VMDK سالم

2. بازسازی descriptor file

3. attach کردن disk به VM جدید

4. بررسی consistency سیستم عامل

روش پیشرفته (Disaster Recovery):

• reconstruction از block-level image

• rebuild virtual disk chain

• forensic recovery از datastore

7. سناریوی خرابی Storage Backend

اگر VMware روی این‌ها اجرا شده باشد:

• RAID خراب

• ZFS pool faulted

• SAN disconnected

 ابتدا باید Storage Recovery انجام شود

بعد از آن:

• VM recovery

• Datastore reconstruction

8. بازیابی دیتابیس‌های حیاتی داخل VM

SQL Server:

• MDF / LDF repair

• transaction log recovery

MySQL:

• InnoDB recovery

• binlog replay

Oracle:

• datafile rebuild

• redo log recovery

9. اشتباهات مرگبار در Emergency VMware Recovery

 نصب مجدد ESXi روی همان دیسک‌ها

 اجرای Storage Reformat
 

Mount Force Datastore

 Delete Snapshot برای “free space”

 استفاده از ابزارهای غیرتخصصی ریکاوری

 روشن کردن VM بدون بررسی disk chain

10. تصمیم سریع (Decision Tree)

آیا Datastore قابل مشاهده است؟

• بله → VM recovery مستقیم

• خیر → Storage recovery

آیا VMDK سالم است؟

• بله → re-register VM

• خیر → reconstruction لازم

آیا Storage backend سالم است؟

• بله → سریع‌ترین ریکاوری

• خیر → multi-layer recovery (RAID/ZFS + VM)

11. زمان‌بندی ریکاوری اضطراری

• خرابی ساده VM: 1 تا 3 روز

• خرابی Datastore: 3 تا 7 روز

• خرابی Storage backend: 7 تا 14 روز

• Disaster multi-layer: 14 روز+

12. اصول طلایی دیتاسنتر

 همیشه snapshot policy فعال باشد

 backup خارج از cluster نگهداری شود

storage redundancy واقعی داشته باشید

 از write مستقیم روی datastore خراب جلوگیری کنید

 قبل از هر اقدام، clone بگیرید

13. جمع‌بندی

در خرابی VMware، مشکل واقعی همیشه VM نیست؛
بلکه معمولاً در یکی از این لایه‌هاست:

• Storage Backend

• Datastore

• Snapshot Chain

• VM Disk Layer

بنابراین بازیابی صحیح باید از پایین‌ترین لایه (Storage) شروع شود نه از VM

14. نتیجه حرفه‌ای

اگر زیرساخت شما دچار خرابی شده:

 اولین اقدام ، توقف کامل سیستم
 دوم ، تحلیل Storage
 سوم ، استخراج VM به‌صورت ایزوله

این ترتیب، تفاوت بین ریکاوری کامل و از دست رفتن دائمی داده‌ها است.