مقاله 03 / بکاپ و بازیابی
RPO و RTO چیست؟ طراحی بکاپ و بازیابی برای سایت و فروشگاه
مشخصات پیشنهادی انتشار
- عنوان سئو
- RPO و RTO چیست؟ راهنمای بکاپ و بازیابی | نگهبان وب
- توضیح متا
- تفاوت RPO و RTO را با مثال فروشگاه بشناسید؛ برای بکاپ مستقل، دوره نگهداری، آزمون بازیابی و کنترل داده ازدست‌رفته برنامه قابل سنجش طراحی کنید.
- مسیر پیشنهادی
- /blog/backup-rpo-rto
- عبارت اصلی
- RPO و RTO چیست
- تصویر
- backup-rpo-rto.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
یک فایل بکاپ موفق، به‌تنهایی تضمین نمی‌کند که کسب‌وکار پس از حادثه به‌موقع برگردد. باید بدانید آخرین داده قابل بازیابی مربوط به چه زمانی است و بازگرداندن سرویس چقدر طول می‌کشد. RPO و RTO دو هدف‌اند که این نیازها را قابل گفت‌وگو و قابل آزمون می‌کنند.
RPO هدف مربوط به مقدار قابل تحمل از دست رفتن داده در قالب زمان است. RTO هدف مربوط به مدت قابل تحمل برای بازگرداندن سرویس است. این دو را مدیر کسب‌وکار و تیم فنی باید با هم تعیین کنند؛ فاصله زمانی بکاپ‌ها یا سرعت یک ابزار، به‌تنهایی پاسخ نهایی نیست.
فرض کنید فروشگاهی در ساعت ۱۵ دچار خرابی می‌شود و آخرین نقطه سالم قابل بازیابی آن ساعت ۱۴:۴۵ است. در این مثال، فاصله داده بالقوه ازدست‌رفته ۱۵ دقیقه است. اگر هدف RPO پنج دقیقه باشد، این وضعیت هدف را تأمین نکرده، حتی اگر فایل بکاپ کاملاً سالم باشد.
حالا فرض کنید فروشگاه بعد از دو ساعت دوباره سفارش می‌گیرد. اگر هدف RTO یک ساعت بوده، زمان بازیابی هم از هدف عبور کرده است. این مثال فرضی نشان می‌دهد سلامت فایل، تازگی داده و سرعت بازگشت سرویس سه موضوع متفاوت‌اند.
| مفهوم | سؤال کسب‌وکاری | روش بررسی |
|---|---|---|
| RPO | تا چه فاصله‌ای از داده اخیر را می‌توانیم از دست بدهیم؟ | مقایسه زمان رخداد با آخرین نقطه سالم بازیابی |
| RTO | تا چه مدت می‌توانیم خدمت را متوقف نگه داریم؟ | اندازه‌گیری مسیر اعلام حادثه تا بازگشت خدمت توافق‌شده |
| دوره نگهداری | چند نسخه تاریخی لازم داریم؟ | بررسی سناریوهای حذف اشتباه و خرابی دیرکشف‌شده |
از سفارش و پرداخت شروع کنید
فهرست داده‌ها را براساس اثرشان بر کار تهیه کنید: سفارش، پرداخت، فایل بارگذاری‌شده، حساب کاربر، تنظیمات و کلیدهای لازم برای بازسازی. برای هر گروه مشخص کنید آیا می‌توان آن را دوباره ساخت و بازسازی چقدر هزینه دارد.
ممکن است صفحات کش‌شده قابل تولید مجدد باشند، اما سفارش ثبت‌شده چنین نباشد. همین تفاوت باید روی دفعات بکاپ و اولویت بازیابی اثر بگذارد. اگر سیستم به درگاه یا سرویس بیرونی وابسته است، روش تطبیق تراکنش‌ها پس از بازگشت را نیز از قبل بنویسید.
بکاپ منطقی، فیزیکی و بازیابی نقطه‌ای
انتخاب روش به دیتابیس، حجم، سرعت رشد و هدف بازیابی بستگی دارد. خروجی منطقی می‌تواند برای انتقال داده و برخی سناریوهای بازیابی مفید باشد. بکاپ فیزیکی و آرشیو پیوسته تغییرات نیز در سامانه‌های مناسب امکان بازیابی دقیق‌تری می‌دهند.
برای نمونه، PostgreSQL روش‌هایی برای آرشیو WAL و بازیابی تا یک نقطه زمانی دارد. این قابلیت نیازمند زنجیره سالم بکاپ و فایل‌های لازم است و با داشتن یک dump روزانه به‌طور خودکار ایجاد نمی‌شود. جزئیات نسخه و سازگاری ابزارها باید در طراحی بررسی شود.
نسخه‌ای مستقل نگه دارید
اگر همه نسخه‌ها روی همان دیسک سرور اصلی باشند، خرابی آن دیسک می‌تواند داده و بکاپ را هم‌زمان از بین ببرد. مقصد مستقل، کنترل دسترسی جدا و سیاست نگهداری روشن، دامنه آسیب یک رخداد را محدود می‌کند. فقط تغییر نام یک پوشه، استقلال ایجاد نمی‌کند.
دسترسی حذف نسخه‌های بکاپ را نیز بررسی کنید. اگر حساب برنامه بتواند همه نسخه‌های تاریخی را پاک کند، یک خطا یا نفوذ می‌تواند مسیر بازیابی را خراب کند. رمزگذاری باید همراه با مدیریت و دسترسی قابل بازیابی به کلیدها طراحی شود؛ بکاپ رمزگذاری‌شده بدون کلید قابل استفاده نیست.
یک آزمون بازیابی واقعی چگونه است؟
در محیطی جدا و کنترل‌شده، بکاپ انتخابی را بازیابی کنید. پایگاه داده را باز کنید، برنامه را اجرا کنید و یک مسیر کاری نمونه را بدون ایجاد تراکنش واقعی بررسی کنید. پیامک، ایمیل و پرداخت واقعی باید در این محیط غیرفعال یا به سرویس آزمایشی متصل باشند.
زمان مراحل را جدا ثبت کنید: پیدا کردن نسخه، دریافت فایل، بازسازی زیرساخت، بازیابی داده و تأیید خدمت. ممکن است خود restore سریع باشد، اما انتظار برای دسترسی یا دانلود فایل بیشتر زمان را بگیرد. برنامه بهبود باید روی گلوگاه واقعی تمرکز کند.
چه چیزهایی باید پایش شوند؟
- موفقیت و مدت اجرای کار بکاپ؛
- سن آخرین نسخه سالم و قابل دسترسی؛
- ظرفیت مقصد و رشد حجم نسخه‌ها؛
- شکست انتقال یا رمزگذاری؛
- تاریخ آخرین آزمون بازیابی و مشکلات باز آن.
صرفاً هشدار «فرمان با کد صفر تمام شد» کافی نیست. نتیجه آزمون و امکان دسترسی به نسخه مستقل هم باید معلوم باشد. چک‌لیست بکاپ قابل اتکا می‌تواند فهرست اولیه کنترل‌ها باشد.
پرسش‌های رایج
آیا replica جای بکاپ را می‌گیرد؟
معمولاً خیر. حذف یا تغییر اشتباه می‌تواند به replica هم منتقل شود. replication و بکاپ برای سناریوهای متفاوتی طراحی می‌شوند.
آیا باید برای همه داده‌ها یک RPO یکسان تعیین کنیم؟
الزامی نیست. داده‌های تراکنشی و فایل‌های قابل تولید مجدد می‌توانند اهداف متفاوتی داشته باشند؛ وابستگی آن‌ها هنگام بازیابی را هم ببینید.
برای طراحی برنامه متناسب با داده‌های خود، درخواست بررسی بکاپ و بازیابی را با حجم دیتابیس، نرخ تغییر و زمان توقف قابل تحمل ثبت کنید.
