RPO مخفف Recovery Point Objective یا «هدف نقطه بازیابی» است؛ یعنی حداکثر مقدار دادهای که سازمان حاضر است در یک بحران از دست بدهد. RPO معمولاً بهصورت یک بازه زمانی بیان میشود. RPO پاسخ این سؤال است: «اگر سیستم از کار افتاد، دادهها حداکثر تا چه زمانی قبل از حادثه میتوانند برگردند؟» یک مثال ساده از RPO اگر RPO یک سامانه مالی ۱۵ دقیقه باشد، راهکار Backup یا Replication باید طوری طراحی شود که در بدترین حالت بیش از ۱۵ دقیقه داده از دست نرود. اگر آخرین Backup چهار ساعت قبل باشد، این معماری با RPO پانزدهدقیقهای سازگار نیست. تفاوت RPO و RTO RPO میزان از دسترفتن داده را محدود میکند؛ در حالی که RTO حداکثر زمان قابلقبول برای بازگرداندن سرویس است. مثلاً ممکن است RPO برابر ۱۵ دقیقه و RTO برابر ۲ ساعت باشد. RPO چه اثری بر Backup و Replication دارد؟ RPO چندساعته ممکن است با Backup دورهای قابل دستیابی باشد. RPO کوتاهتر معمولاً به Backupهای پرتکرار، Snapshot یا Replication نیاز دارد. RPO نزدیک به صفر میتواند معماری پیچیدهتر و هزینه بیشتری ایجاد کند. صرف داشتن Backup کافی نیست؛ بازیابی و صحت داده نیز باید تست شود. RPO را چگونه تعیین کنیم؟ RPO باید بر اساس ارزش و نرخ تغییر داده، اثر از دسترفتن اطلاعات، الزامات قانونی و هزینه بازیابی تعیین شود. خروجی Business Impact Analysis کمک میکند برای هر سرویس RPO واقعبینانه تعریف شود. RPO و RTO باید داخل Disaster Recovery Plan ثبت شوند و با تستهای دورهای اثبات شوند. برای مقایسه عمیقتر نیز مقاله نقش RTO و RPO در تابآوری خدمات فناوری اطلاعات را ببینید. سخن پایانی RPO عددی برای تیم Backup نیست؛ یک تصمیم کسبوکاری درباره میزان دادهای است که سازمان توان از دستدادنش را دارد و معماری فنی باید برای تحقق آن طراحی شود.
