وقتی سرور از دسترس خارج می شود، از کجا شروع کنیم؟

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

1. دامنه حادثه را مشخص کنید: همه سرویس ها قطع شده اند یا فقط یک برنامه؟ وضعیت کنسول، شبکه و استوریج چیست؟
2. نوشتن غیرضروری را متوقف کنید: اگر حذف، خرابی منطقی یا اختلال آرایه محتمل است، اجازه ندهید برنامه ها همچنان روی همان فضای آسیب دیده داده تولید کنند.
3. شواهد را ثبت کنید: از پیام خطا، چراغ ها، وضعیت کنترلر و زمان رخداد عکس یا یادداشت تهیه کنید، بدون اجرای تست سنگین.
4. سوابق اخیر را جمع کنید: تعویض دیسک، قطعی برق، تغییر تنظیمات، به روزرسانی یا اجرای Rebuild را ثبت کنید.
5. نسخه پشتیبان را بررسی کنید: وجود فایل بک آپ کافی نیست؛ سلامت، تاریخ و امکان بازگردانی آن اهمیت دارد.
6. یک مسئول تصمیم گیری تعیین کنید: ورود همزمان چند نفر و اجرای دستورهای مختلف می تواند تشخیص را دشوار کند.

آیا باید سرور را بلافاصله خاموش کرد؟

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

اما در رخداد امنیتی، خاموش کردن فوری ممکن است شواهد موجود در حافظه موقت را از بین ببرد. در این حالت، مهار ارتباطات و تصمیم درباره خاموشی باید با هماهنگی تیم پاسخ به رخداد انجام شود. نسخه واحد «همیشه خاموش کنید» یا «همیشه روشن نگه دارید» برای همه خرابی ها مناسب نیست.

چرا ریستارت مکرر و Rebuild بدون بررسی خطرناک است؟

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

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

Rebuild چه زمانی مفید و چه زمانی پرخطر است؟

Rebuild در یک آرایه سالم از نظر ساختار، پس از خرابی یک عضو و در محدوده تحمل خطای همان RAID، بخشی از فرایند معمول نگهداری است. اما اگر چند دیسک مشکل دارند، اعضا به اشتباه شناسایی شده اند یا وضعیت آرایه روشن نیست، شروع Rebuild می تواند خطر از دست رفتن داده یا پیچیده شدن بازیابی را افزایش دهد.

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

در وضعیت نامشخص، از این اقدامات خودداری کنید:

• ساخت آرایه جدید روی دیسک های قبلی.
• اجرای Initialize یا فرمت برای رفع خطا.
• اجبار یک عضو مشکوک به Online شدن.
• پذیرفتن یا پاک کردن تنظیمات Foreign بدون تحلیل.
• اجرای ابزار تعمیر فایل سیستم روی تنها نسخه موجود.

چگونه دیسک های سرور را ثبت و شماره گذاری کنیم؟

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

برای هر دیسک این موارد را ثبت کنید:

• شناسه سرور یا محفظه ذخیره سازی.
• شماره شاسی و اسلات.
• مدل، ظرفیت و شماره سریال.
• وضعیت گزارش شده مانند Online، Failed یا Hot Spare.
• زمان و ترتیب خارج کردن.

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

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

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

آیا بازیابی سرور در بندرعباس انجام می شود یا باید تجهیزات ارسال شوند؟

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

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

کلین روم برای چه کاری لازم است؟

باز کردن محفظه یک هارد دیسک مکانیکی باید در محیط مناسب با کنترل آلودگی ذره ای انجام شود. این محیط می تواند اتاق تمیز یا ایستگاه کار کنترل شده و متناسب با عملیات باشد.

عنوان هایی مانند «کلاس ۱۰۰» یا «ISO Class ۵» بدون توضیح محدوده، شرایط آزمون و مستندات، برای ارزیابی کافی نیستند. محیط تمیز نیز به معنای نبود مطلق هرگونه ذره نیست.

