RTO مخفف Recovery Time Objective یا «هدف زمان بازیابی» است؛ یعنی حداکثر زمانی که یک سرویس یا فرایند حیاتی می‌تواند پس از اختلال از دسترس خارج باشد تا پیش از عبور از سطح قابل‌قبول کسب‌وکار بازیابی شود.
RTO پاسخ این سؤال است: «بعد از بحران، حداکثر تا چه زمانی باید سرویس برگردد؟» این عدد باید از نیاز کسب‌وکار و تحلیل اثر تعیین شود، نه صرفاً از توان فنی تیم IT.
یک مثال ساده از RTO
اگر RTO سامانه فروش ۲ ساعت باشد، برنامه بازیابی باید طوری طراحی شود که از لحظه اختلال تا بازگشت سرویس بیش از دو ساعت طول نکشد. این زمان می‌تواند شامل تشخیص حادثه، تصمیم Failover، راه‌اندازی زیرساخت جایگزین، Restore، تست و بازگشت کاربران باشد.
تفاوت RTO و RPO
RTO درباره زمان توقف سرویس است؛ اما RPO درباره میزان قابل‌قبول از دست‌رفتن داده است. ممکن است یک سیستم RTO دو ساعته داشته باشد اما RPO آن فقط ۱۵ دقیقه باشد؛ یعنی باید سریع برگردد و نسخه بازیابی نیز حداکثر ۱۵ دقیقه از داده‌های قبل از حادثه عقب باشد.
RTO چگونه تعیین می‌شود؟
- اثر توقف سرویس بر درآمد، عملیات و مشتریان
- الزامات قانونی و قراردادی
- وابستگی سرویس به سیستم‌های دیگر
- هزینه زیرساخت بازیابی سریع‌تر
- نتایج Business Impact Analysis
برای طراحی دقیق‌تر، RTO باید داخل DRP ثبت و در تست‌های بازیابی اندازه‌گیری شود. صفحه نقش RTO و RPO در تاب‌آوری خدمات فناوری اطلاعات نیز مقایسه کامل‌تری ارائه می‌کند.
سخن پایانی
RTO یک آرزو برای «سریع برگشتن» نیست؛ یک هدف قابل‌اندازه‌گیری است که باید با معماری، بودجه، Runbook و تست واقعی سازمان پشتیبانی شود.
