DR مخفف Disaster Recovery یا «بازیابی از فاجعه» است؛ مجموعه‌ای از سیاست‌ها، فناوری‌ها و رویه‌ها برای بازگرداندن سرویس‌ها، سیستم‌ها و داده‌های حیاتی پس از یک اختلال شدید.
هدف DR این نیست که هر خرابی کوچکی را مدیریت کند؛ تمرکز آن روی سناریوهایی است که ادامه سرویس را تهدید می‌کنند، مثل خرابی دیتاسنتر، حمله باج‌افزاری، از دست رفتن زیرساخت حیاتی، خطای گسترده انسانی یا بلایای طبیعی.
اجزای اصلی Disaster Recovery
- شناسایی سرویس‌ها و سامانه‌های حیاتی
- Backup و Replication مناسب
- تعریف RTO و RPO برای هر سرویس
- Runbook بازیابی و نقش‌های مشخص
- محیط جایگزین یا Site ثانویه در صورت نیاز
- آزمون دوره‌ای سناریوهای بازیابی
DR با Business Continuity چه تفاوتی دارد؟
Business Continuity دامنه بزرگ‌تری دارد و هدفش ادامه عملکرد کسب‌وکار در بحران است؛ اما DR بیشتر روی بازیابی فناوری، داده و سرویس‌های IT تمرکز می‌کند. بنابراین DR یکی از اجزای مهم برنامه تداوم کسب‌وکار است، نه معادل کامل آن.
RTO و RPO چه نقشی در DR دارند؟
RTO مشخص می‌کند سرویس حداکثر چه مدت می‌تواند از دسترس خارج باشد و RPO نشان می‌دهد سازمان چه میزان از داده اخیر را می‌تواند از دست بدهد. این دو شاخص مستقیماً روی معماری Backup، Replication، HA و هزینه راهکار DR اثر می‌گذارند. برای جزئیات، مقاله RTO و RPO در تاب‌آوری خدمات فناوری اطلاعات را ببینید.
DRP چیست و چه تفاوتی با DR دارد؟
DR مفهوم کلی بازیابی از فاجعه است؛ اما DRP یا Disaster Recovery Plan سند اجرایی این مفهوم است. DRP باید مراحل بازیابی، اولویت سرویس‌ها، افراد مسئول، ارتباطات و روش آزمون را مشخص کند. برای ساختار عملی برنامه، DRP چیست؟ را مطالعه کنید.
یک مثال ساده
فرض کنید پایگاه داده اصلی یک سامانه مالی از دسترس خارج شده است. اگر سازمان نسخه Replica سالم، Backup قابل بازیابی، RTO دو ساعته و Runbook مشخص داشته باشد، تیم می‌داند چه سرویس‌هایی را با چه ترتیبی برگرداند و چه زمانی Failback انجام دهد. این یعنی DR از یک «نسخه پشتیبان» فراتر رفته و به یک قابلیت واقعی سازمانی تبدیل شده است.
سخن پایانی
Disaster Recovery زمانی واقعی است که آزمایش شده باشد. داشتن Backup بدون سنجش RTO/RPO، Runbook و آزمون بازیابی، تضمین نمی‌کند که سازمان در بحران بتواند سرویس حیاتی را به‌موقع برگرداند.