همه خرابی های سخت افزاری نیازمند باز کردن محفظه نیستند. ایراد برد یا تغذیه ممکن است مسیر دیگری داشته باشد و در بعضی مدل ها، انتقال یا بازیابی اطلاعات اختصاصی برد لازم است. SSD و NVMe نیز اجزای مکانیکی هارد دیسک را ندارند و به روش های متفاوتی نیاز دارند.

شرایط محیطی بندرعباس چه اهمیتی دارد؟

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

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

چگونه مرکز مناسب بازیابی اطلاعات سرور را انتخاب کنیم؟

نام برند ابزار یا تعداد تبلیغات، به تنهایی معیار قابل اتکایی نیست. از مجری بخواهید روش کار، حدود توانایی و مسئولیت خود را روشن کند.

آیا داشتن PC-۳۰۰۰ شرط کافی برای اعتبار است؟

خیر. ابزارهای تخصصی می توانند مفید باشند، اما توانایی آن ها به مدل، رابط، ماژول و نوع خرابی بستگی دارد. داشتن یک ابزار مشخص، مهارت مجری را ثابت نمی کند و نداشتن آن نیز به تنهایی اثبات واسطه بودن نیست.

برای دیسک های SAS، SSD، NVMe، آرایه های پیچیده و استوریج های اختصاصی، ترکیب تجهیزات، دانش و روش کار اهمیت دارد. پرسش بهتر این است: «برای همین مدل رسانه و همین نوع خرابی، چه مسیر فنی قابل توضیحی دارید؟»

ارسال امن هاردهای سرور و حفاظت از اطلاعات

1. پس از هماهنگی با مرکز، فهرست مدل و شماره سریال رسانه ها را تهیه کنید.
2. هر رسانه را جداگانه در بسته ضد الکتریسیته ساکن مناسب قرار دهید.
3. از ضربه گیر مناسب و جعبه مقاوم استفاده کنید تا رسانه ها حرکت نکنند یا با هم تماس نداشته باشند.
4. برچسب چیدمان و شناسه پرونده را خوانا نگه دارید.
5. روش حمل قابل رهگیری، رسید تحویل و شرایط مسئولیت خسارت را بررسی کنید.
6. اطلاعات تماس و شرح خرابی را جدا از رسانه قرار دهید؛ رمزها را روی جعبه ننویسید.

اگر رسانه خیس شده یا در معرض آب شور قرار گرفته است، آن را روشن نکنید و پیش از خشک کردن، تمیزکاری یا بسته بندی از متخصص راهنمایی بگیرید. دستور نگهداری رسانه آسیب دیده ممکن است با یک دیسک خشک متفاوت باشد.

NDA چه نقشی دارد؟

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

قرارداد بهتر است محدوده کپی مجاز، هدف پردازش، افراد دارای دسترسی، استفاده از پیمانکار، مدت نگهداری، نحوه حذف و مسئولیت رخداد امنیتی را روشن کند. امضای نماینده دارای اختیار و بررسی حقوقی متناسب با حساسیت داده نیز اهمیت دارد.

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

جدول هزینه بازیابی اطلاعات سرور در سال ۱۴۰۵

برای این مقاله، تعرفه رسمی یا قیمت روز قابل استناد از مراکز بندرعباس در اختیار نیست. بنابراین، درج بازه عددی به عنوان نرخ بازار ۱۴۰۵ می تواند گمراه کننده باشد. جدول زیر مشخص می کند پیش فاکتور باید چه اجزایی داشته باشد تا پیشنهادها قابل مقایسه شوند.

چه عواملی قیمت را تغییر می دهند؟

تعداد دیسک ها، وضعیت خواندن، نوع RAID، رمزگذاری، خرابی متادیتا، عملیات قبلی و حساسیت اعتبارسنجی در هزینه اثر دارند. ظرفیت به تنهایی کافی نیست؛ خواندن یک دیسک بزرگ سالم می تواند از تصویربرداری یک دیسک کوچک معیوب ساده تر باشد.

وجود Hot Spare به خودی خود به معنای پیچیدگی بیشتر نیست. مهم این است که آیا عضو یدکی وارد آرایه شده، Rebuild تا کجا پیش رفته و کدام دیسک ها آخرین داده معتبر را دارند.

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

بازیابی انواع سرور و استوریج چه تفاوتی دارد؟

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

