وقتی سرور سازمان بالا نمی آید؛ ۴ کاری که تا یک ساعت اول نباید انجام دهید

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

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

بازیابی اطلاعات سرور 

چرا روشن و خاموش کردن مداوم یا Rebuild عجولانه کار را خراب تر می کند؟

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

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

۲. سرور را پشت سر هم خاموش و روشن نکنید

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

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

سناریوی بحران؛ چه زمانی باید کابل برق استوریج را بدون معطلی بکشیم؟

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

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

۴. روی همان دیسک ها تعمیر آزمایشی انجام ندهید

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

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

نرخ نامه و تعرفه های بازیابی اطلاعات سرور در تهران (سال ۱۴۰۵)

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

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

بازیابی اطلاعات سرور استوریج NAS یا SAN

جدول قیمت ریکاوری بر اساس ظرفیت، نوع پیکربندی RAID و نوع هارد (SAS/SATA/NVMe)

در پیش فاکتور چه چیزهایی باید مشخص باشد؟

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

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

چه عواملی هزینه نهایی را جا به جا می کند؟ (خرابی فیزیکی جراحی هارد در برابر خطای لاجیکال)

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

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

خدمات فورس ماژور و اورژانسی در تهران؛ چقدر به فاکتور نهایی اضافه می کند؟

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

در متن اولیه، افزایش هزینه ۳۰ تا ۵۰ درصدی مطرح شده بود؛ این بازه تایید نشده و باید از خود مرکز استعلام شود. به جای وعده «نصف شدن زمان»، درباره زمان شروع، برنامه گزارش دهی و عوامل احتمالی تاخیر توافق کنید.

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

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

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

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

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

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

کلین روم کلاس ۱۰۰ و دستگاه های اختصاصی جراحی دیسک دقیقا چه فرقی در خروجی دارند؟

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

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

آدرس و محدوده جغرافیایی معتبرترین لابراتوارهای تخصصی ریکاوری سرور در تهران

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

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

خطر لو رفتن داده های مالی و دیتابیس؛ امنیت اطلاعات و قرارداد NDA چیست؟

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

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

بازیابی اطلاعات دیتابیس SQL

بندهای کلیدی در قرارداد عدم افشای اطلاعات (NDA) که باید از مرکز بازیابی بخواهید

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

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

آیا امکان دارد فرآیند ریکاوری زیر نظر مستقیم کارشناس شبکه شرکت ما انجام شود؟

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

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

کالبدشکافی خطاهای مرگبار سرور؛ مشکل دیتابیس شما در کدام دسته است؟

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

خطای RAID Controller و گم شدن چیدمان دیسک ها (RAID ۵, ۶, ۱۰)

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

پیام Unconfigured Bad به تنهایی ثابت نمی کند دیسک سالم است یا فقط تنظیمات از دست رفته است. معنی وضعیت ها بین کنترلرها متفاوت است و باید همراه با شواهد دیگر بررسی شود. تغییر وضعیت دیسک بدون تشخیص علت، می تواند مسئله را پیچیده تر کند.

پریدن ماشین های مجازی در VMware ESXi و خرابی فایل های Datastore یا VMDK

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

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

آسیب دیدن دیتابیس های حجیم SQL Server، اوراکل و فایل های نرم افزارهای مالی و ERP

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

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

آسیب فیزیکی همزمان چند هارد دیسک بر اثر نوسان برق رک یا خرابی کولینگ اتاق سرور

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

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

فرآیند مرحله به مرحله ثبت سفارش تا تحویل دیتا در ایران هارد

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

تحویل حضوری یا اعزام پیک اختصاصی امن در سطح شهر تهران

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

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

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

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

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

تست سلامت داده ها و تحویل فایل ها روی مدیا یا استوریج اختصاصی مشتری

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

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

سوالات پرتکرار مدیران IT درباره ریکاوری

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

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

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

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

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

هارد سروری که قبلا در یک مرکز دیگر باز شده و دست خورده است، قابل بازیابی است؟

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

آیا برای عیب یابی باید کل شاسی سرور یا تیغه ها را بیاوریم یا فقط هاردها کافی است؟

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

در روزهای تعطیل یا ساعات غیر اداری، پشتیبانی شیفت و اضطراری برای سرور فعال است؟

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

اگر دو یا چند هارد در آرایه RAID به صورت همزمان سوخته باشند، امیدی به برگشت دیتا هست؟

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

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