باج‌افزار، خرابی سخت‌افزار، حذف اشتباهی دیتابیس یا قطعی طولانی یک دیتاسنتر؛ سوال این نیست که آیا یکی از این‌ها رخ می‌دهد، بلکه این است که وقتی رخ داد، کسب‌وکار شما در چه مدتی و با چقدر از دست دادن داده دوباره کار می‌کند. برنامه بازیابی از حادثه یا DR Plan پاسخ از پیش آماده به همین سوال است. در این راهنما مفاهیم کلیدی، سطوح مختلف DR و قدم‌های نوشتن یک برنامه عملی را برای کسب‌وکارهای کوچک و متوسط توضیح می‌دهیم.
فهرست مطالب
برنامه بازیابی از حادثه چیست؟
برنامه بازیابی از حادثه (Disaster Recovery Plan) سندی است که مشخص می‌کند پس از یک حادثه جدی، چه سیستم‌هایی، به چه ترتیبی، توسط چه کسانی و با چه روشی بازگردانده می‌شوند. DR بخشی از مفهوم بزرگ‌تر «تداوم کسب‌وکار» است: DR روی بازگرداندن زیرساخت IT تمرکز دارد، و تداوم کسب‌وکار به ادامه کار سازمان در کل، از ارتباط با مشتریان تا روش‌های جایگزین کار، می‌پردازد.
بکاپ به‌تنهایی برنامه DR نیست. بکاپ داده را حفظ می‌کند؛ DR مشخص می‌کند با آن بکاپ، چطور و در چه مدتی سرویس دوباره کار می‌کند.
RPO و RTO
- RPO (Recovery Point Objective): حداکثر داده‌ای که از دست دادنش قابل قبول است، به زمان. RPO چهار ساعته یعنی بکاپ یا تکثیر باید دست‌کم هر چهار ساعت انجام شود.
- RTO (Recovery Time Objective): حداکثر زمانی که سرویس می‌تواند پس از حادثه از دسترس خارج باشد تا دوباره کار کند.
این دو عدد را مدیران کسب‌وکار تعیین می‌کنند، نه تیم فنی؛ چون به هزینه قطعی و از دست رفتن داده برای کسب‌وکار وابسته‌اند. هرچه RPO و RTO کوتاه‌تر، راهکار گران‌تر. برای هر سیستم جداگانه تعیین کنید: درگاه فروش آنلاین ممکن است RTO یک ساعته بخواهد، اما سیستم گزارش‌گیری داخلی با یک روز هم مشکلی ندارد.
سناریوهای حادثه
| سناریو | اثر | راه بازیابی |
|---|---|---|
| حذف یا خرابی داده با خطای انسانی | بخشی از داده | بازیابی انتخابی از بکاپ |
| به‌روزرسانی ناموفق | یک سرویس | بازگشت به Snapshot یا نسخه قبلی |
| خرابی سرور یا دیسک | یک سرور | سرور جایگزین و بازیابی بکاپ |
| باج‌افزار یا نفوذ | چند سیستم، اعتماد به همه سیستم‌ها از بین می‌رود | ساخت از نو و بازیابی از بکاپ ایزوله |
| قطعی یا حادثه دیتاسنتر | همه سیستم‌های آن محل | راه‌اندازی در محل دوم |
| از دست رفتن دسترسی به حساب‌ها | پنل‌ها، دامنه، DNS | حساب‌های اضطراری و مستندات دسترسی |
سناریوی باج‌افزار به‌خصوص مهم است؛ چون بکاپ‌های در دسترس سرور آلوده هم ممکن است از بین رفته باشند. اصول نگهداری بکاپ ایزوله را در بکاپ سرور چیست و چرا Snapshot جای Backup را نمی‌گیرد ببینید.
سطوح DR
| سطح | شرح | RTO معمول | هزینه |
|---|---|---|---|
| بکاپ و بازیابی | بکاپ در محل دیگر؛ در حادثه، سرور جدید ساخته و داده بازیابی می‌شود | ساعت‌ها تا یک روز | کم |
| Pilot Light | دیتابیس به‌طور مداوم در محل دوم تکثیر می‌شود؛ بقیه سرورها در حادثه راه‌اندازی می‌شوند | دقیقه‌ها تا ساعت‌ها | متوسط |
| Warm Standby | نسخه کوچک‌تری از کل سرویس در محل دوم آماده به کار است | دقیقه‌ها | بالا |
| Active-Active | سرویس همزمان در دو محل کار می‌کند | نزدیک صفر | بسیار بالا |
برای اغلب کسب‌وکارهای کوچک و متوسط، سطح «بکاپ و بازیابی» که درست پیاده و تست شده باشد، و برای سیستم‌های حیاتی‌تر Pilot Light، تعادل مناسبی بین هزینه و ریسک است.
نوشتن برنامه در ۷ قدم
- فهرست دارایی‌ها: سرورها، سرویس‌ها، دیتابیس‌ها، دامنه‌ها، حساب‌های ابری و وابستگی‌های آن‌ها.
- تحلیل اثر: برای هر سیستم، هزینه هر ساعت قطعی و از دست رفتن داده را بسنجید و RPO و RTO تعیین کنید.
- اولویت‌بندی: ترتیب بازگرداندن؛ مثلاً اول DNS و دیتابیس، سپس سایت فروش، بعد سیستم‌های داخلی.
- انتخاب راهکار: سطح DR مناسب برای هر گروه از سیستم‌ها.
- نقش‌ها و ارتباطات: چه کسی تصمیم می‌گیرد، چه کسی اجرا می‌کند، با کدام ارائه‌دهندگان تماس گرفته می‌شود و به مشتریان چه گفته می‌شود.
- مستندسازی دسترسی‌ها: اطلاعات ورود اضطراری به پنل‌ها، ثبت‌کننده دامنه، DNS و بکاپ‌ها، در جایی امن که با از دست رفتن سرورها از بین نرود.
- Runbook و تست (بخش‌های بعدی).
Runbook: دستورالعمل روز حادثه
در روز حادثه، فشار زیاد است و نباید به حافظه افراد تکیه کرد. برای هر سناریوی اصلی یک دستورالعمل قدم‌به‌قدم بنویسید؛ آن‌قدر دقیق که کسی جز نویسنده هم بتواند اجرایش کند:
- چطور حادثه تأیید و اعلام می‌شود.
- دستورهای دقیق ساخت سرور جایگزین، بازیابی دیتابیس و فایل‌ها.
- تغییرات DNS لازم؛ مفاهیم در DNS چیست.
- چک‌لیست اطمینان از سلامت سرویس پس از بازیابی.
- متن آماده اطلاع‌رسانی به مشتریان.
Runbook را نسخه‌بندی کنید و یک نسخه از آن را خارج از زیرساخت اصلی نگه دارید.
تست برنامه
برنامه‌ای که تست نشده، فقط یک فرضیه است. حداقل سالی دو بار، و پس از تغییرات مهم زیرساخت:
- تست روی میز: تیم سناریو را مرور و نقاط مبهم را پیدا می‌کند.
- بازیابی آزمایشی: یک سرویس را واقعاً روی محیط جداگانه از بکاپ بالا بیاورید و زمان آن را با RTO مقایسه کنید.
- بازبینی: هر آنچه در تست کند یا مبهم بود، در برنامه و Runbook اصلاح شود.
نسخه حداقلی برای کسب‌وکار کوچک
- بکاپ خودکار روزانه با یک نسخه در محل دیگر و یک نسخه غیرقابل تغییر؛ اصول در تفاوت Snapshot و Backup.
- یک صفحه مستند: فهرست سرویس‌ها، محل بکاپ‌ها، دسترسی‌های اضطراری و شماره تماس ارائه‌دهندگان.
- Runbook ساده برای «سرور از دست رفت».
- یک بازیابی آزمایشی در سال.
- پایش و هشدار تا حادثه زود کشف شود؛ مقدمات در مانیتورینگ سرور چیست.
سوالات متداول
فرق بکاپ و برنامه بازیابی از حادثه چیست؟
بکاپ نسخه‌ای از داده‌هاست. برنامه بازیابی مشخص می‌کند با آن بکاپ، چه کسی، به چه ترتیبی و در چه مدتی سرویس‌ها را بازمی‌گرداند.
RPO و RTO را چطور تعیین کنیم؟
با پرسیدن اینکه هر ساعت قطعی و از دست رفتن هر ساعت داده چقدر برای کسب‌وکار هزینه دارد، و مقایسه آن با هزینه راهکارهای کوتاه‌تر کردن این زمان‌ها.
آیا سرور در دیتاسنتر دوم لازم است؟
برای اغلب کسب‌وکارهای کوچک، بکاپ در محل دوم کافی است. سرور آماده در محل دوم وقتی لازم می‌شود که RTO کوتاه باشد.
برنامه DR را چند وقت یک بار به‌روز کنیم؟
پس از هر تغییر مهم در زیرساخت و حداقل سالی یک بار، همراه با تست.
بکاپ، بازیابی و راهبری زیرساخت
برای طراحی بکاپ ایزوله، برنامه بازیابی و پایش مستمر، از خدمات پشتیبانی IT و مدیریت سرور تراست هاست کمک بگیرید.
