بازیابی اطلاعات VMFS در ESXi
ریکاوری VMware Datastore
بازیابی VMFS در ESXi
بازیابی اطلاعات در محیط VMware ESXi یکی از حساسترین عملیاتهای دیتاسنتر است، بهخصوص زمانی که فایلسیستم VMFS (Virtual Machine File System) دچار خرابی یا عدم دسترسی شود.
VMFS فایلسیستمی است که برای ذخیره ماشینهای مجازی، دیسکهای VMDK و Snapshotها در VMware استفاده میشود و خرابی آن معمولاً به معنی از دست رفتن همزمان چندین ماشین مجازی است.
VMFS چیست ؟
VMFS فایلسیستم اختصاصی VMware برای ذخیرهسازی Datastore است که روی Storageهایی مثل:
RAID
SAN / NAS
Local SSD / HDD
Storage مبتنی بر ZFS
پیادهسازی میشود.
تمام فایلهای حیاتی VMware در VMFS ذخیره میشوند:
VMDK (دیسک ماشین مجازی)
VMX (کانفیگ VM)
Snapshot files
Log files
دلایل خرابی VMFS در ESXi
1. خرابی Storage Backend
RAID failure
SAN disconnect
corruption در ZFS pool
قطع ناگهانی دیسکها
2. خرابی Metadata VMFS
آسیب به file system headers
corruption در volume descriptors
inconsistency در block allocation
3. حذف یا Unmount اشتباه Datastore
Remove شدن Datastore از ESXi
rescan ناقص storage
reformat اشتباهی volume
4. خرابی Host ESXi
crash در hypervisor
power failure
corruption در bootbank
5. خطای انسانی
delete datastore
initialize disk اشتباه
overwrite کردن VMFS volume
علائم خرابی VMFS
Datastore Not Accessible
VMFS Volume Missing
VMDK not found
VM shows orphaned state
I/O error on datastore
ESXi cannot mount volume
این علائم معمولاً نشاندهنده خرابی سطح پایین Storage هستند.
ساختار VMFS و اهمیت آن در ریکاوری
VMFS برخلاف فایلسیستمهای معمولی:
Cluster-based است
برای concurrency چند ESXi طراحی شده
metadata پیچیده دارد
وابسته به block-level storage است
به همین دلیل، ریکاوری VMFS معمولاً file-level نیست بلکه block-level forensic recovery است.
مراحل حرفهای بازیابی VMFS در ESXi
1. توقف کامل عملیات (Critical First Step)
توقف تمام VMها
جلوگیری از write جدید
قطع دسترسی ESXi به datastore آسیبدیده
2. بررسی Storage Layer
قبل از VMFS باید Storage بررسی شود:
RAID health
SAN connectivity
disk failure
ZFS pool status
اگر Storage خراب باشد، VMFS قابل ریکاوری مستقیم نیست.
3. Disk Imaging (حیاتی)
تهیه clone سکتور به سکتور
جلوگیری از overwrite
کار روی نسخه image شده
4. تحلیل VMFS Metadata
بررسی volume headers
بررسی block allocation
reconstruction ساختار datastore
5. بازیابی VMDKها
استخراج فایلهای دیسک
rebuild descriptor files
attach به VM جدید
6. بازسازی ماشینهای مجازی
re-register VM در ESXi
rebuild VMX configuration
تست boot در محیط ایزوله
سناریوهای پیشرفته خرابی VMFS
1. VMFS Corruption کامل
datastore raw شده
volume unmount شده
نیاز به forensic recovery
2. RAID Failure
loss of multiple disks
inconsistency در block mapping
نیاز به reconstruction RAID
3. ZFS Backend Failure
اگر VMFS روی Storage مبتنی بر ZFS باشد:
pool faulted
vdev missing
metadata corruption
4. Snapshot Chain Damage
missing delta disks
corrupted VMDK chain
VM non-bootable state
اشتباهات مرگبار در VMFS Recovery
- اجرای format روی datastore
- rescan بدون تحلیل
- mount force volume
- delete کردن VMFS partition
- rebuild RAID بدون image
- copy کردن فایلها روی storage خراب
این اقدامات معمولاً باعث از بین رفتن دائمی data blocks میشوند.
بازیابی VMDK در VMFS
VMDKها مهمترین دارایی VMFS هستند:
حالت سالم:
قابل mount مستقیم
attach به VM جدید
حالت خراب:
نیاز به reconstruction descriptor
rebuild chain snapshot
forensic carving از datastore
زمانبندی بازیابی VMFS
خرابی ساده: 1 تا 3 روز
خرابی متوسط: 3 تا 7 روز
خرابی پیچیده (RAID/Storage): 7 تا 14 روز
Disaster recovery کامل: 14+ روز
هزینه بازیابی VMFS
هزینه وابسته است به:
میزان خرابی datastore
تعداد VMها
نوع storage backend
وضعیت RAID / ZFS
حجم VMDKها
ارزیابی اولیه معمولاً بدون هزینه انجام میشود.
جمعبندی نهایی
بازیابی VMFS در ESXi یک فرآیند چندلایه است که شامل:
Storage layer (RAID / SAN / ZFS)
File system layer (VMFS)
VM layer (VMDK / VMX)
ترتیب صحیح ریکاوری:
Storage → VMFS → VMDK → VM
نتیجه حرفهای
در خرابی VMFS:
مشکل واقعی تقریباً همیشه در Storage backend است، نه خود VMFS
بنابراین موفقیت ریکاوری وابسته به:
توقف سریع سیستم
Thin و Thick چیست؟
اصطلاح «درایو مجازی Thin و Thick» معمولاً در محیطهای مجازیسازی (مثل VMware ESXi) برای نوع تخصیص فضای دیسکهای مجازی (VMDK) استفاده میشود. این موضوع مستقیم روی عملکرد، مصرف Storage و حتی سناریوهای ریکاوری تأثیر دارد.
درایو مجازی Thin و Thick چیست؟
در محیطهای مجازیسازی، وقتی یک دیسک مجازی (Virtual Disk) برای ماشین مجازی ساخته میشود، دو مدل اصلی تخصیص فضا داریم:
- Thin Provisioning (دیسک Thin)
- Thick Provisioning (دیسک Thick)
1. دیسک Thin (Thin Provisioned Disk)
تعریف:
در دیسک Thin، فضای ذخیرهسازی فقط به اندازه داده واقعی مصرف میشود، نه کل ظرفیت تعیینشده.
مثلاً:
- دیسک 500GB ساخته میشود
- ولی فقط 50GB داده داخل آن است
فقط همان 50GB روی Storage اشغال میشود
مزایا:
- صرفهجویی در فضای Storage
- استفاده بهینه از منابع
- مناسب برای محیطهای Cloud و Multi-VM
معایب:
- ریسک پر شدن ناگهانی Storage
- افت عملکرد در رشد ناگهانی داده
- پیچیدگی در مانیتورینگ ظرفیت
ریسک در ریکاوری:
- احتمال corruption در صورت full شدن datastore
- وابستگی به metadata allocation
- حساس به crash در Storage backend
2. دیسک Thick (Thick Provisioned Disk)
تعریف:
در دیسک Thick، کل فضای دیسک از ابتدا به VM اختصاص داده میشود.
مثلاً:
- دیسک 500GB ساخته میشود
همان 500GB از Storage اشغال میشود حتی اگر استفاده نشود
انواع Thick در VMware:
1. Thick Lazy Zeroed
- فضا رزرو میشود
- صفرسازی هنگام استفاده انجام میشود
2. Thick Eager Zeroed
- کل فضا از ابتدا zero میشود
- مناسب برای performance بالا (مثل دیتابیس)
مزایا:
- عملکرد پایدارتر
- ریسک کمتر fragmentation
- مناسب برای دیتابیس و workload سنگین
معایب:
- مصرف زیاد Storage
- زمان ساخت بیشتر
- انعطاف کمتر
ریسک در ریکاوری:
- معمولاً پایدارتر از Thin
- corruption کمتر در allocation
- اما در خرابی RAID/ZFS همچنان حساس است
تفاوت Thin و Thick در ریکاوری اطلاعات
Thin Disk Recovery:
- نیاز به تحلیل allocation map
- احتمال “missing blocks” بیشتر
- وابستگی شدید به metadata
Thick Disk Recovery:
- ساختار سادهتر
- دادهها continuous هستند
- forensic recovery راحتتر
مقایسه سریع Thin vs Thick
| ویژگی | Thin | Thick |
|---|---|---|
| مصرف Storage | کم | زیاد |
| Performance | متغیر | پایدار |
| ریسک پر شدن | بالا | پایین |
| پیچیدگی ریکاوری | بیشتر | کمتر |
| مناسب | Cloud / VDI | Database / Production |
نقش در VMware و VMFS
در محیط VMware vSphere و فایلسیستم VMFS:
- Thin و Thick هر دو داخل VMDK ذخیره میشوند
- نوع provisioning روی layout دیسک تأثیر دارد
- در خرابی Storage، Thin معمولاً حساستر است
اشتباهات رایج در استفاده Thin و Thick
- استفاده از Thin بدون monitoring
- استفاده از Thick برای محیطهای غیرضروری (اتلاف Storage)
- عدم توجه به datastore capacity
- اجرای VMهای سنگین روی Thin بدون کنترل رشد
جمعبندی
- Thin = بهینه برای فضا، حساستر در خرابی
- Thick = پایدارتر، سنگینتر از نظر Storage
- انتخاب درست کاملاً به نوع workload بستگی دارد
در سناریوهای ریکاوری:
Thick معمولاً قابل پیشبینیتر و Thin پیچیدهتر است
بازیابی اطلاعات ESXi
مجازی سازی پیچیدگی های عملیات بازیابی اطلاعات را بیشتر می کند. هنگامیکه نیاز به بازیابی اطلاعات از یک سیستم مجازی مانند VMware دارید، بهتر است برای این کار افرادی که تجربه و سابقه کار لازم را دارند انتخاب کنید. مهندسین متخصص بازیابی اطلاعات ما بیش از 1000 مورد بازیابی اطلاعات سیستم های مجازی را با موفقیت به انجام رسانده اند.
مهندسین “ویرا رسانه افزار” با دسترسی به ابزارهای تخصصی و اتكا به تجربه و دانش روز دنیا میتوانند هر آرایه RAID یا سرور مجازی را درمان و بازیابی نمایند.
با ما تماس بگیرید : 3-88974672 مشکل خود را بگویید و مشاوره رایگان دریافت نمایید.
آیا شما از آخرین نسخه VMware استفاده می کنید و نیاز به بازیابی اطلاعات دارید؟ تیم مهندسین ما به دقت و به صورت تخصصی (حرفه ای) با VMware یا روی ماشین های مجازی کار می کنند و با توجه به ساختار VM ها و همچنین مهندسی معکوس عملکرد VM ها اقدام به بازیابی های موفق در این مورد پرداخته اند و ابزارهایی را برای تسریع و بهبود نتیجه عملیات بازیابی این موارد تولید نموده اند.
بازیابی اطلاعات از تمامی مجازی سازها :
ویرا رسانه افزار متخصصان و کارشناسان بازیابی اطلاعات هستند که موفقیت در بازیابی اطلاعات ماشین مجازی ، سرور یا سیستم شامل موارد ذیل را برای شما در دسترس تر و نزدیکتر می کنند :
• زیر ساخت های مجازی : VMware ، Citrix ، Linux XEN ، Oracle VM
• فایل سیستم های مجازی: HFS، EXTS ، FAT ، NTFS ، VMFS و غیره
• برای دریافت لیست کامل سیستم ها و انواع فایل های قابل بازیابی با ما تماس بگیرید : 3-88974672
رایج ترین عوامل از دست رفتن اطلاعات در سیستم های مجازی :
• فرمت مجدد VMware
• خرابی فایل های دیسک مجازی ( VMDK )
• خرابی ولوم های VMFS
• پاک شدن فایل های دیسک مجازی ( VMDK )
• معیوب شدن فایل سیستم
• ایرادات فیزیکی
نکاتی برای سناریوهای رایج در بازیابی اطلاعات VMware :
1. پاک شدن یا از دست رفتن ماشین مجازی VMDK
2. معیوب شدن VMFS Metadata یا از دسترس خارج شدن Datastore
3. خرابی مکانیکی به وجود آمده در Storage/RAID
4. ایراد در سیستم عامل داخلی
1- پاک شدن یا از دست رفتن ماشین مجازی VMDK
اگر با مشکل از دست دادن اطلاعات برخورد کرده اید ، ابتدا هرگونه اطلاعاتی که درباره ماشین مجازی پاک شده یا گم شده دارید ثبت کنید. داده های مربوط شامل: اندازه (سایز) دیسک مجازی ، Thin یا Thick بودن VM ، نام ماشین مجازی ، فایل سیستم داخلی و نوع داده های موجود.
در اقدام بعدی ، تا حد امکان عملیات خواندن و نوشتن در Datastore آسیب دیده را کاهش دهید. اگر Datastore شامل ماشین های مجازی Thin فعال می باشد حتما در اسرع وقت آنها را خاموش کنید. بنابراین قبل از اینکه ماشین های مجازی فعال یا Data Store آسیب دیده را جابجا یا ذخیره کنید با یک فرد متخصص در بازیابی اطلاعات صحبت کنید. شما ممکن است ناخواسته پیچیدگی های بازیابی اطلاعات VMware را افزایش و همینطور شانس بازیابی اطلاعات را کاهش دهید.
در مواردی که Snapshots یک VM از دست رفته یا پاک شده است ، آن را روشن نکنید. و اگر ماشین (دستگاه) درحال کارکردن است ، در اسرع وقت آن را خاموش کنید.
2- معیوب شدن VMFS Metadata یا از دسترس خارج شدن Datastore
برای کم کردن مشکلات ، هرگز سعی نکنید یک Data Store جدید ایجاد کنید و اگر در حال جستجو کردن LUN خودتان هستید ، مطمئن شوید که دسترسی شما به صورت Read only باشد.
3- خرابی مکانیکی به وجود آمده در Storage/RAID
هرگز یک درایو Fail را با یک درایوی که قسمتی از یک سیستم RAID قبلی است جایگزین نکنید.
همیشه قبل از جایگزینی یک درایو ابتدا آن را Zero و سپس از آن استفاده می نماییم. اگر درایو صداهای مکانیکی غیر معمول دارد، فورا آن را خاموش کنید و از متخصصین کمک بگیرید. در محیط سرور فیزیکی ، جدا کردن یک درایو با آسیب فیزیکی روشن (درحال استفاده) احتمال آسیب بیشتر را افزایش می دهد و بطور قابل توجهی شانس بازیابی کامل اطلاعات را کاهش می دهد.
نکته : قبل از اینکه هاردها را از سیستم جدا کنید ، روی دیسک ها با توجه به جایگاه دیسک ها در آرایه ی RAID ، روی دیسک برچسب بزنید.
اگر سیستم RAID وسط فرآیند بازسازی (Rebuild ) متوقف شود، سعی نکنید که مجددا عملیات بازسازی (Rebuild ) را اجرا کنید. هرگز ماشین های مجازی را به یک RAID و یا از یک RAID مشکوک جا به جا نکنید، و اگر نیاز به خاموش کردن و یا افزایش توان سخت افزار RAID دارید، قبل از آن مطمئن شوید همه ماشین های مجازی (VMS) و هاست های VMware به شکل صحیح خاموش شده باشند.
4- ایراد در سیستم عامل داخلی
زمانیکه OS داخلی ایراد دارد ابزارهای ترمیم Volume ( مانند ScanDisk – ChkDsk ) یا ابزارهای Defragment را در دیسک های مجازی خراب مشکوک اجرا نکنید زیرا این کار می تواند مشکلات را تشدید کند.
اگر متوجه شدید که بیشتر از یک ماشین مجازی دچار خرابی شده اند این موارد ممکن است اشاره به این مطلب باشد که یک مشکل در سطح Storage به وجود آمده است. در این صورت در اسرع وقت ماشین ها را خاموش کرده و از یک متخصص حرفه ای در بازیابی اطلاعات VMware مشاوره بگیرید.
فهرست مشتریان
تقدیر نامه های بازیابی اطلاعات VMware