وقتی سازمانی برای راهکار پشتیبانگیری یا بازیابی از حادثه سراغ ما میآید، اولین سؤال ما دربارهٔ فناوری نیست. دو عدد میپرسیم — و در بیشتر موارد، هیچکس پاسخ روشنی ندارد.
خلاصه: RPO میگوید چقدر داده میتوانید از دست بدهید. RTO میگوید چقدر میتوانید سرویس نداشته باشید. بدون این دو، هر انتخابی حدس است.
RPO — چقدر داده قابل از دست دادن است؟
Recovery Point Objective یعنی فاصلهٔ زمانی بین آخرین نسخهٔ پشتیبان سالم و لحظهٔ حادثه. اگر شبها ساعت ۲ پشتیبان میگیرید و ساعت ۴ بعدازظهر اتفاقی میافتد، ۱۴ ساعت کار را از دست دادهاید.
سؤال درست این نیست که «چقدر داده از دست بدهیم خوب است؟» — پاسخ همیشه «هیچ» است. سؤال درست این است: از دست رفتن چند ساعت کار، چقدر برای سازمان هزینه دارد؟ وقتی این را به عدد تبدیل کنید، بودجهٔ راهکار خودش مشخص میشود.
RTO — چقدر میشود سرویس نداشت؟
Recovery Time Objective یعنی فاصلهٔ بین قطع سرویس و برگشتن آن. این عدد معمولاً بیشتر از چیزی که مدیران فکر میکنند طول میکشد، چون فقط زمان بازیابی فایل نیست:
- تشخیص اینکه اصلاً مشکلی هست
- تصمیمگیری برای شروع بازیابی (که اغلب نیاز به تأیید دارد)
- تهیهٔ سختافزار یا فضای جایگزین، اگر لازم باشد
- بازیابی واقعی داده
- راستیآزمایی و بازگرداندن سرویس به مدار
در تمرینهای واقعی بازیابی، معمولاً مرحلهٔ دوم و سوم بیشترین زمان را میبرند، نه مرحلهٔ چهارم.
چرا این دو عدد همهچیز را تعیین میکنند
یک مثال ساده: سازمانی با RPO بیستوچهار ساعت، با پشتیبانگیری شبانه روی دستگاه محلی راضی میشود. همان سازمان اگر RPO یکساعته داشته باشد، به تکرارسازی پیوسته نیاز دارد — یعنی راهکاری از جنس کاملاً متفاوت و با هزینهٔ چند برابر.
به همین ترتیب، RTO چهار ساعته یعنی باید سختافزار جایگزین از قبل آماده باشد. RTO سه روزه یعنی میتوانید منتظر تهیهٔ تجهیزات بمانید. این دو، دو دنیای متفاوت از نظر هزینهاند.
یک نکتهٔ عملی
این اعداد را برای کل سازمان تعیین نکنید. سامانهٔ معاملاتی و بایگانی اسناد اداری، دو نیاز کاملاً متفاوت دارند. اگر برای همهچیز سختگیرانهترین عدد را بگذارید، هزینهای میدهید که لازم نیست؛ اگر آسانترین را بگذارید، جایی که مهم است ضربه میخورید.
سرویسها را دستهبندی کنید و برای هر دسته عدد جدا بگذارید. همین کار، نصف تصمیمگیری را انجام میدهد.