سرور یک مجموعه از دسترس خارج شده و مدیر آن با اطمینان میگوید: «بکاپ داریم.» اما هنگام Restore مشخص میشود آخرین نسخه مربوط به چند هفته قبل است، بخشی از فایلها در آن وجود ندارد یا آرشیو اصلاً خوانده نمیشود. در چنین موقعیتی تازه سؤال مهم مطرح میشود: بکاپ چیست و آیا هر فایل پشتیبانی واقعاً قابل بازیابی است؟ بکاپ، نسخهای جداگانه از دادههای مهم است؛ ولی صرف وجود آن روی یک دیسک یا فضای ابری، موفقیت ریستور را ثابت نمیکند.
بکاپ یا Backup نسخهای مستقل از اطلاعات اصلی است که برای بازگرداندن فایلها، تنظیمات، دیتابیس یا سرویسها پس از حذف، خرابی یا حمله سایبری نگهداری میشود. یک بکاپ معتبر باید کامل، بهروز، در دسترس و آزمایششده باشد؛ بنابراین «تهیه موفق بکاپ» بدون انجام تست Restore، بهتنهایی قابلیت بازیابی اطلاعات را تضمین نمیکند.
بکاپ چیست و چه کاربردی دارد؟
اگر بخواهیم ساده بگوییم بکاپگیری چیست، فرایندی است که طی آن از دادههای انتخابشده نسخهای قابل بازگردانی ساخته میشود. این دادهها میتوانند فایلهای سایت، دیتابیس، ایمیلها، تنظیمات سیستمعامل، کانفیگ سرویسها، ماشینهای مجازی یا کل وضعیت یک سرور باشند.
نسخه پشتیبان هنگام حذف اشتباهی، خرابی سختافزار، خطای انسانی، آلودگی به بدافزار، بهروزرسانی ناموفق یا اختلال گسترده سرور کاربرد دارد. بااینحال، کپی موجود روی همان سرور یا همان Storage در برابر خرابی مشترک، باجافزار و حذف مدیریتی محافظت کافی ایجاد نمیکند. بکاپ باید از داده اصلی مستقل، با سطح دسترسی کنترلشده، قابلدسترسی در زمان بحران و قابلآزمایش باشد.
تفاوت Backup، Restore و Recovery چیست؟
این سه واژه به بخشهای متفاوتی از حفاظت و بازگردانی داده اشاره دارند. Backup پیش از حادثه انجام میشود، Restore از نسخه سالم استفاده میکند و Recovery معمولاً دامنه گستردهتری دارد؛ بهخصوص زمانی که نسخه معتبر وجود ندارد، ریستور شکست میخورد یا رسانه ذخیرهسازی آسیب دیده است.
| مفهوم | تعریف | زمان استفاده | پیشنیاز | نمونه کاربرد |
|---|---|---|---|---|
| Backup | ایجاد و نگهداری نسخه پشتیبان | پیش از خرابی و طبق برنامه | فضای امن و سیاست نگهداری | بکاپ شبانه از دیتابیس |
| Restore | بازگرداندن داده از بکاپ | پس از حذف یا اختلال | نسخه سالم، سازگار و در دسترس | ریستور یک فایل یا ماشین مجازی |
| Recovery | بازیابی داده یا سرویس در سناریوی خرابی | هنگام نبود بکاپ معتبر یا آسیب زیرساخت | بررسی تخصصی دیسک، RAID و ساختار داده | بازسازی منطقی RAID و استخراج اطلاعات |
«Restore چیست» این است: بازگرداندن اطلاعات از یک منبع پشتیبان قابلاعتماد. تفاوت بکاپ و ریکاوری نیز در این است که بکاپ یک اقدام پیشگیرانه است، اما ریکاوری مجموعه اقداماتی برای برگرداندن داده یا سرویس پس از حادثه محسوب میشود. Disaster Recovery حتی میتواند بازگردانی زیرساخت، شبکه، برنامهها و تداوم سرویس را نیز پوشش دهد.
انواع بکاپ در سرور
بکاپ کامل یا Full Backup
در بکاپ کامل، تمام دادههای انتخابشده در هر نوبت کپی میشوند. بازیابی آن ساده و سریع است، اما تهیه نسخه به زمان و فضای بیشتری نیاز دارد. Full Backup معمولاً مبنای زنجیره نسخههای افزایشی یا تفاضلی است.
بکاپ افزایشی یا Incremental Backup
پس از یک نسخه کامل، فقط تغییرات ایجادشده از آخرین بکاپ ذخیره میشوند. تهیه آن سریع و کمحجم است؛ ولی برای ریستور کامل معمولاً نسخه پایه و همه Incrementalهای سالم زنجیره لازماند. خرابی یکی از حلقهها ممکن است بازیابی نقاط بعدی را مختل کند.
بکاپ تفاضلی یا Differential Backup
هر نسخه تفاضلی، تمام تغییرات پس از آخرین Full Backup را ثبت میکند. در نتیجه از Incremental فضای بیشتری میگیرد، اما برای بازگردانی معمولاً فقط نسخه کامل و آخرین Differential سالم کافی است.
| نوع | فضای موردنیاز | سرعت تهیه | سرعت بازیابی | کاربرد مناسب |
|---|---|---|---|---|
| Full | زیاد | کمتر | زیاد | نسخه پایه و سیستمهای کوچک |
| Incremental | کم | زیاد | کمتر | بکاپ پرتکرار و تغییرات روزانه |
| Differential | متوسط و رو به افزایش | متوسط | متوسط تا زیاد | تعادل میان فضای ذخیره و زمان ریستور |
روش اصولی بکاپگیری از سرور
بکاپگیری از سرور با نصب یک نرمافزار تمام نمیشود؛ باید بر اساس اهمیت سرویس، سرعت تغییر داده و هزینه توقف طراحی شود. برای جزئیات اجرایی بیشتر میتوانید راهنمای راهکارهای Backup گیری حرفهای در سرور را نیز بخوانید.
- دادههای حیاتی را مشخص کنید:
فایلهای سایت، دیتابیس، تنظیمات سرویس، کلیدها، گواهیها و ماشینهای مجازی را شناسایی و وابستگیهای لازم برای راهاندازی مجدد آنها را ثبت کنید.
- RPO و RTO را تعیین کنید:
RPO میزان قابلقبول از دست رفتن داده و RTO حداکثر زمان قابلقبول برای توقف سرویس است.
- بکاپ را خودکار و پایشپذیر کنید:
زمانبندی بکاپ، خطاهای Job، ظرفیت مخزن، مدت اجرا و تاریخ انقضای نسخهها را مرتب بررسی کنید.
- یک نسخه خارج از سرور اصلی نگه دارید:
بکاپ را روی Storage یا RAID جداگانه و در صورت امکان در موقعیتی خارج از محل اصلی ذخیره کنید.
- دسترسی به بکاپ را محدود کنید:
از مجوزهای حداقلی، احراز هویت مناسب و حسابهای کاربری جداگانه برای مدیریت بکاپ استفاده کنید.
- نسخه آفلاین یا Immutable داشته باشید:
نسخههای جدا از شبکه یا تغییرناپذیر، خطر حذف عمدی و حملات باجافزاری را کاهش میدهند. - گزارشها و Restore را مستند کنید:
مسئول اجرا، محل نسخهها، کلیدهای دسترسی، ترتیب راهاندازی سرویسها و مراحل بازگشت به تولید را در Runbook ثبت و بهروز کنید.
قانون 3-2-1 بکاپ و نسخه 3-2-1-1-0
بر اساس راهنمای فنی Veeam، قانون 3-2-1 یعنی سه نسخه از داده داشته باشید: داده اصلی و دو بکاپ، روی دو نوع رسانه، با حداقل یک نسخه خارج از محل اصلی. در الگوی 3-2-1-1-0، یک نسخه آفلاین، Air-gapped یا Immutable نیز اضافه میشود و عدد صفر به معنی باقی نماندن خطای تأییدنشده در بررسی صحت و تست بازیابی است.
چگونه تست سالم بودن بکاپ را انجام دهیم؟
پیام «Backup Successful» فقط نشان میدهد Job طبق انتظار نرمافزار تمام شده است؛ نه اینکه همه فایلها سالماند یا سرویس در زمان موردنیاز بالا میآید. دو آزمون زیر باید در برنامه نگهداری بکاپ قرار بگیرند:
Restore آزمایشی: بخشی از اطلاعات یا یک سرویس نمونه را در محیطی جدا از Production برگردانید. سطح دسترسی، سازگاری نسخهها، بوت ماشین مجازی، اتصال برنامه به دیتابیس و زمان واقعی بازیابی را بررسی کنید.
همچنین Logها و هشدارها را بخوانید، Checksum یا قابلیت Integrity Check ابزار را اجرا کنید و چند فایل نمونه از انواع مختلف را باز کنید. تست دورهای Disaster Recovery باید سناریوی قطع سرویس، مسئولیت افراد، دسترسی به رمزها و زمان بازگشت را هم بسنجد. مستندات Microsoft نیز بر قابلآزمایش بودن برنامه DR و سنجش زمان Restore در برابر RTO تأکید دارد.
چه زمانی Restore معمولی کافی است؟
ریستور بکاپ انتخاب درستی است وقتی مشکل در سطح منطقی رخ داده و نسخهای سالم، بهروز و سازگار در اختیار دارید. حذف یک فایل، تغییر اشتباه تنظیمات، انتشار نسخه معیوب برنامه یا خراب شدن محدود دیتابیس معمولاً با بازیابی بکاپ حل میشود؛ به شرط آنکه مقصد سالم باشد و بازه زمانی نسخه با RPO کسبوکار سازگار باشد.
Snapshot سالم نیز ممکن است برای بازگشت سریع یک ماشین مجازی یا Volume مفید باشد، اما Snapshot وابسته به همان Storage جای بکاپ مستقل را نمیگیرد. پیش از بازگردانی کامل، اثر آن بر دادههای جدید و امکان بازیابی انتخابی را بررسی کنید.
چه زمانی بازیابی تخصصی اطلاعات لازم میشود؟
وقتی منبع سالمی برای Restore وجود ندارد یا خود لایه ذخیرهسازی آسیب دیده، تکرار ریستور معمولاً مسئله را حل نمیکند. نشانههای مهم عبارتاند از:
- سرور بوت نمیشود یا Volume به حالت RAW درآمده است.
- RAID در وضعیت Failed یا Offline قرار دارد.
- چند دیسک بهصورت همزمان از دسترس خارج شدهاند.
- فایل بکاپ ناقص، خراب، قدیمی یا غیرقابلخواندن است.
- هارد صدای غیرعادی دارد، شناسایی نمیشود یا خطاهای فیزیکی نشان میدهد.
- فرآیند Rebuild ناموفق انجام شده است.
- ترتیب و وضعیت دیسکها نامشخص است.
- اطلاعات بدون داشتن بکاپ حذف شده است.
- فایل ماشین مجازی، دیتابیس، NAS، SAN یا Storage آسیب دیده است.
RAID با افزونگی و تحمل خرابی، دسترسپذیری را بهتر میکند؛ اما از حذف، باجافزار، خرابی کنترلر، خطای Rebuild یا از دست رفتن بیش از ظرفیت تحمل آرایه جلوگیری نمیکند. برای شناخت سطحهای مختلف، مقاله بررسی کامل انواع RAID و کاربردشان را ببینید. در این سناریوها ابتدا باید وضعیت دیسکها، متادیتا، ترتیب اعضا و احتمال Overwrite بدون تغییر روی منبع ارزیابی شود.
بعد از خرابی سرور چه کارهایی انجام ندهیم؟
RAID را بدون بررسی وضعیت اعضا و علت خرابی Rebuild نکنید. دیسکها را بدون ثبت شماره Bay، ترتیب، Serial و وضعیت هر عضو جابهجا نکنید. Storage یا Volume ناشناخته را Initialize، Format یا دوباره پارتیشنبندی نکنید. نرمافزار ریکاوری را روی همان دیسکها نصب و خروجی را روی منبع ذخیره نکنید. روی رسانه آسیبدیده فایل جدید ننویسید و سرویس تولید را روی آن ادامه ندهید. هارد دارای صدای غیرعادی را بارها روشن و خاموش نکنید. پیش از ارزیابی فنی، دستورها و آزمونوخطاهای نامطمئن اینترنتی را اجرا نکنید.
این اقدامات ممکن است باعث Overwrite شدن بلوکهای قابلبازیابی، تغییر متادیتا، تخریب ساختار RAID یا تشدید آسیب فیزیکی شوند. در خرابی RAID، خاموشکردن کنترلشده پس از ثبت وضعیت و حفظ ترتیب دیسکها معمولاً از ادامه نوشتن ناخواسته جلوگیری میکند؛ تصمیم نهایی باید با توجه به اهمیت سرویس و وضعیت سختافزار گرفته شود.
اگر سرور بوت نمیشود، چند دیسک RAID همزمان از دسترس خارج شدهاند، بکاپ معتبر ندارید یا Restore با خطا روبهرو است، ادامه آزمونوخطا میتواند شرایط را پیچیدهتر کند. بهتر است پیش از Rebuild، فرمت یا تغییر تنظیمات بازیابی اطلاعات سرور از یک مرکز تخصصی مانند امدادسیستم مشاوره بگیرید.
جمعبندی؛ بکاپ چیست و چه زمانی قابل اتکاست؟
در پاسخ نهایی به سؤال بکاپ چیست باید گفت: نسخهای مستقل و قابلآزمایش برای بازگرداندن داده، نه صرفاً فایلی که جایی ذخیره شده است. بکاپ زمانی ارزش دارد که جدا از منبع اصلی نگهداری، مرتب پایش و عملاً Restore شود. اگر نسخه سالمی وجود ندارد یا سرور، RAID و هارد آسیب دیدهاند، Recovery فرآیندی متفاوت از ریستور معمولی است و باید با حفظ وضعیت موجود آغاز شود.
سؤالات متداول
بکاپ چیست و چه تفاوتی با ریکاوری دارد؟
بکاپ ساخت نسخه پشتیبان پیش از حادثه است. ریکاوری فرایند بازگرداندن داده یا سرویس پس از خرابی است و میتواند شامل Restore بکاپ یا بازیابی از رسانه آسیبدیده باشد.
آیا RAID جایگزین بکاپ است؟
خیر. RAID میتواند خرابی تعداد مشخصی دیسک را تحمل کند، اما در برابر حذف، بدافزار، خرابی همزمان چند عضو یا خطای مدیریتی نسخه تاریخی مستقلی ارائه نمیدهد.
از کجا بفهمیم بکاپ سالم است؟
گزارشها و Checksum را بررسی کنید، بکاپ را Mount و فایلهای نمونه را باز کنید و مهمتر از همه، Restore آزمایشی را در محیط جداگانه انجام دهید.
چرا فایل بکاپ Restore نمیشود؟
ناقص بودن زنجیره، خرابی فایل، کمبود فضا، ناسازگاری نسخه نرمافزار، مجوزهای اشتباه، رمز یا کلید گمشده و آسیب مخزن از علتهای رایجاند.
بعد از خرابی RAID اولین اقدام چیست؟
نوشتن روی آرایه را متوقف کنید، پیامها و ترتیب دیسکها را ثبت کنید و بدون بررسی Rebuild یا Initialize انجام ندهید. سپس وضعیت برای انتخاب روش ایمن ارزیابی شود.