ورود به پنل کاربری
PRIORITY · PREPARE · RECOVER · ACCEPT

طراحی و پیاده‌سازی Disaster Recovery

راهنمای بازیابی بحران یا DR؛ از هدف RPO و RTO تا وابستگی سرویس‌ها، برنامهٔ بازگردانی، محیط پاک و تمرین پذیرش خدمت.

نقشهٔ مفهومی مراحل طراحی و پیاده‌سازی Disaster Recovery

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

طراحی Disaster Recovery سازمانی؛ از نیاز واقعی شروع کنیم

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

۱

نیاز و پوشش

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

۲

طراحی راهکار

روش، محل نگهداری، اختیار اجرا و مسیر خطا را مشخص کنید.

۳

آزمون ایزوله

بازیابی و پذیرش برنامه را در محیط مجاز و جدا بررسی کنید.

۴

تحویل و بازبینی

شاهد آزمون، مسئول پیگیری و برنامهٔ بازآزمون را نگه دارید.

اولویت خدمت و وابستگی‌های واقعی

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

RPO و RTO را جدا تعریف کنید

در راهنمای NIST SP 800-34، RPO به نقطهٔ زمانی داده برای بازیابی و RTO به هدف زمان در دسترس نبودن منبع مربوط است. یکی دربارهٔ دادهٔ قابل برگشت و دیگری دربارهٔ زمان بازگشت است. این‌ها هدف توافقی‌اند، نه نتیجهٔ خودکار نصب ابزار؛ معیار اندازه‌گیری و دامنهٔ خدمت باید معلوم باشد.

سناریوی خرابی و دامنهٔ پوشش

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

آمادگی محیط جایگزین

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

نسخهٔ سالم و بازگردانی در محیط پاک

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

راهنمای اجرا، اختیار و ارتباطات

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

بازگشت به محیط اصلی و تطبیق داده

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

تمرین، شاهد پذیرش و هزینه

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

طراحی و پیاده‌سازی Disaster Recovery در ویوان نت

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

مثال آموزشی، نه نمونه‌کار واقعی

سناریوی آموزشی: طراحی Disaster Recovery سازمانی

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

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

راهنماهای مرتبط

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

پرسش‌های متداول دربارهٔ طراحی و پیاده‌سازی Disaster Recovery

DR همان بکاپ است؟

خیر؛ بکاپ نسخهٔ داده است، DR بازگرداندن خدمت، مسئولیت‌ها و وابستگی‌های لازم را هم پوشش می‌دهد.

RPO و RTO چه فرقی دارند؟

RPO نقطهٔ دادهٔ قابل بازیابی را هدف می‌گیرد؛ RTO هدف زمان بازگشت منبع یا خدمت در دامنهٔ مشخص است.

آیا هدف نوشته‌شده تضمین نتیجه است؟

خیر؛ تحقق هدف باید با طراحی، منابع و تمرین معتبر بررسی و محدودیت آن ثبت شود.

در حادثه امنیتی آخرین نسخه را برگردانیم؟

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

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

بدون مجوز و طرح کنترل‌شده نه؛ محیط ایزوله و دادهٔ مجاز برای آزمون اولیه مناسب‌ترند.

چه مدرکی تحویل بگیریم؟

دامنهٔ سناریو، اهداف، ترتیب اجرا، مسئولان، نتیجهٔ پذیرش برنامه و روش بازگشت به محیط اصلی.

منابع فنی و مطالعهٔ بیشتر

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

قابل بازیابی بودن خدمت را به معیار تبدیل کنیم

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

ثبت درخواست مشاوره ←