DRP یا Disaster Recovery Plan برنامه‌ای عملیاتی برای بازیابی سرویس‌ها، سیستم‌ها و داده‌های حیاتی پس از یک بحران فناوری اطلاعات است. DRP مشخص می‌کند چه چیزی باید بازیابی شود، با چه اولویتی، توسط چه کسی، در چه زمانی و با چه روش‌هایی.
اجزای اصلی یک DRP
- فهرست سرویس‌ها و سیستم‌های حیاتی
- RTO و RPO هر سرویس
- مسئولیت‌ها و Call Tree بحران
- Backup، Replication و محل نگهداری نسخه‌های بازیابی
- Runbook مرحله‌به‌مرحله بازیابی
- وابستگی‌ها؛ مانند DNS، Active Directory، Database و Network
- روش تست، بازبینی و ثبت Lessons Learned
RTO و RPO در DRP چه نقشی دارند؟
RTO مشخص می‌کند سرویس حداکثر چه مدت می‌تواند در دسترس نباشد. RPO مشخص می‌کند از دست‌رفتن چه مقدار داده قابل قبول است. مثلاً RTO برابر ۲ ساعت و RPO برابر ۱۵ دقیقه یعنی سرویس باید حداکثر ظرف دو ساعت برگردد و بازیابی داده نباید بیش از ۱۵ دقیقه عقب‌تر از لحظه حادثه باشد.
DRP با Backup یکی نیست
Backup فقط یکی از ابزارهای DRP است. داشتن نسخه پشتیبان بدون Runbook، دسترسی اضطراری، زیرساخت جایگزین، تست Restore و مسئول مشخص، به معنای داشتن Disaster Recovery Plan نیست.
تفاوت DRP و Business Continuity
DRP بیشتر روی بازیابی فناوری و سرویس‌های IT تمرکز دارد؛ Business Continuity دامنه وسیع‌تری دارد و ادامه فعالیت کسب‌وکار، نیروی انسانی، محل کار، تأمین‌کنندگان و فرایندهای حیاتی را نیز پوشش می‌دهد. برای تعیین اولویت‌ها معمولاً از Business Impact Analysis استفاده می‌شود.
چگونه DRP را تست کنیم؟
- Tabletop: مرور سناریو و نقش‌ها بدون قطع سرویس.
- Restore Test: بازیابی واقعی Backup و سنجش زمان و صحت داده.
- Partial Failover: انتقال کنترل‌شده بخشی از سرویس به محیط جایگزین.
- Full Simulation: شبیه‌سازی کامل بحران برای سرویس‌های بسیار حیاتی، با برنامه و کنترل ریسک.
سخن پایانی
DRP زمانی معتبر است که قابل اجرا و قابل آزمون باشد. سندی که فقط روی کاغذ وجود دارد، در بحران ارزش چندانی ندارد؛ برنامه بازیابی باید با RTO/RPO، زیرساخت واقعی و تمرین دوره‌ای سازمان هماهنگ باشد.
