درخواست صفر اتلاف داده و بازیابی فوری برای همه‌ی سامانه‌ها بودجه را از بین می‌برد. روشی عملی برای طبقه‌بندی سامانه‌ها با تحلیل اثر کسب‌وکار و انتخاب هدف RPO/RTO و فناوری مناسب برای هر یک.
از بسیاری از SMBها درباره‌ی برنامه‌ی بازیابی از فاجعه (DR) بپرسید، پاسخ این است: «ما هر شب پشتیبان می‌گیریم.» اما نسخه‌ی پشتیبان یک کپی از داده‌هاست؛ بازیابی از فاجعه یعنی دوباره به راه انداختن کسب‌وکار. اگر از پیش ندانید پس از آتش‌سوزی، خرابی سخت‌افزار یا حمله‌ی باج‌افزاری چه مقدار داده را می‌توانید از دست بدهید و چه مدت می‌توانید از کار بیفتید، برنامه‌ای ندارید. پاسخ این دو پرسش را RPO و RTO می‌دهند.
RPO و RTO چیستند؟
- RPO (هدف نقطه‌ی بازیابی): حداکثر میزان قابل‌قبول اتلاف داده که بر حسب زمان سنجیده می‌شود. اگر هر شب پشتیبان بگیرید، RPO شما حدود 24 ساعت است؛ فاجعه‌ای در بعدازظهر همه‌ی داده‌های آن روز را از بین می‌برد.
- RTO (هدف زمان بازیابی): حداکثر زمان قابل‌قبول تا زمانی که سامانه دوباره قابل استفاده شود.
هرچه هر دو کوتاه‌تر باشند، هزینه بیشتر است. بنابراین به‌جای هدف‌گیری «صفر اتلاف، بازیابی فوری» در همه جا، باید سامانه‌ها را بر اساس اهمیتشان برای کسب‌وکار گروه‌بندی کرد.
گام 1: تحلیل اثر کسب‌وکار
این پرسش‌ها را برای هر سامانه مطرح کنید:
- اگر این سامانه یک ساعت از کار بیفتد، چه چیزی از دست می‌دهیم؟ فروش، تولید، رضایت مشتری، جریمه‌های قراردادی؟
- اگر داده‌های یک ساعت اخیر این سامانه از بین برود، می‌توانیم آن را دوباره ایجاد کنیم؟
- آیا تعهد قانونی یا قراردادی برای دسترس‌پذیری وجود دارد؟
- به کدام سامانه‌های دیگر وابسته است؟
این تحلیل را نباید واحد IT به‌تنهایی انجام دهد، بلکه باید همراه با واحدهای کسب‌وکار انجام شود. تیمی که از یک سامانه استفاده می‌کند بهتر از همه می‌داند که آیا آن سامانه حیاتی است یا نه.
گام 2: سامانه‌ها را در سطوح مختلف گروه‌بندی کنید
- سطح 1 — حیاتی: ERP، تجارت الکترونیک، سامانه‌های پرداخت و سفارش. هدف: RPO در حد دقیقه، RTO در حد چند ساعت. فناوری مناسب: تکثیر پیوسته به یک مرکز داده‌ی دیگر.
- سطح 2 — مهم: ایمیل، سرور فایل، CRM. هدف: RPO بین 1 تا 4 ساعت، RTO در همان روز کاری. فناوری مناسب: تکثیر مکرر یا کپی‌های اسنپ‌شات.
- سطح 3 — پشتیبان: آرشیو، محیط‌های آزمایش و توسعه. هدف: RPO برابر 24 ساعت، RTO چند روز. فناوری مناسب: بازیابی از پشتیبان خارج از محل.
گام 3: وابستگی‌ها و ترتیب را ترسیم کنید
بالا آوردن یک سرور برنامه در چند دقیقه بی‌فایده است اگر احراز هویت (Active Directory) و DNS از کار افتاده باشند. ترتیب بازیابی را مکتوب کنید: ابتدا شبکه، هویت و DNS؛ سپس پایگاه‌های داده؛ و در آخر برنامه‌ها و دسترسی کاربران. برنامه همچنین باید پوشش دهد که نشانی‌های IP، رکوردهای DNS و اتصال‌های VPN در محیط DR چگونه تغییر می‌کنند.
گام 4: دستورالعمل اجرایی برای زمان فاجعه
- چه کسی و بر اساس چه معیارهایی وقوع فاجعه را اعلام می‌کند؟
- کدام سامانه توسط چه کسی و به چه ترتیبی بالا آورده می‌شود؟
- چه چیزی و از طریق کدام کانال به کارکنان، مشتریان و تأمین‌کنندگان اطلاع داده می‌شود؟
- چگونه و چه زمانی به مرکز داده‌ی اصلی بازمی‌گردید؟
گام 5: مانورها
برنامه‌ی DR آزموده‌نشده فقط یک فرض است. دست‌کم سالی دو بار مانور برگزار کنید و RTO واقعی را اندازه بگیرید. راهکارهای مدرن تکثیر به شما اجازه می‌دهند بدون تأثیر بر محیط عملیاتی، مانورها را در یک شبکه‌ی آزمایشی جداگانه اجرا کنید. پس از هر مانور، برنامه را به‌روزرسانی کنید.
سناریوی باج‌افزار را فراموش نکنید
تکثیر، داده‌های رمزگذاری‌شده را نیز ظرف چند ثانیه به سمت DR کپی می‌کند. بنابراین راهکار DR شما باید نه‌تنها «آخرین وضعیت» بلکه نقاط بازیابی تاریخی را نیز نگه دارد. دوره‌ی نگهداری ژورنال تکثیر را همراه با نسخه‌های پشتیبان تغییرناپذیر خود برنامه‌ریزی کنید تا بتوانید به نقطه‌ای سالم درست پیش از آغاز حمله بازگردید.
اشتباهات رایج
- یکی دانستن نسخه‌ی پشتیبان با برنامه‌ی بازیابی از فاجعه
- نگهداری کپی DR در همان ساختمان یا مرکز داده‌ی محیط عملیاتی
- نادیده‌گرفتن برنامه‌ی شبکه، DNS و دسترسی کاربران
- نوشتن برنامه و هرگز نیازمودن آن
- نبود مسئول مشخص برای برنامه یا دوره‌ی بازبینی
DRaaS CloudRUX
DRaaS CloudRUX با تکثیر پیوسته‌ی مبتنی بر Zerto، سرورهای مجازی شما را به یک مرکز داده‌ی جداگانه در ترکیه کپی می‌کند و به شما امکان می‌دهد بدون تأثیر بر محیط عملیاتی مانور اجرا کنید. در چارچوب گواهی‌نامه‌ی مدیریت تداوم کسب‌وکار ISO 22301، می‌توانیم با هم سامانه‌های شما را سطح‌بندی کرده و هدف RPO/RTO مناسب را برای هر یک تعیین کنیم. برای ارزیابی با ما از طریق info@cloudrux.com تماس بگیرید.