چگونه RPO و RTO تحمل از دست دادن داده‌ها را از هزینه قطعی سیستم جدا می‌کنند

در ۳۱ مه ۲۰۱۰، موسسه ملی استاندارد و فناوری (NIST) نسخه اول نشریه ویژه ۸۰۰-۳۴ را منتشر کرد. در این راهنمای ۱۱۸ صفحه‌ای برنامه‌ریزی اقتضایی برای سیستم‌های اطلاعاتی فدرال، نویسندگان تمایز ریاضیاتی دقیقی را رسم کردند که قرار بود معماری فناوری اطلاعات سازمان‌ها را برای دو دهه آینده هدایت کند. آن‌ها خط زمانی یک فاجعه را به دو متغیر کاملاً مجزا تقسیم کردند: گذشته و آینده.[1]

این سند تثبیت کرد که بازیابی از یک خرابی فاجعه‌بار، یک عملیات واحد نیست. بلکه نیازمند پاسخ به دو پرسش کاملاً متفاوت است: یک سازمان چقدر می‌تواند از دست دادن داده‌ها را تحمل کند، و چقدر می‌تواند آفلاین بودن را تاب بیاورد؟ پاسخ این پرسش‌ها با «هدف نقطه بازیابی» (RPO) و «هدف زمان بازیابی» (RTO) داده می‌شود.[1][5]

با وجود اینکه فروشندگان اغلب این دو را در قالب بسته‌های بازاریابی پر زرق‌وبرق «دسترس‌پذیری بالا» به هم گره می‌زنند، RPO و RTO محدودیت‌های فیزیکی متفاوتی را اندازه‌گیری می‌کنند. شاخص RPO از لحظه وقوع خرابی به عقب نگاه می‌کند و حداکثر داده‌های از دست رفته قابل‌قبول را بر حسب ساعت یا دقیقه می‌سنجد. اما RTO به جلو نگاه می‌کند و حداکثر زمان مجاز قطعی پیش از بازیابی سیستم‌ها را اندازه می‌گیرد.[5][6]

این تمایز از آن جهت اهمیت دارد که رساندن هر یک از این اعداد به صفر، نیازمند معماری‌های سخت‌افزاری و شبکه‌ای کاملاً متفاوتی است. یک خریدار شکاک باید بداند فروشنده‌ای که وعده «بازیابی فوری» می‌دهد، اغلب این دو مفهوم را با هم می‌آمیزد و در حالی که مشتری شاید تنها به تکرار تهاجمی داده‌ها نیاز داشته باشد، افزونگی پردازشی گران‌قیمتی را به او می‌فروشد.[7][8]

هدف نقطه بازیابی (RPO) زمان‌بندی بک‌آپ‌گیری و معماری ذخیره‌سازی را دیکته می‌کند. واژه‌نامه NIST شاخص RPO را به عنوان «نقطه‌ای از زمان که داده‌ها باید پس از قطعی به آن بازیابی شوند» تعریف می‌کند. اگر یک پایگاه داده دارای RPO چهار ساعته باشد، سیستم باید حداقل هر چهار ساعت یک اسنپ‌شات در حافظه ثانویه ثبت کند. در صورت بروز خرابی کامل در ساعت ۳:۵۹ بعدازظهر، سازمان می‌پذیرد که تمام تراکنش‌های پردازش‌شده از زمان بک‌آپ ظهر به طور دائمی پاک شده‌اند.[3]

کاهش RPO از چهار ساعت به نزدیک صفر، معماری را از بک‌آپ‌های دوره‌ای دسته‌ای به تکرار همزمان تغییر می‌دهد. هر عملیات نوشتن روی دیسک اصلی باید پیش از آنکه برنامه سیگنال موفقیت دریافت کند، همزمان روی یک دیسک ثانویه (اغلب در یک موقعیت جغرافیایی متفاوت) نیز نوشته شود. این امر هزینه‌ها را از طریق پهنای باند شبکه و عملیات ورودی/خروجی ذخیره‌سازی در ثانیه (IOPS) به شدت افزایش می‌دهد.[8]

