دو عددی که طرح بازیابی را تعیین می‌کنند

این دو عدد چه می‌گویند

هدف زمان بازگشت (RTO — Recovery Time Objective) پاسخ این پرسش است: از لحظهٔ قطع سرویس تا لحظهٔ بازگشت آن به کار، چه مدت زمانی قابل تحمل است؟ این عدد مدت توقف را توصیف می‌کند، نه سرعت کپی فایل.

بیشینهٔ داده از دست‌رفته (RPO — Recovery Point Objective) پاسخ پرسش دیگری است: پس از بازگشت سرویس، قابل قبول است که کار چند دقیقه یا چند ساعت اخیر از دست رفته باشد؟ این عدد فاصلهٔ میان نسخه‌های پشتیبان را تعیین می‌کند.

تفاوت این دو در عمل بسیار مهم است. سازمانی می‌تواند RTO چهار ساعته و RPO پانزده دقیقه‌ای داشته باشد: بازگرداندن سرویس نیم‌روز وقت می‌برد، اما داده‌ای بیش از ربع ساعت نباید از دست برود. طرحی که فقط یکی از این دو را برآورده کند، طرح کاملی نیست.

چرا یکسان‌سازی اهداف اشتباه است

وسوسهٔ طبیعی این است که برای همهٔ سرویس‌ها یک هدف تعیین شود — مثلاً «همه چیز تا دو ساعت برگردد». این تصمیم هم‌زمان پرهزینه و غیرواقعی است: پرهزینه چون سخت‌گیرانه‌ترین نیاز را به کل زیرساخت تعمیم می‌دهد، و غیرواقعی چون در یک رویداد واقعی همه چیز را نمی‌توان هم‌زمان برگرداند.

راه درست، دسته‌بندی سرویس‌ها بر پایهٔ تحمل توقف سازمان است. یک تقسیم‌بندی سه‌لایه در بیشتر سازمان‌ها کافی است:

• لایهٔ حیاتی: سرویسی که توقف آن کار سازمان را متوقف می‌کند — سامانهٔ اصلی کسب‌وکار، احراز هویت، و در بسیاری سازمان‌ها مرکز تلفن.
• لایهٔ مهم: سرویسی که توقف چندساعته‌اش قابل تحمل است اما توقف یک‌روزه‌اش نه — فایل سرور بخش‌ها، سامانه‌های گزارش‌گیری.
• لایهٔ پشتیبان: سرویسی که می‌تواند روزها بعد برگردد — محیط آزمون، آرشیو قدیمی.

این دسته‌بندی هم‌زمان ترتیب بازگردانی را هم تعیین می‌کند. در یک رویداد گسترده، تیم عملیات به فهرستی نیاز دارد که بگوید اول چه چیزی، و این فهرست باید پیش از رویداد نوشته شده باشد — نه در میانهٔ آن.

چه تصمیم‌هایی از این دو عدد بیرون می‌آید

اهداف بازیابی اعداد روی کاغذ نیستند؛ هر کدام یک الزام فنی ایجاد می‌کنند.

بیشینهٔ داده از دست‌رفته، فاصلهٔ نسخه‌ها را تعیین می‌کند

اگر RPO پانزده دقیقه باشد، پشتیبان‌گیری شبانه کافی نیست؛ لازم است سامانه در طول روز هم نسخه بگیرد، و این بر بار ذخیره‌ساز و شبکه اثر می‌گذارد. اگر RPO بیست و چهار ساعت باشد، یک نسخهٔ شبانه پاسخ می‌دهد و طرح به‌مراتب ساده‌تر و ارزان‌تر می‌شود.

هدف زمان بازگشت، روش بازگردانی را تعیین می‌کند

بازگرداندن یک ماشین مجازی چند ترابایتی از نسخهٔ پشتیبان، زمان خواندن از ذخیره‌ساز را می‌خواهد. اگر این زمان از هدف بیشتر باشد، راه‌حل تغییر ابزار نیست؛ تغییر معماری است — مثلاً نگه‌داشتن یک نسخهٔ آمادهٔ اجرا در محل دوم، تا بازگشت به جای بازگردانی، سوئیچ کردن باشد.

هر دو عدد، محل نگه‌داشت نسخه را تعیین می‌کنند

نسخهٔ محلی سریع‌ترین بازگشت را می‌دهد و نسخهٔ خارج از محل، بقا در رویداد گسترده. سازمانی که هر دو هدف را جدی گرفته باشد به هر دو نسخه نیاز دارد، چون هیچ‌کدام جایگزین دیگری نیست.

عددی که آزموده نشده، عدد نیست

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

آزمون بازیابی لازم نیست پیچیده باشد، اما باید واقعی باشد: یک سرویس انتخاب می‌شود، روی محیط جدا بازگردانده می‌شود، زمان واقعی بازگشت ثبت می‌شود و اختلاف آن با هدف بررسی می‌گردد. اگر این آزمون دوره‌ای انجام شود، عدد مستند به واقعیت نزدیک می‌ماند؛ در غیر این صورت با هر تغییر زیرساخت از آن فاصله می‌گیرد.

یک نکتهٔ امنیتی که معمولاً جا می‌افتد

اهداف بازیابی برای خرابی سخت‌افزار و خطای انسانی طراحی می‌شوند، اما سناریوی رایج‌تر امروز چیز دیگری است: مهاجمی که به دامنه دسترسی گرفته و پیش از رمزگذاری داده، نسخه‌های پشتیبان را حذف می‌کند.

این سناریو یک الزام اضافه می‌گذارد: دسترسی مدیریتی سامانهٔ پشتیبان نباید با همان حساب‌های دامنهٔ اصلی ممکن باشد، و دست‌کم یک نسخه باید در جایی نگه داشته شود که حذف آن از دامنهٔ اصلی امکان‌پذیر نباشد. بدون این لایه، هدف زمان بازگشت در دقیق‌ترین حالت خود هم بی‌معنا می‌شود — چون چیزی برای بازگرداندن نمانده است.