RPO پنجره از دست رفتن داده‌ای را توصیف می‌کند که آماده پذیرش آن هستید؛ RTO وقفه‌ای را توصیف می‌کند که هدف شما نگه داشتن آن در محدوده مشخص است. هر دو را برای یک کارکرد تجاری مفید تعریف کنید، سپس توالی بازیابی را در یک تمرین اثبات کنید. یک برنامه پشتیبان‌گیری یا مشخصات سرور به‌تنهایی هیچ‌کدام از این اهداف را تعیین نمی‌کند.
با سرویسی شروع کنید که مردم بتوانند از آن استفاده کنند
اهداف بازیابی زمانی مفید می‌شوند که یک کارکرد تجاری را توصیف کنند، نه یک ماشین منفرد. یک سرور می‌تواند بالا بیاید در حالی که مشتریان هنوز نمی‌توانند وارد شوند، فایل‌ها را بازیابی کنند یا درخواستی را کامل کنند. شرط پایان را به زبان ساده بنویسید: کاربران مجاز می‌توانند به برنامه دسترسی داشته باشند و داده‌های مورد نیاز سازگار هستند. این کار هدف را برای فردی بیرون از تیم زیرساخت قابل آزمایش می‌کند.
از مالک برنامه بپرسید که یک وقفه چه چیزی را متوقف می‌کند و داده‌های ازدست‌رفته چه هزینه‌ای دارند. یک انتشار هفتگی و یک برنامه پردازش تراکنش ممکن است پاسخ‌های متفاوتی داشته باشند. اهداف حاصل را به‌عنوان اهداف برنامه‌ریزی در نظر بگیرید، نه وعده‌هایی که از فهرست سخت‌افزار ساخته شده‌اند. ثبت کنید چه کسی آن‌ها را تأیید کرده و برنامه کدام سناریوهای خرابی را پوشش می‌دهد.
دو ساعت را جدا کنید
RPO به این مربوط است که داده‌های بازیابی‌شده ممکن است نسبت به زمان اختلال چقدر عقب باشند. RTO به این مربوط است که کارکرد ممکن است چه مدت غیرقابل دسترس بماند. یک پشتیبان تازه می‌تواند پنجره از دست رفتن داده را بهبود دهد، در حالی که یک بازیابی کند همچنان هدف زمان بازیابی را از دست می‌دهد. برعکس، یک راه‌اندازی مجدد سریع می‌تواند دسترسی به برنامه‌ای را بازگرداند که تازه‌ترین داده‌اش باقی نمانده است.
نقاط مرجع را مشخص کنید. تصمیم بگیرید ساعت رخداد چه زمانی شروع می‌شود، چه چیزی عملیات بازیابی‌شده به حساب می‌آید و نقطه داده قابل استفاده چگونه شناسایی خواهد شد. اهداف را از نتایج اندازه‌گیری‌شده جدا نگه دارید: هدف آن چیزی است که دنبال می‌کنید؛ یک تمرین نشان می‌دهد فرایند فعلی به چه چیزی رسیده است. هر یک را هنگام تغییر برنامه یا مجموعه داده بازبینی کنید.
برای هر مرحله بازیابی بودجه در نظر بگیرید
یک بودجه عملی RTO شامل تشخیص، ارزیابی، مجوزدهی، دسترسی به محیط بازیابی، بازیابی، اعتبارسنجی برنامه و بازگشایی است. زمان کپی فایل تنها یک جزء است. اگر فردی که کلید بازیابی را دارد در دسترس نباشد، یک پشتیبان به‌ظاهر سریع می‌تواند همچنان غیرقابل استفاده باشد. وابستگی‌ها را فهرست کنید و مطمئن شوید تیم بازیابی می‌تواند در طول خرابی مورد بررسی به آن‌ها دسترسی داشته باشد.
برای هر مرحله یک زمان موقت تعیین کنید، سپس برآوردها را با مشاهدات جایگزین کنید. در این بودجه نمونه دو ساعته، بازیابی بیشترین سهم را دریافت می‌کند اما اعتبارسنجی همچنان زمان محافظت‌شده دارد. این اعداد یک نمونه برنامه‌ریزی را توصیف می‌کنند، نه ارائه سرویس SwissOctet. اگر مجموع حاشیه‌ای ندارد، طراحی پیش از معتبر بودن هدف به بهبود نیاز دارد.
| مرحله بازیابی | سهم نمونه | شواهدی که باید جمع‌آوری شود |
|---|---|---|
| تشخیص و ارزیابی | 15 دقیقه | رسیدن هشدار و تصمیم رخداد |
| آماده‌سازی محیط بازیابی | 20 دقیقه | دسترسی و پیکربندی در دسترس |
| بازیابی داده و سرویس | 50 دقیقه | بازیابی کامل با داده‌های سازگار |
| اعتبارسنجی و بازگشایی | 25 دقیقه | مسیر کاربر موفق می‌شود |
| حاشیه احتمالی | 10 دقیقه | کار پیش‌بینی‌نشده ثبت‌شده |
پنجره واقعی از دست رفتن داده را بررسی کنید
کاری که هر ساعت زمان‌بندی می‌شود به‌طور خودکار RPO یک‌ساعته ارائه نمی‌دهد. یک کار ناموفق، بارگذاری تأخیری یا نسخه غیرقابل استفاده می‌تواند آخرین نقطه قابل بازیابی را بسیار قدیمی‌تر کند. تکمیل موفق و وضعیتی که واقعاً می‌توان بازیابی کرد را مشاهده کنید. برای برنامه‌ای با چند مخزن داده، تأیید کنید که نقاط بازیابی آن‌ها سازگار هستند، نه اینکه هر مهر زمانی را جداگانه بخوانید.
در طول یک تمرین یک رخداد مرجع انتخاب کنید، مانند یک رکورد آزمایشی مجاز که در زمانی مشخص ایجاد شده است. پس از بازیابی، جدیدترین رکورد معتبر را شناسایی و فاصله را اندازه‌گیری کنید. از داده آزمایشی بی‌خطر استفاده کنید. این کار نتیجه‌ای عملی می‌دهد و فرض‌هایی را آشکار می‌کند که یک داشبورد تنها با نمایش موفقیت کار ممکن است پنهان بگذارد.
راهبردی در محدوده بودجه انتخاب کنید
پشتیبان‌گیری و بازیابی، محیط‌های آماده پشتیبان و طراحی‌های برنامه تکرارشده، هزینه و پیچیدگی را در برابر سرعت بازیابی مبادله می‌کنند. تکرار می‌تواند برخی تأخیرها را کاهش دهد اما ممکن است یک حذف تصادفی یا اشتباه برنامه را نیز بازتولید کند. یک پشتیبان که از پیکربندی عملیاتی فاصله گرفته، ریسک خودش را ایجاد می‌کند. راهبردی را بر اساس سناریوهای خرابی و اهدافی که مستند کرده‌اید انتخاب کنید.
یک سرویس کوچک با هدف چهار ساعته و یک مجموعه داده بزرگ‌تر را در نظر بگیرید که بازیابی آن به‌تنهایی شش ساعت در یک تمرین طول می‌کشد. خرید یک پورت شبکه سریع‌تر تنها یک فرضیه است: خواندن‌های ذخیره‌سازی، نوشتن‌های دریافت‌کننده و بازیابی برنامه ممکن است غالب باشند. مرحله محدودکننده اندازه‌گیری‌شده را بهبود دهید، مجموعه بازیابی را کاهش دهید یا راهبرد را تغییر دهید، سپس دوباره تمرین کنید.
بدون به خطر انداختن محیط عملیاتی تمرین کنید
از یک محیط بازیابی جداگانه و یک بازه تمرین تعریف‌شده استفاده کنید. مطمئن شوید کارهای بازیابی‌شده نمی‌توانند اعلان‌های واقعی ارسال کنند، پرداخت‌های عمومی بپذیرند یا در یکپارچه‌سازی‌های عملیاتی بنویسند. دسترسی، یکپارچگی داده و مسیرهای نماینده کاربر را پیش از کامل دانستن تمرین آزمایش کنید. فردی را شامل کنید که رویه اصلی را ننوشته است تا دستورالعمل‌های جاافتاده آشکار شوند.
یک خط زمانی از تمرین، نقطه بازیابی به‌دست‌آمده و هر وقفه‌ای که به دلیل اطلاعات در دسترس نبودن ایجاد شده نگه دارید. یک گزارش مفید نتیجه اندازه‌گیری‌شده، فاصله تا هدف و یک اقدام اصلاحی مشخص را بیان می‌کند. پس از تغییرات معنادار و در بازه‌ای متناسب با اهمیت پروژه تکرار کنید.
برنامه را در زمان خرابی قابل استفاده نگه دارید
رویه بازیابی را جایی ذخیره کنید که تیم بتواند بدون تکیه صرف بر برنامه ازکارافتاده به آن دسترسی داشته باشد. اعتبارنامه‌ها و کلیدهای رمزنگاری را در مکانی محافظت‌شده با فرایند دسترسی آزمایش‌شده نگه دارید. با تحول پروژه، مخاطبین، اندازه‌های مجموعه داده و وابستگی‌ها را به‌روزرسانی کنید. یک برنامه منسوخ می‌تواند حاشیه زمانی را پیش از آنکه بازیابی حتی آغاز شود مصرف کند.
هنگام مقایسه پیکربندی‌های SwissOctet، معماری بازیابی خود را از گزینه‌های اختیاری پشتیبان‌گیری این فهرست جدا کنید. تأیید کنید یک گزینه چه چیزی را پوشش می‌دهد، داده بازیابی کجا نگهداری می‌شود و چه کسی بازیابی را انجام می‌دهد. این فهرست RPO یا RTO یک برنامه را تعیین نمی‌کند. فرایند اندازه‌گیری‌شده شما و شرایط واقعی سرویس، مبنای آن تصمیم را فراهم می‌کنند.
چک‌لیست عملی شما.
- کارکرد تجاری بازیابی‌شده را تعریف کنید.
- اهداف جداگانه RPO و RTO را تأیید کنید.
- برای تشخیص، دسترسی، بازیابی و اعتبارسنجی بودجه در نظر بگیرید.
- جدیدترین نقطه داده قابل استفاده را اندازه‌گیری کنید.
- در یک محیط جداگانه تمرین کنید.
- شکاف‌ها را ثبت کنید و پس از تغییرات مرتبط تکرار کنید.
جزئیاتی که اهمیت دارند.
آیا RTO همان زمان کارکرد است؟+
خیر. RTO یک هدف بازیابی برای یک سناریوی وقفه است. زمان کارکرد، دسترس‌پذیری را در یک دوره اندازه‌گیری می‌کند؛ یکی دیگری را تعیین نمی‌کند.
آیا پشتیبان‌گیری ساعتی، RPO یک‌ساعته را تضمین می‌کند؟+
خیر. نسخه‌های کامل و قابل استفاده و الزامات سازگاری برنامه را بررسی کنید. کارهای ناموفق و انتقال‌های تأخیری می‌توانند شکاف داده قابل بازیابی را بزرگ‌تر کنند.
آیا هر پروژه باید از یک سرور پشتیبان استفاده کند؟+
راهبردی را بر اساس اهداف بازیابی پروژه و فرایند بازیابی اندازه‌گیری‌شده انتخاب کنید. یک سرور پشتیبان هزینه و پیچیدگی عملیاتی اضافه می‌کند و به‌طور خودکار ضروری نیست.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- NIST SP 800-34 Rev. 1: راهنمای برنامه‌ریزی احتمالی nvlpubs.nist.gov
- AWS Well-Architected: تعریف اهداف بازیابی docs.aws.amazon.com
- Microsoft Learn: تداوم کسب‌وکار، دسترس‌پذیری بالا و بازیابی از فاجعه learn.microsoft.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.