در رسانه معیوب، تهیه ایمیج باید کنترل شده باشد. ممکن است متخصص ابتدا نواحی خواندنی یا داده های مهم تر را استخراج کند و سراغ بخش های دشوار برود؛ تصویربرداری کامل از همان ابتدا همیشه امن ترین یا ممکن ترین مسیر نیست.

VMware ESXi و Hyper-V

در مجازی سازی، چند لایه باید بررسی شوند: رسانه فیزیکی، آرایه، فضای ذخیره سازی میزبان، دیسک مجازی و فایل سیستم داخل مهمان.

Datastore به خودی خود «فضای ابری» نیست و می تواند محلی یا مشترک باشد. یک ماشین VMware نیز ممکن است علاوه بر VMDK، به فایل تنظیمات، چند دیسک و زنجیره Snapshot وابسته باشد. در Hyper-V، فایل های VHDX و دیسک های تفاضلی AVHDX می توانند درگیر باشند.

از ایجاد ماشین جدید، کپی داده یا ادغام Snapshot روی فضای آسیب دیده خودداری کنید. روشن شدن سیستم عامل مهمان نیز سلامت برنامه و دیتابیس داخل آن را ثابت نمی کند.

SQL Server، Oracle و سامانه های مالی

برگرداندن فایل دیتابیس، پایان کار نیست. سازگاری تراکنش ها، سلامت ساختار و امکان استفاده در برنامه باید بررسی شود.

• در SQL Server، فایل های داده، لاگ و زنجیره بک آپ اهمیت دارند.
• در Oracle، فایل های داده، کنترل، لاگ ها و تنظیمات بازیابی باید متناسب با معماری بررسی شوند.
• در نرم افزارهای مالی، نسخه برنامه، وابستگی ها و تایید مسئول مالی نیز ممکن است لازم باشد.

MDF و LDF نام فایل های متداول SQL Server هستند و نباید به Oracle تعمیم داده شوند. ترمیم دیتابیس هم همیشه به معنای ویرایش دستی کد هگز نیست؛ استفاده از بک آپ، لاگ و ابزارهای بومی معمولا باید پیش از روش های پرریسک بررسی شود.

NAS و SAN

تجهیزات QNAP، Synology و سامانه های سازمانی می توانند از ساختارها و فایل سیستم های متفاوتی استفاده کنند. مدل، نسخه سیستم عامل، نوع Pool، Snapshot، کش SSD و رمزگذاری در روش بازیابی اثر دارند.

در SAN ممکن است LUN، Thin Provisioning، گروه های دیسک و تنظیمات کنترلر هم لازم باشند. شبیه سازی یک سیستم عامل لینوکس، توضیح کافی برای همه پرونده های استوریج نیست.

اگر سرور باج افزاری شده است چه کنیم؟

باج افزار فقط مسئله ریکاوری فایل نیست؛ احتمال سرقت اطلاعات، سرقت حساب ها و باقی ماندن دسترسی مهاجم هم باید بررسی شود.

1. سیستم های درگیر را با هماهنگی تیم امنیت از شبکه جدا کنید.
2. بک آپ های سالم را از دسترسی محیط آلوده محافظت کنید.
3. یادداشت باج، پسوند فایل ها، زمان رخداد و لاگ های موجود را حفظ کنید.
4. پیش از پاک سازی، نصب مجدد یا خاموشی، نیاز به حفظ شواهد را ارزیابی کنید.
5. نوع باج افزار و وجود رمزگشای معتبر را بررسی کنید.
6. بازیابی را در محیط پاک و پس از مهار مسیر نفوذ انجام دهید.

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

پنج اشتباه پرخطر هنگام بازیابی اطلاعات سرور

انجام این اشتباهات می تواند هزینه زیادی رو برای شما متحمل شود.

۱. نصب ابزار ریکاوری روی همان فضای آسیب دیده

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

۲. اسکن سنگین رسانه ناپایدار

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

۳. اجرای تعمیر خودکار روی تنها نسخه