در مقابل، هدف زمان بازیابی (RTO) بر زیرساخت انتقال به سیستم پشتیبان (Failover) حاکم است. هیئت ارزیابی و صدور گواهینامه حرفه‌ای (PECB) با استناد به ایزو ۲۲۳۰۱، شاخص RTO را به عنوان «مدت زمان پس از یک حادثه که در آن یک محصول یا خدمت باید از سر گرفته شود» تعریف می‌کند. اگر سیستمی دارای RTO دو ساعته باشد، واحد IT دقیقاً ۱۲۰ دقیقه فرصت دارد تا سرورها را آماده کند، سیستم‌عامل‌ها را بارگذاری نماید، داده‌ها را از جدیدترین بک‌آپ بازیابی کرده و ترافیک شبکه را تغییر مسیر دهد.[4]

کاهش RTO به نزدیک صفر نیازمند کلاسترینگ فعال-فعال است. محیط ثانویه نمی‌تواند یک انبار ذخیره‌سازی سرد باشد؛ بلکه باید یک نسخه کاملاً روشن و دارای لایسنس از محیط اصلی باشد که در لحظه آماده به کار است و منتظر می‌ماند تا به محض قطع شدن پینگ ارتباطی، آدرس‌های IP را در اختیار بگیرد. این قابلیت، هزینه‌ها را به دلیل نیاز به سخت‌افزار پردازشی افزونه و لایسنس‌های نرم‌افزاری به شدت بالا می‌برد.[8]

سازمان بین‌المللی استانداردسازی (ISO) این تعاریف را در سطح جهانی در استانداردهای ایزو ۲۲۳۰۱ و ایزو ۲۲۳۱۳ (استانداردهای سیستم‌های مدیریت تداوم کسب‌وکار) تدوین کرده است. این استانداردها سازمان‌ها را وادار می‌کنند تا اهداف خود را به جای قابلیت‌های فنی، بر اساس تأثیرات واقعی بر کسب‌وکار توجیه کنند.[4]

سیستم سوابق بیماران یک بیمارستان ممکن است به RPO صفر نیاز داشته باشد—زیرا از دست دادن به‌روزرسانی یک نسخه دارویی تهدیدکننده حیات است—اما RTO چهار ساعته برای آن کافی باشد، چرا که کارکنان می‌توانند موقتاً از پرونده‌های کاغذی استفاده کنند. برعکس، یک وب‌سایت خبری ممکن است RPO بیست‌وچهار ساعته را تحمل کند و مقالات دیروز را از آرشیو بازنشر دهد، اما برای در دسترس ماندن در زمان یک رویداد فوری، به RTO پنج دقیقه‌ای نیاز داشته باشد. پرداخت هزینه برای معماری RPO صفر در سایت خبری، یا معماری RTO صفر در بیمارستان، صرفاً هدر دادن سرمایه است.[6]

ادبیات بازاریابی ارائه‌دهندگان ابری اغلب این تفکیک را مبهم جلوه می‌دهد. فروشندگان با تبلیغ «۹۹.۹۹۹٪ در دسترس بودن»، تمام تمرکز خود را روی RTO (شاخص زمان آپ‌تایم) می‌گذارند. آن‌ها معمولاً RPO را در میان نوشته‌های ریز قرارداد پنهان می‌کنند و مشتری تازه در زمان قطعی متوجه می‌شود که اگرچه سرور در عرض چند ثانیه ریبوت شده، اما پایگاه داده متصل به آن به اسنپ‌شاتی مربوط به ۱۲ ساعت پیش بازگشته است.[7]

ابهام در بازیابی فاجعه مدرن در این نهفته است که باج‌افزارها چگونه این شاخص‌ها را تغییر می‌دهند. محاسبات سنتی RTO فرض را بر این می‌گذارند که دیتاسنتر اصلی در اثر یک رویداد فیزیکی از بین رفته و سایت ثانویه جایگزین بدیهی آن است. با این حال، باج‌افزارها اغلب شبکه را در سکوت آلوده می‌کنند، به این معنی که بک‌آپ‌های مورد نیاز برای تحقق RPO نیز ممکن است رمزنگاری شده باشند.[7]

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

آزمون واقعی این شاخص‌ها زمانی رخ می‌دهد که یک سازمان مجبور می‌شود برنامه اقتضایی خود را تحت فشار اجرا کند. اگر داده‌های بک‌آپ مورد نیاز برای برآورده کردن RPO خودشان آلوده شده باشند، زمان RTO به پایان می‌رسد در حالی که تیم‌های امنیتی هنوز در جستجوی یک اسنپ‌شات پاک هستند—و این ثابت می‌کند که اگر چیزی برای بازیابی باقی نمانده باشد، بازیابی سریع هیچ فایده‌ای ندارد.[8]