طراحی و اجرای استراتژی پشتیبان‌گیری

توضیحات

طراحی و اجرای استراتژی پشتیبان‌گیری

۱) تعریف RPO و RTO و طراحی چارچوب استراتژی بک‌آپ

تحلیل نیاز کسب‌وکار برای تعیین RPO و RTO هر سرویس، طبقه‌بندی داده‌ها بر اساس حیثیت (Tiering)، و طراحی استراتژی متناسب شامل روش بک‌آپ، Schedule و Retention.

استراتژی بک‌آپ با این سؤال شروع می‌شود: “اگر الان همه چیز از بین برود، چقدر زمان و داده می‌توانیم از دست بدهیم؟” پاسخ این سؤال برای دیتابیس مالی (RPO=15min, RTO=2h) با فایل‌سرور اشتراکی (RPO=24h, RTO=48h) کاملاً متفاوت است. ما در یک جلسه تحلیلی، تمام سرویس‌های شما را بر اساس Impact مالی و عملیاتی طبقه‌بندی می‌کنیم: Tier 1 (بحرانی: RPO نزدیک به صفر، RTO زیر ۱ ساعت)، Tier 2 (مهم: RPO چند ساعت، RTO زیر ۸ ساعت)، Tier 3 (عادی: RPO روزانه، RTO ۲۴-۴۸ ساعت). سپس برای هر Tier، روش بک‌آپ مناسب را طراحی می‌کنیم: برای Tier 1 از ترکیب Transaction Log Backup هر ۱۵ دقیقه + Full هفتگی، برای Tier 2 از Incremental روزانه + Synthetic Full هفتگی، و برای Tier 3 از Full هفتگی ساده. این چارچوب مکتوب، نقشه راه تمام Job های بک‌آپ شما خواهد بود، نه یک سری تنظیمات سلیقه‌ای و پراکنده.

2) طراحی و پیکربندی Job های بک‌آپ (VM، فایل، دیتابیس)

ساخت Job های مجزا برای VM ها، فایل‌سرورها و دیتابیس‌ها با روش بک‌آپ مناسب (Application-Aware، Crash-Consistent)، تنظیم Proxy، Schedule و Retry Policy.

Job بک‌آپ مثل یک ماشین دقیق است؛ اگر یک چرخ‌دنده آن درست تنظیم نباشد، کل فرآیند از کار می‌افتد. Job مخصوص VM باید Application-Aware Processing فعال داشته باشد تا دیتابیس داخل VM (SQL، Exchange، Oracle) در لحظه بک‌آپ Quiesce شود و Transaction Log ها Truncate شوند. Job فایل‌سرور باید Indexing فعال داشته باشد تا بشود یک فایل تکی را بدون Restore کل VM برگرداند. Job دیتابیس فیزیکی باید با Agent اختصاصی بک‌آپ گرفته شود، نه صرفاً کپی فایل‌های دیتابیس. تیم ما برای هر سرویس، Job مناسب را طراحی می‌کند: انتخاب Source (کل VM، Volume مشخص، یا فولدر خاص)، انتخاب Proxy نزدیک‌ترین به منبع، تنظیم Schedule (روزانه، هفتگی، یا هر ۴ ساعت)، و Retry Policy (اگر Job شکست خورد، ۳ بار با فاصله ۱۰ دقیقه تلاش مجدد کند). همچنین Maximum Concurrent Tasks را متناسب با منابع Proxy تنظیم می‌کنیم تا Job ها هم‌دیگر را گرسنه نگذارند.

3) تنظیم زنجیره بک‌آپ: Full، Incremental، Differential و Synthetic Full

طراحی زنجیره بهینه برای تعادل بین سرعت بک‌آپ، فضای مصرفی و سرعت Restore، با ترکیب Full هفتگی، Incremental روزانه و Synthetic Full.

انتخاب روش زنجیره بک‌آپ، یک معامله سه‌ضلعی است بین: سرعت بک‌آپ، فضای مصرفی، و سرعت Restore. روش Forward Incremental با Full هفتگی، سریع‌ترین بک‌آپ روزانه را دارد (فقط تغییرات روزانه کپی می‌شود) اما Restore به چند فایل نیاز دارد و کندتر است. Reverse Incremental همیشه آخرین وضعیت را Full نگه می‌دارد و Restore سریع دارد، اما بک‌آپ روزانه سنگین‌تر است و فشار بیشتری به Repository وارد می‌کند. Synthetic Full هم Full هفتگی را بدون مراجعه مجدد به سرور تولید، از روی Incremental های موجود روی Repository می‌سازد، عالی برای کاهش بار شبکه، اما پردازش سنگین روی Repository دارد. تیم ما برای هر Tier بهترین زنجیره را انتخاب می‌کند: مثلاً Forward Incremental + Synthetic Full هفتگی برای VM های معمولی، Reverse Incremental برای دیتابیس بحرانی که Restore سریع می‌خواهد، و Forever Forward Incremental (بدون Full) برای محیط‌های با پهنای باند محدود. هر Job با Retention Policy مشخص: نگهداری ۷ روز Incremental + ۴ هفته Full + ۱۲ ماه Full ماهانه.

