Disaster Recovery چیست؟ راهنمای بازیابی پس از بحران

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

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

خلاصه سریع

• Disaster Recovery یا DR برای بازگرداندن سرویس ها و داده ها پس از اختلال جدی برنامه ریزی می کند.
• بکاپ نسخه ای از داده ها و اجزای مورد نیاز را نگه می دارد؛ DR مشخص می کند چگونه از آنها برای بازیابی سرویس استفاده کنیم.
• High Availability یا HA به ادامه دسترسی به سرویس هنگام خرابی بعضی اجزا کمک می کند؛ DR برای بازیابی پس از بحران های تعریف شده آماده می شود.
• RTO هدف زمانی بازگرداندن سرویس و RPO هدف مربوط به میزان قابل قبول از دست رفتن داده، برحسب زمان است.
• برنامه بازیابی باید آزمایش شود تا زمان بازیابی، صحت داده ها و عملکرد سرویس در عمل بررسی شود.

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

بکاپ، نسخه قابل بازیابی را فراهم می کند؛ Disaster Recovery مسیر بازگرداندن سرویس را مشخص می کند.

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

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

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

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

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

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

HA و DR مکمل یکدیگرند. وجود HA به تنهایی اثبات نمی کند که برای حذف داده، حمله باج افزاری یا از دست رفتن کامل محیط اصلی آماده هستیم.

برنامه تداوم کسب و کار یا Business Continuity Plan دامنه ای گسترده تر از فناوری اطلاعات دارد. این برنامه مشخص می کند سازمان هنگام بحران چگونه فعالیت های ضروری خود را با کمک افراد، فرایندها، امکانات و روش های ارتباطی ادامه دهد.

Disaster Recovery، بخش مربوط به بازیابی سامانه ها و زیرساخت فناوری اطلاعات در این آمادگی است. برای مثال، در زمان توقف فروشگاه اینترنتی، برنامه DR به بازگرداندن سایت و داده ها می پردازد؛ برنامه تداوم کسب و کار می تواند روش اطلاع رسانی به مشتریان، رسیدگی به سفارش های قبلی و ادامه موقت پاسخگویی از یک کانال دیگر را مشخص کند.

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

فرض کنیم یک فروشگاه اینترنتی در ساعت ۱۰:۰۰ دچار اختلال جدی شده است. اهداف بازیابی آن به صورت زیر تعیین شده اند:

اگر فروشگاه ساعت ۱۱:۳۰ قابل استفاده شود، هدف زمانی بازیابی محقق شده است. اگر داده های بازیابی شده تا ساعت ۹:۵۰ را پوشش دهند، فاصله نقطه بازیابی تا حادثه ۱۰ دقیقه است و هدف RPO نیز محقق شده است.

اما اگر سرویس ساعت ۱۱:۳۰ بالا بیاید و داده ها فقط تا ساعت ۹:۰۰ موجود باشند، RTO محقق شده ولی RPO رعایت نشده است. در حالت معکوس، بازیابی داده تا ساعت ۹:۵۵ همراه با راه اندازی سرویس در ساعت ۱۳:۰۰، هدف RPO را محقق می کند ولی از RTO عبور می کند.

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

همه سامانه ها به RTO و RPO یکسان نیاز ندارند. توقف یک سیستم ثبت سفارش ممکن است مستقیما درآمد را تحت تاثیر قرار دهد، در حالی که توقف یک گزارش داخلی برای چند ساعت قابل تحمل باشد.

برای تعیین این اهداف، باید موارد زیر بررسی شوند:

• اثر توقف سرویس: اختلال چه تاثیری بر درآمد، مشتریان و فعالیت های ضروری دارد؟
• اثر از دست رفتن داده: آیا اطلاعات اخیر قابل بازسازی هستند و بازسازی آنها چه هزینه ای دارد؟
• وابستگی سرویس ها: سامانه برای بازگشت به کار به کدام پایگاه داده، سرویس یا ارائه دهنده بیرونی نیاز دارد؟
• نیازهای قراردادی و قانونی: چه تعهدهایی درباره دسترسی به سرویس و حفاظت از اطلاعات وجود دارد؟
• هزینه و توان اجرایی: چه بودجه، نیروی انسانی و امکاناتی برای دستیابی به اهداف در دسترس است؟

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

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

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

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

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

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

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

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

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

این مقایسه جهت کلی انتخاب را نشان می دهد. برای تعیین RTO و RPO قابل دستیابی، باید معماری واقعی، حجم داده، ظرفیت مقصد و نتایج آزمایش بررسی شوند.

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

Cloud DR یک سطح آمادگی ثابت ندارد. در فضای ابری نیز می توان از Backup and Restore، Pilot Light، Warm Standby یا Active/Active استفاده کرد.

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

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

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

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

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

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

برای هر سرویس، این اطلاعات ثبت می شود:

• مالک یا مسئول سرویس.
• اهمیت و اولویت بازیابی.
• RTO و RPO مورد نیاز.
• داده ها و اجزای ضروری.
• وابستگی های داخلی و بیرونی.
• معیار قابل استفاده بودن سرویس پس از بازیابی.

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

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

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

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

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

آزمایش می تواند در سطح های مختلف انجام شود:

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

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

برنامه باید با وضعیت واقعی سامانه هماهنگ بماند. تغییر معماری، نسخه برنامه، پایگاه داده، دسترسی ها یا اعضای تیم می تواند دستورالعمل قبلی را ناقص کند.

بازبینی برنامه در این شرایط اهمیت دارد:

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

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

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

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

سایر خطاهای رایج عبارت اند از:

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

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