ابزار تعمیر ممکن است برای سازگار کردن فایل سیستم، بعضی ساختارها را تغییر دهد یا حذف کند. در داده حساس، این عملیات باید پس از حفظ نسخه مناسب و با شناخت پیامدها انجام شود.

۴. تعویض قطعه بدون بررسی سازگاری

شباهت مدل یا ظرفیت برای سازگاری برد، هد یا قطعه دهنده کافی نیست. اطلاعات اختصاصی، میان افزار و مشخصات داخلی هم ممکن است تعیین کننده باشند.

۵. پذیرش وعده قطعی یا شروع بدون قرارداد

عبارت هایی مانند «بازیابی صد درصد» یا «تحویل تضمینی در چند ساعت» پیش از تشخیص قابل اتکا نیستند. محدوده کار، هزینه، مجوز تغییر و معیار نتیجه باید ثبت شوند.

چه زمانی می توان بازیابی را موفق دانست؟

وجود نام فایل ها یا نمایش پوشه ها به تنهایی کافی نیست. پیش از شروع، فهرست داده های حیاتی را مشخص کنید؛ برای مثال دیتابیس مالی، اسناد بازه زمانی خاص یا یک ماشین مجازی مشخص.

معیار تحویل می تواند شامل این موارد باشد:

• گزارش فایل های سالم، ناقص و غیرقابل خواندن.
• بررسی نمونه فایل های مهم توسط نماینده مجاز مشتری.
• اعتبارسنجی دیتابیس و آزمون برنامه در محیط جداگانه.
• بررسی زنجیره دیسک های مجازی و Snapshot ها.
• تحویل روی رسانه سالم با روش انتقال مناسب.
• ثبت مهلت بررسی و زمان حذف نسخه های مرکز.

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

پس از بازیابی، چه ساختار پشتیبان گیری لازم است؟

قاعده ۳-۲-۱ نقطه شروع مناسبی است: سه نسخه از داده شامل نسخه اصلی و دو نسخه پشتیبان، روی دو نوع رسانه یا بستر با ریسک مستقل، و حداقل یک نسخه خارج از محل اصلی.

برای مقابله با باج افزار، نسخه آفلاین یا تغییرناپذیر، حساب مدیریتی جدا، محدودیت دسترسی و آزمون منظم بازگردانی اهمیت دارند. RAID و Snapshot به تنهایی جای بک آپ مستقل را نمی گیرند.

دو شاخص را نیز مشخص کنید:

• RPO: حداکثر فاصله زمانی داده ای که سازمان می تواند از دست بدهد.
• RTO: زمان هدف برای بازگشت سرویس.

برای یک سامانه حیاتی حمل، مالی یا انبار، داشتن نسخه پشتیبان بدون برنامه بازگردانی آزمایش شده ممکن است کافی نباشد.

سوالات متداول

در این بخش از ایران هارد به سوالات رایج شما عزیزان پاسخ کامل می دهیم. شما نیز اگر سوالی داشتید در بخش کامنت های سایت باما در ارتباط باشید.

بررسی اولیه چقدر زمان می برد؟

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

اگر اطلاعات بازیابی نشود، هزینه ای دریافت می شود؟

این موضوع قراردادی است. سیاست «عدم بازیابی، عدم دریافت دستمزد» ممکن است شامل بررسی، قطعه، حمل یا خدمات فوری نباشد. تعریف موفقیت و هزینه های غیرقابل استرداد باید پیش از شروع روشن شود.

آیا امکان انجام کار در محل شرکت یا محدوده بندری وجود دارد؟

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

هزینه قطعه دهنده بر عهده چه کسی است؟

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

اگر ترتیب دیسک ها فراموش شده باشد، ریکاوری ممکن است؟

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

آیا اطلاعات SSD یا NVMe حذف شده قابل بازیابی است؟

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

برای استعلام اولیه چه اطلاعاتی آماده کنیم؟

مدل سرور و کنترلر، تعداد و مدل دیسک ها، نوع RAID، پیام خطا، زمان حادثه، تغییرات اخیر، وضعیت بک آپ و فهرست داده های حیاتی را آماده کنید. رمزها و فایل های محرمانه را از مسیر عمومی یا ناامن نفرستید.

جمع بندی

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

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