4) پیکربندی Backup Verification و SureBackup

تنظیم Health Check خودکار روی فایل‌های بک‌آپ (تأیید یکپارچگی داده)، پیکربندی SureBackup برای تست بازیابی VM در محیط ایزوله، و زمان‌بندی Verification هفتگی.

بک‌آپ تست‌نشده فقط یک فایل بی‌ارزش روی دیسک است. Health Check خودکار، فایل‌های بک‌آپ را بایت‌به‌بایت می‌خواند و یکپارچگی Checksum را تأیید می‌کند تا مطمئن شویم Bit Rot یا خرابی خاموش رخ نداده. اما Health Check فقط می‌گوید فایل سالم است، نمی‌گوید آیا VM واقعاً با آن فایل بالا می‌آید. SureBackup (در Veeam) یا Restoration Test (در Proxmox) یک قدم فراتر می‌رود: یک Virtual Lab ایزوله می‌سازد، VM را از فایل بک‌آپ در آن بالا می‌آورد، منتظر می‌ماند تا سرویس‌ها Start شوند، یک Ping به VM می‌زند، حتی می‌تواند یک اسکریپت تست دیتابیس اجرا کند، سپس VM را خاموش و محیط را پاک می‌کند. همه اینها خودکار، مثلاً هر یک‌شنبه صبح. تیم ما SureBackup را برای VM های بحرانی پیکربندی می‌کند، Application Group تعریف می‌نماید (VM های وابسته مثل Domain Controller + SQL + Web با هم تست شوند)، و نتیجه را با اسکرین‌شات از کنسول VM در گزارش ایمیل می‌کند. این یعنی هر هفته یک تست Disaster Recovery کامل، بدون دخالت انسان.

5) پیکربندی گزارش‌دهی و هشدار (Reporting & Alerting)

تنظیم ایمیل گزارش روزانه/هفتگی از وضعیت تمام Job ها، پیکربندی هشدار فوری برای Job های شکست‌خورده، و طراحی Dashboard مدیریتی با معیارهای کلیدی.

بک‌آپی که شکست می‌خورد و کسی متوجه نمی‌شود، از نداشتن بک‌آپ هم بدتر است، چون اعتماد کاذب ایجاد می‌کند. سیستم گزارش‌دهی باید دو لایه داشته باشد: لایه اول، هشدار فوری (واقعی) برای Job های شکست‌خورده که ظرف ۵ دقیقه از طریق ایمیل، پیامک یا تلگرام به تیم فنی اطلاع دهد. لایه دوم، گزارش خلاصه روزانه یا هفتگی که وضعیت همه Job ها، فضای مصرفی Repository، نرخ رشد، و وضعیت Tape ها را در یک نگاه نشان دهد. تیم ما Notification را روی Backup Server پیکربندی می‌کند (SMTP معتبر، گروه‌بندی هشدارها بر اساس Severity)، و اگر Veeam ONE یا ابزار مانیتورینگ مشابه در دسترس باشد، یک Dashboard سفارشی با Key Metrics می‌سازد: Success Rate هفتگی، Top 10 VM های پرمصرف Repository، تخمین زمان پر شدن فضای آزاد، و Job های دارای Warning مکرر. نتیجه: شنبه صبح، یک نگاه به ایمیل یعنی خیالتان از ۴۸ ساعت گذشته راحت باشد.

6) شبیه‌سازی فاجعه و ممیزی استراتژی (Disaster Simulation & Strategy Audit)
اجرای یک شبیه‌سازی کامل از سناریوی از دست رفتن زیرساخت تولید، اندازه‌گیری RTO واقعی، و اصلاح استراتژی بر اساس نتایج.

استراتژی روی کاغذ با واقعیت در لحظه بحران، اغلب فاصله زیادی دارد. RTO ای که ۴ ساعت تخمین زده شده، ممکن است در عمل ۱۲ ساعت شود، چون کسی فکر نکرده بود Restore یک VM دیتابیس ۲ ترابایتی از Tape چقدر طول می‌کشد. تیم ما یک روز کامل، سناریوی فاجعه را با شما شبیه‌سازی می‌کند: فرض می‌کنیم سایت تولید کاملاً از بین رفته. ساعت صفر اعلام می‌شود. تیم شما باید با استفاده از Runbook و زیرساخت بک‌آپ، سرویس‌های بحرانی را برگرداند. ما زمان واقعی هر مرحله را اندازه می‌گیریم: چقدر طول کشید Backup Server بالا بیاید؟ اولین VM چند دقیقه‌ای Restore شد؟ دیتابیس کی پذیرای Connection شد؟ در پایان، یک گزارش Gap Analysis ارائه می‌دهیم: RTO هدف در برابر RTO واقعی، گلوگاه‌ها (مثلاً پهنای باند ناکافی بین Repository و Host، یا نبود Proxy یدکی)، و توصیه‌های اصلاحی. استراتژی بعد از این ممیزی، دیگر یک سند تئوریک نیست، یک برنامه عملیاتی تست‌شده است.