بازیابی اطلاعات سرور چیست؟ روش‌های ریکاوری، سناریوهای خرابی و نکات حیاتی
خرابی سرور همیشه به معنی نابودی داده نیست؛ اما چند دقیقه تصمیم عجولانه می‌تواند یک مشکل قابل‌کنترل را به ازدست‌رفتن دائمی اطلاعات تبدیل کند. خرابی هارد، به‌هم‌ریختن RAID، حذف فایل، آسیب ماشین مجازی و باج‌افزار هرکدام مسیر تشخیص متفاوتی دارند. اگر همین حالا با قطعی روبه‌رو هستید، قبل از هر تعمیر، بخش بعد را بخوانید.
پس از خرابی سرور چه کار کنیم؟
اول وضعیت را ثابت نگه دارید. زمان خطا، پیام‌ها، چراغ دیسک‌ها، صدای غیرعادی، آخرین تغییرات و ترتیب فیزیکی هاردها را ثبت کنید. نوشتن روی رسانه مشکوک را متوقف کنید و سلامت بکاپ را از محیطی جداگانه، بدون دست‌کاری دیسک اصلی، بررسی کنید. اگر دیسک صدای تق‌تق دارد، مرتب قطع می‌شود یا کنترلر چند هارد را هم‌زمان Failed نشان می‌دهد، سرور را خاموش و ارزیابی تخصصی بگیرید.
چه کارهایی خطرناک‌اند؟ اجرای CHKDSK، fsck یا فرمت، Initialize کردن دیسک، تعویض چند هارد با هم و Rebuild خودسرانه RAID. این ابزارها بد نیستند، ولی ابزار تعمیر فایل‌سیستم‌اند و ممکن است روی ساختار آسیب‌دیده بنویسند. در یک پرونده فرضی، مدیر شبکه با تصور خرابی یک دیسک، Rebuild را آغاز می‌کند؛ دیسک دوم خطای خواندن دارد و آرایه وسط کار از دسترس خارج می‌شود. سؤال بعدی روشن است: آیا می‌شود بدون دست‌زدن به اصل داده کار کرد؟ بله؛ متخصص معمولاً ابتدا از دیسک‌ها ایمیج سکتوربه‌سکتور می‌گیرد و تحلیل را روی کپی انجام می‌دهد.
بازیابی اطلاعات سرور چیست؟
بازیابی اطلاعات سرور یعنی استخراج و بازگرداندن داده‌های قابل‌استفاده از رسانه، فایل‌سیستم، آرایه ذخیره‌سازی، ماشین مجازی یا بکاپ آسیب‌دیده. این کار با بازیابی سرویس فرق دارد: ممکن است فایل‌های دیتابیس سالم برگردند، اما تا نصب سیستم‌عامل، تنظیم مجوزها و راه‌اندازی برنامه، سرویس عملیاتی نشود.
| مفهوم | هدف | محدودیت |
|---|---|---|
| Data Recovery | نجات داده از وضعیت خراب یا حذف‌شده | موفقیت به آسیب و بازنویسی بستگی دارد |
| Backup | ساخت نسخه مستقل پیش از حادثه | باید سالم و قابل‌بازیابی باشد |
| Disaster Recovery | بازگرداندن سرویس، داده و عملیات سازمان | به طرح، زیرساخت و تمرین نیاز دارد |
| High Availability | کاهش قطعی با افزونگی | حذف یا رمزگذاری داده را جبران نمی‌کند |
پس تفاوت Backup و Recovery چیست؟ بکاپ نسخه‌ای است که از قبل ساخته‌اید؛ Recovery فرایند رسیدن به داده یا سرویس قابل‌استفاده است. Disaster Recovery نیز برنامه‌ای گسترده‌تر برای آدم‌ها، اولویت سرویس‌ها، ارتباطات و زیرساخت جایگزین است. برای جزئیات بیشتر، راهنمای Disaster Recovery چیست را ببینید.
ریکاوری سرور پیچیده‌تر از کامپیوتر شخصی است، چون داده میان RAID، LVM، SAN یا NAS پخش می‌شود. در سرورهای HP و Dell نیز مدل کنترلر، ترتیب دیسک‌ها و وضعیت رسانه مهم‌تر از برند است.
چه چیزهایی باعث ازدست‌رفتن داده می‌شوند؟
خرابی مکانیکی HDD، فرسودگی SSD، ایراد کنترلر RAID، نوسان برق، خاموشی ناگهانی، فرمت پارتیشن، حذف تصادفی، خرابی NTFS، ReFS، EXT4 یا XFS، اشتباه مدیریتی و اختلال Datastore از علت‌های رایج‌اند. باج‌افزار هم ممکن است داده اصلی و بکاپ متصل را هم‌زمان رمزگذاری کند.
روش‌های اصلی بازیابی اطلاعات سرور
| روش | کاربرد | محدودیت مهم |
|---|---|---|
| بازیابی از بکاپ | بازگشت از نسخه معتبر | سلامت، تازگی و تست Restore |
| File Recovery | فایل حذف‌شده | بازنویسی شانس را کم می‌کند |
| RAID Recovery | خرابی آرایه | ترتیب و وضعیت دیسک‌ها حیاتی است |
| VM Recovery | بازیابی VMDK یا VHDX | وابسته به سلامت Storage و زنجیره Snapshot |
| Database Recovery | بازگردانی دیتابیس | سازگاری منطقی باید بررسی شود |
| Snapshot Restore | بازگشت سریع به یک نقطه | جایگزین بکاپ مستقل نیست |
اگر بکاپ سالم و جدا دارید، Restore معمولاً امن‌ترین مسیر است. در نبود آن، Snapshot، لاگ تراکنش یا ایمیج رسانه بررسی می‌شود؛ تحلیل باید روی کپی کنترل‌شده باشد.
بازیابی اطلاعات RAID چگونه انجام می‌شود؟
RAID داده و افزونگی را میان چند دیسک توزیع می‌کند. RAID 0 افزونگی ندارد؛ RAID 1 داده را آینه می‌کند؛ RAID 5 تحمل خرابی یک دیسک و RAID 6 معمولاً تحمل خرابی دو دیسک دارد؛ RAID 10 نیز آینه‌سازی و Striping را ترکیب می‌کند. این تحمل خطا تضمین بازیابی نیست: حذف فایل، باج‌افزار، خرابی کنترلر و خطای انسانی می‌تواند کل آرایه را درگیر کند.
برای ریکاوری RAID، ترتیب دیسک‌ها، Stripe، Offset و Parity شناسایی و آرایه به‌صورت مجازی بازسازی می‌شود. انتقال دیسک‌ها به کنترلر ناسازگار یا Rebuild با چند دیسک معیوب خطر بازنویسی دارد. RAID جایگزین Backup نیست.
بازیابی ویندوز، لینوکس و ماشین‌های مجازی
Windows Server
در ویندوز، NTFS یا ReFS، Event Log، Shadow Copy و Windows Server Backup بررسی می‌شود. فایل‌های اشتراکی و مجوزها نیز باید اعتبارسنجی شوند. CHKDSK را پیش از ایمیج‌گیری روی دیسک معیوب اجرا نکنید.
Linux Server
در لینوکس، فایل‌سیستم، LVM، mdadm و لاگ‌ها بررسی می‌شوند. fsck یا xfs_repair روی رسانه ناپایدار خطر دارد. مالکیت فایل، Permission و سازگاری سرویس نیز باید برگردد.
VMware و Hyper-V
در VMware، Datastore، فایل VMDK و زنجیره Snapshot بررسی می‌شود؛ در Hyper-V نوبت VHDX و Checkpoint است. فایل بازیابی‌شده باید آزمایشی Mount و سازگاری برنامه بررسی شود. Snapshot و Checkpoint بکاپ مستقل نیستند.
بازیابی دیتابیس و حادثه باج‌افزاری
در SQL Server، Full Backup و Transaction Log امکان بازیابی نقطه‌ای می‌دهند. MySQL و PostgreSQL نیز از بکاپ و لاگ تراکنش کمک می‌گیرند. پس از Restore، سازگاری و رکوردهای کلیدی را تست کنید.
در حمله باج‌افزاری، سیستم آلوده را از شبکه جدا کنید، ولی شواهد را کورکورانه پاک نکنید. دامنه نفوذ، حساب‌های درگیر و سلامت بکاپ‌های Offline یا Immutable باید روشن شود. بازیابی در محیط پاک، اسکن داده و تغییر اعتبارنامه‌ها پیش از اتصال دوباره ضروری است؛ وگرنه داده سالم دوباره آلوده می‌شود. هماهنگی تیم زیرساخت با امنیت و حتی مرکز تماس سازمان کمک می‌کند پیام واحدی به کاربران و مشتریان برسد.
زمان، هزینه و احتمال موفقیت
برای موفقیت بازیابی عدد ثابت و صادقانه‌ای وجود ندارد. نوع خرابی، سلامت فیزیکی دیسک، مقدار بازنویسی، تعداد دیسک‌ها، ساختار RAID، رمزگذاری، فایل‌سیستم و اقدام‌های بعد از حادثه تعیین‌کننده‌اند. زمان نیز از تشخیص، ایمیج‌گیری، بازسازی، انتقال و اعتبارسنجی تشکیل می‌شود؛
| عامل هزینه | اثر بر کار | اطلاعات لازم |
|---|---|---|
| نوع خرابی | منطقی یا نیازمند تجهیزات تخصصی | علائم و گزارش خطا |
| RAID و تعداد دیسک | تحلیل و تصویربرداری بیشتر | سطح RAID، مدل کنترلر، ترتیب دیسک |
| حجم و اولویت داده | زمان انتقال و اعتبارسنجی | حجم کل و پوشه‌های حیاتی |
| فوریت | تخصیص منابع خارج از صف | RTO مورد انتظار |
پیش از اعلام هزینه بازیابی اطلاعات سرور، ارزیابی اولیه لازم است. قیمت تلفنی بدون دانستن ساختار آرایه و وضعیت دیسک‌ها بیشتر حدس است تا برآورد.
RPO و RTO چه می‌گویند؟
RPO بیشترین فاصله زمانی قابل‌قبول میان آخرین نسخه سالم و حادثه است؛ RTO زمان هدف برای بازگرداندن سرویس است. اگر RPO پانزده دقیقه و RTO دو ساعت باشد، حفاظت باید ازدست‌رفتن داده را به حدود پانزده دقیقه محدود کند و سرویس هدف در دو ساعت برگردد. این‌ها هدف طراحی‌اند، نه تضمین.
برای سنجش برنامه، نرخ موفقیت بکاپ و Restore، زمان واقعی بازیابی، صحت داده و دسترس‌پذیری سرویس را ثبت کنید. بکاپی که هر شب پیام Success می‌دهد اما هرگز Restore نشده، هنوز مدرک قابل اتکایی برای بازیابی نیست.
چطور احتمال ازدست‌رفتن اطلاعات را کم کنیم؟
سیاست 3-2-1، بکاپ آفلاین یا Immutable، مانیتورینگ RAID، کنترل دسترسی، وصله امنیتی و تست دوره‌ای Restore ضروری‌اند. پشتیبانی و نگهداری شبکه باید سلامت بکاپ، ظرفیت ذخیره‌سازی و سناریوی بحران را هم پوشش دهد.
چک‌لیست انتخاب تیم بازیابی
- تجربه با نوع سرور، RAID، NAS یا SAN شما
- تشخیص پیش از هر عملیات نوشتن و توضیح شفاف ریسک
- تعهد محرمانگی و زنجیره تحویل رسانه
- گزارش ارزیابی، محدوده هزینه و شرایط عدم موفقیت
- تحویل روی رسانه امن و امکان بررسی صحت داده
اگر مجموعه‌ای پیش از دیدن وضعیت، بازیابی صددرصدی وعده می‌دهد یا می‌خواهد فوراً Rebuild انجام دهد، احتیاط کنید.
سؤالات متداول
آیا اطلاعات سرور خراب قابل بازیابی است؟
در بسیاری از خرابی‌های منطقی و بعضی خرابی‌های فیزیکی بله، اما نتیجه به آسیب، بازنویسی و اقدام‌های پس از حادثه بستگی دارد.
آیا RAID 5 قابل بازیابی است؟
اغلب قابل بررسی است. سلامت همه دیسک‌ها، ترتیب آن‌ها و اینکه Rebuild ناموفق رخ داده یا نه، تعیین‌کننده است.
آیا سرور HP یا Dell فرق دارد؟
روش پایه مشابه است؛ مدل کنترلر، Metadata آرایه و رسانه‌های نصب‌شده تفاوت عملی ایجاد می‌کنند.
آیا فایل VHDX یا ماشین VMware بازیابی می‌شود؟
اگر بخش کافی از فایل و Metadata ذخیره‌سازی سالم باشد، امکان استخراج VM یا فایل‌های داخل آن وجود دارد؛ سپس سازگاری برنامه باید تست شود.
اگر بکاپ هم خراب باشد چه؟
نسخه‌های قدیمی‌تر، Replica، Snapshot، لاگ تراکنش و رسانه اصلی ارزیابی می‌شوند. هیچ‌کدام را روی منبع آسیب‌دیده آزمایش نکنید.
چه زمانی باید کار را به متخصص سپرد؟
وقتی دیسک نشانه فیزیکی دارد، چند عضو RAID از دسترس خارج شده، بکاپ نامطمئن است، باج‌افزار مطرح است یا داده برای کسب‌وکار حیاتی است. در این نقطه آزمون‌وخطا گران‌تر از تشخیص درست تمام می‌شود.
قبل از هر تعمیر، وضعیت را ارزیابی کنید
پرشین ارتباطات را به‌عنوان آزمایشگاه تخصصی ریکاوری هارد معرفی نمی‌کنیم؛ اما برای ارزیابی زیرساخت، طراحی بکاپ، برنامه بازیابی سرویس و مدیریت بحران شبکه می‌توانید از خدمات پشتیبانی و نگهداری شبکه کمک بگیرید. مشخصات سرور، علائم خطا و آخرین بکاپ موفق را آماده کنید تا تصمیم اولیه دقیق‌تر باشد.
