مواجهه با لاگهای خطای بحرانی در محیط vSphere یا مشاهده وضعیت Degraded در نرمافزار HPE Smart Storage Administrator (SSA)، کابوس هر مدیر شبکهای است. در این شرایط دیتای حیاتی سازمان شما در مرز نابودی قرار دارد. زمانی که سرور شما با افت شدید I/O مواجه میشود یا کنترلر RAID هشدارهای فیزیکی صادر میکند، هر ثانیه تصمیمگیری اشتباه (مانند یک ریبوت ساده) میتواند خسارات جبرانناپذیری به بار آورد. این مقاله، برای تشخیص علائم خرابی سرور و متوقف کردن چرخه تخریب دادهها است.
اگر هماکنون با قطعی سرور یا خطای هارد درایوها مواجه هستید، ۳ گام زیر را فوراً اجرا کنید:
- سرور را خاموش کنید: از طریق iLO یا به صورت فیزیکی سرور را Power Off کنید تا از بازنویسی دادهها (Overwriting) جلوگیری شود.
- عملیات Rebuild را متوقف کنید: به هیچوجه هارد جدیدی را در وضعیت Degraded وارد مدار نکنید و دستور chkdsk را اجرا نکنید.
- لاگها را استخراج کنید: لاگهای Active Health System (AHS) را از iLO دانلود کرده و با یک متخصص ریکاوری تماس بگیرید.
فهرست موضوعات
بررسی علائم خرابی سرور
خرابی سرور همیشه با سکوت مطلق همراه نیست؛ گاهی با هشدارهایی ظاهر میشود که درصورت نادیده گرفته شدن اتفاقات فاجعهباری رخ میدهد.
شنیدن صداهای غیرعادی (Clicking) از کیس سرور
صدای “کلیککلیک” از هارد دیسکها به معنای شکست فیزیکی هد یا خرابی موتور درایو است. این صدا، آخرین اخطار سختافزار قبل از نابودی کامل اطلاعات است.
پیغامهای خطای I/O در کنسول مدیریت سرور
خطاهای Input/Output نشاندهنده ناتوانی سرور در خواندن یا نوشتن دادهها روی مدیای ذخیرهسازی است که اغلب خبر از بدسکتورهای گسترده یا خرابی کنترلر میدهد.
بالا نیامدن سیستمعامل (Boot Failure) یا گیر کردن در مرحله POST
اگر سرور در مرحله POST متوقف میشود، احتمالاً سیستمعامل نمیتواند آرایه RAID یا درایو بوت را شناسایی کند. دستکاری تنظیمات بایوس در این مرحله بدون دانش فنی، ریسک شکست ریکاوری را دوچندان میکند.
جدول عیبیابی سریع سرور (Diagnostic Table)
برای تشخیص اینکه با یک خرابی منطقی روبهرو هستید یا فیزیکی، از جدول زیر استفاده کنید:
| نشانه (Symptom) | علت احتمالی (Probable Cause) | اقدام اورژانسی (Emergency Action) |
|---|---|---|
| صدای کلیک مستمر از دیسکها | خرابی فیزیکی هد یا موتور هارد (Mechanical Failure) | فوراً سرور را خاموش کرده و هارد را از مدار خارج کنید. |
| خطای صفحه آبی (BSOD) یا Kernel Panic | اختلال در فایلسیستم یا خرابی رم/کنترلر | بررسی لاگهای iLO و عدم اجرای ابزارهای تعمیر خودکار ویندوز/لینوکس. |
| افت شدید و ناگهانی سرعت I/O در ماشینهای مجازی | وجود Bad Sector گسترده یا خرابی کش کنترلر | متوقف کردن سرویسهای سنگین دیتابیس و انتقال اضطراری دیتا (اگر امکانپذیر است). |
| سرور بالا میآید اما درایوهای دیتا (LUNs) Mount نمیشوند | از دست رفتن کانفیگ RAID یا خرابی فایلسیستم VMFS/NTFS | از ایجاد LUN جدید یا فرمت کردن درایوها اکیداً خودداری کنید. به آموزش بازگردانی اطلاعات سرور در منزل مراجعه کنید. |
سرور بالا میآید ولی اطلاعات نیست؛ چرا با چنین وضعیتی مواجه میشویم؟
یکی از گیجکنندهترین اتفاق ها برای مدیران شبکه زمانی است که سیستمعامل (Host OS یا Hypervisor) بدون مشکل بوت میشود، اما LUNها، Datastoreها یا درایوهای حاوی اطلاعات کاربران Mount نمیشوند. این وضعیت معمولاً ریشه در ۳ عامل کلیدی دارد:
۱. خرابی فیزیکی کنترلر RAID و از دست رفتن کانفیگ
کنترلرهای سختافزاری برای افزایش سرعت I/O از حافظه کش (Write-Back Cache) استفاده میکنند. اگر باتری کنترلر (مانند HPE Smart Storage Battery) از کار بیفتد یا خود چیپست کنترلر دچار اختلال شود، دیتای موجود در کش پیش از نوشته شدن روی دیسکها از بین میرود. در این حالت، آرایه RAID اصطلاحاً کانفیگ خود را گم میکند (Foreign Configuration) و سیستمعامل دیسکها را به عنوان فضای خام (RAW) یا Unallocated میشناسد.
هشدار: در این سناریو، اجرای دستور Clear Configuration یا ساخت مجدد آرایه با همان تنظیمات قبلی، باعث بازنویسی سکتورهای حیاتی شده و فاجعه به بار میآورد.
۲. اختلال در فایلسیستم و جداول پارتیشن (Logical Corruption)
قطع ناگهانی برق، ریستهای سختافزاری متوالی (Hard Reset) یا باگهای کرنل میتواند باعث تخریب جداول پارتیشن (MFT در ویندوز یا Superblock در لینوکس و VMFS) شود. در این حالت، دیسکها از نظر فیزیکی کاملاً سالم هستند، اما ساختار آدرسدهی فایلها فرو ریخته است.
۳. تخریب منطقی دیتابیسها
گاهی اوقات مشکل در لایه نرمافزار رخ میدهد. افت شدید سرعت خواندن/نوشتن (I/O Bottleneck) به دلیل وجود بدسکتور روی یکی از هاردهای آرایه RAID 5 یا RAID 10، باعث میشود دیتابیسهایی نظیر SQL Server یا Oracle دچار Time-out شوند. در این وضعیت، فایلهای دیتابیس (.mdf یا .ldf) با برچسب Suspect مارک شده و دیتابیس متوقف میشود.
کدهای خطای سرورهای HPE در مرحله POST، مستقیماً به ریشه مشکل اشاره دارند. در جدول زیر، لینکهای دسترسی سریع به مقالات تخصصی رفع خطاهای خانواده ProLiant گردآوری شده است تا در کمترین زمان ممکن مشکل سرور خود را عیبیابی کنید:
| دستهبندی خطا | عنوان مقاله و لینک دسترسی |
|---|---|
| سری 100 | چرا سرور HP ما روی خطای 100 گیر کرده؟ |
| سری 200 | کدهای خطای 200 سرور HP: تشخیص فوری و رفع قطعی ارورهای بوت |
| سری 300 | راهنمای رفع خطاهای سری 300 سرور HP |
| سری 400 | لیست کدهای خطای سری 400 سرور hp و روشهای سریع رفع آنها |
| سری 500 | لیست کدهای خطای سری 500 سرور hp و روشهای عملی رفع آنها |
| سری 1700 | لیست کامل خطاهای سری 1700 سرور hp (خطاهای کنترلر دیسک و RAID) |
اقدامات حیاتی بعد از مشاهده نشانههای از دست رفتن اطلاعات سرور
چرا ریست کردن مکرر سرور، قاتل اطلاعات شماست؟
هر بار که سرور را ریست میکنید، سیستمعامل سعی میکند بخشهای آسیبدیده را بازسازی یا “اصلاح” کند. این اقدام روی دیسکهای خراب، باعث نوشتن دادههای جدید روی سکتورهای در حال مرگ و نابودی شانس بازیابی آنها خواهد شد.
بر اساس تجربه تیم تخصصی ما در بررسی لاگهای سرورهای آسیبدیده، در بیش از 80% پروژههای ریکاوری سرور که در ماههای اخیر ارجاع داده شده است، بزرگترین اشتباه ادمینها، تلاش برای Rebuild کردن کورکورانه آرایه RAID بوده است.
مثال: در سرورهای HPE با کنترلر Smart Array (مانند مدل P408i-a)، اگر خطای 1716 (Unrecoverable Media Errors Detected) را دریافت کردید و چراغهای Amber روی درایوها روشن شد، ریبوت کردن سرور باعث بههمریختگی کامل Parity در آرایه RAID 5 یا RAID 6 میشود. این کار شانس موفقیت [ریکاوری و بازیابی اطلاعات NAS Storage] یا سرور را به زیر 20% کاهش میدهد.
بررسی سلامت سختافزار و ضرورت خرید سرور HP
بسیاری از خرابیها ناشی از فرسودگی قطعات است. بهترین راه مانیتورینگ سلامت دیسکها برای پیشگیری از خرابی و آگاهی به موقع از خرابیها است. اما در صورت نیاز [خرید سرور HP] با استانداردهای جدید و گارانتی معتبر، ریسک خرابیهای ناگهانی را به حداقل میرساند.
فرآیند کار بازیابی اطلاعات سرور بعد از خرابی چگونه است؟
گامهای اولیه برای عیبیابی بدون آسیب به دادهها
اولین گام، گرفتن ایمیج کلون (Clone) از دیسکها در محیطی امن است. هرگونه تست و عیبیابی باید فقط روی کپی دادهها انجام شود، نه دیسک اصلی.
- Clone کردن سکتور به سکتور: هیچ متخصص حرفهای هرگز روی هاردهای اصلی سرور شما کار نرمافزاری انجام نمیدهد. ابتدا تمامی درایوها (حتی درایوهای سالم) با استفاده از تجهیزات تخصصی مانند دستگاههای سختافزاری PC-3000 کپی (Image) گرفته میشوند.
- آنالیز هگزادسیمال (Hex Analysis): متخصصان با بررسی کدهای هگزادسیمال، پارامترهای گمشده RAID (مانند Block Size، Parity Delay و ترتیب درایوها) را به صورت دستی محاسبه و شبیهسازی میکنند.
- جراحی هارد دیسک (در صورت نیاز): اگر هاردهای SAS یا Enterprise دچار خرابی هد یا موتور شده باشند، در محیط ایزوله کلینروم (Clean Room کلاس 100) برای استخراج موقت دیتا انجام میشود.
چه زمانی باید کار را به متخصص سپرد؟
اگر دادههای شما برای کسبوکار حیاتی هستند یا با خطاهای RAID مواجه شدهاید، هیچگونه آزمون و خطایی را نپذیرید. استفاده از [خدمات تخصصی ریکاوری اطلاعات سرور] تنها راهی است که ریسک نابودی دائمی اطلاعات را به صفر میرساند.
جمعبندی
نادیده گرفتن علائم خرابی سرور، از صداهای غیرعادی فن و دیسک گرفته تا خطاهای I/O در ماشینهای مجازی، قماری است که همیشه سازمان شما در آن بازنده خواهد بود. وقتی با وضعیت بحرانی روبرو میشوید، «دستکاری نکردن» ارزشمندترین اقدامی است که یک مدیر شبکه میتواند انجام دهد. سیستم را خاموش کنید، لاگها را جمعآوری کنید و سرنوشت دادههای حیاتی سازمان را به ابزارهای تعمیر خودکار ویندوز نسپارید.
سوالات متداول درباره خرابی سرور و بازیابی اطلاعات
✔ آیا بعد از شنیدن صدای تقتق از سرور، همچنان امکان ریکاوری وجود دارد؟
بله، اما به شرطی که بلافاصله سرور خاموش شود و در محیط کلینروم توسط متخصص بررسی شود.
✔ در صورت خرابی RAID، آیا جابهجا کردن هاردها باعث تخریب بیشتر میشود؟
بله، جابهجایی هاردها میتواند ترتیب آرایه را به هم ریخته و فرآیند ریکاوری را غیرممکن کند.
✔ تفاوت خرابی پاور سرور با خرابی هارد در چیست؟
خرابی پاور معمولاً باعث خاموشی ناگهانی میشود که میتواند منجر به فساد فایلسیستم شود، اما خرابی هارد علائم محیطی و منطقی خاص خود را دارد.
✔ آیا میتوان با نرمافزارهای ریکاوری رایگان اطلاعات سرور را برگرداند؟
خیر. نرمافزارهای رایگان معمولاً قادر به درک ساختار پیچیده Parity در کنترلرهای سختافزاری نیستند. اسکن کردن هاردهای سرور با این نرمافزارها تنها باعث فشار مضاعف به دیسکها و کاهش شانس بازیابی توسط لابراتوارهای تخصصی میشود.
✔ چقدر زمان برای بازیابی اطلاعات پس از خرابی سرور داریم؟
زمان عامل تعیینکنندهای نیست، بلکه “اقدامات انجام شده بعد از خرابی” تعیینکننده موفقیت در ریکاوری است.