بکاپ ۳-۲-۱ و ۳-۲-۱-۱-۰؛ طراحی نسخه پشتیبان مقاوم در برابر باج‌افزار

وجود فایل Backup به معنی امکان بازیابی نیست. یک طراحی مناسب باید خرابی سخت‌افزار، حذف اشتباه، آلودگی باج‌افزاری و از دست رفتن محل اصلی را پوشش دهد. قانون ۳-۲-۱ یک چارچوب ساده برای حذف نقطه شکست مشترک است و نسخه ۳-۲-۱-۱-۰ آن را برای تهدیدهای جدید کامل‌تر می‌کند.

اعداد ۳-۲-۱ چه می‌گویند؟

سه نسخه یعنی داده اصلی و دست‌کم دو کپی پشتیبان. دو نوع رسانه کمک می‌کند خرابی یک فناوری یا سامانه همه نسخه‌ها را هم‌زمان از بین نبرد. یک نسخه خارج از محل، ریسک آتش‌سوزی، سرقت یا خرابی کامل سایت را کاهش می‌دهد. دو Repository روی همان Storage یا همان Domain امنیت مستقل ایجاد نمی‌کنند.

چرا ۳-۲-۱-۱-۰ مطرح شد؟

راهنمای Veeam یک نسخه Immutable یا Air-gapped و نتیجه بازیابی بدون خطا را به مدل کلاسیک اضافه می‌کند. «۱» دوم یعنی حداقل یک کپی که تغییر یا حذف آن برای مهاجم دشوار باشد. «۰» یعنی آزمون Recovery خطای تأییدنشده باقی نگذارد. Immutable بودن باید با دسترسی جداگانه، Retention مشخص و محدودیت حذف همراه باشد.

RPO و RTO را پیش از خرید تعیین کنید

RPO بیشترین میزان داده قابل از دست رفتن و RTO زمان قابل‌قبول برای بازگشت سرویس است. فایل‌سرور، Domain Controller، ERP و VoIP ارزش و زمان بازیابی یکسان ندارند. ابتدا سرویس‌ها را رتبه‌بندی کنید، سپس Job، Retention، پهنای باند و ظرفیت را بر اساس آن بسازید.

چک‌لیست طراحی

• فهرست VMها، سرورها، دیتابیس‌ها و داده‌های حیاتی
• مالک سرویس و اولویت بازیابی هر مورد
• Repository محلی سریع برای Recovery کوتاه
• نسخه Off-site با حساب و مسیر دسترسی مستقل
• یک کپی Immutable یا Offline
• رمزگذاری، ثبت کلیدها و کنترل دسترسی
• هشدار شکست Job و گزارش ظرفیت

آزمون بازیابی را از Backup جدا کنید

موفقیت Job فقط نشان می‌دهد فرآیند نوشتن بدون خطای گزارش‌شده تمام شده است. هر ماه نمونه‌ای از فایل، VM یا دیتابیس را در محیط ایزوله بازیابی کنید. زمان واقعی Recovery، سازگاری Application و مراحل دستی را ثبت کنید. برای DC یا دیتابیس، روش بازیابی Application-aware باید از قبل مستند باشد.

پرسش‌های رایج

آیا Snapshot بکاپ است؟

Snapshot معمولاً به Storage و ماشین اصلی وابسته است و برای بازگشت کوتاه‌مدت مفید است؛ به‌تنهایی نسخه مستقل خارج سایت نیست.

آیا NAS دوم کافی است؟

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

نمونه ماتریس بازیابی

برای هر سرویس چهار ستون بسازید: آخرین Backup موفق، محل کپی دوم، RPO/RTO و تاریخ آخرین Restore Test. اگر فایل‌سرور هر شب Backup می‌شود ولی آخرین آزمون بازیابی شش ماه قبل بوده، وضعیت آن «تأییدشده» نیست. نتیجه Restore، مدت انجام و خطاهای Application را ثبت و اقدام اصلاحی را به مسئول مشخص واگذار کنید.

منابع و مطالعه بیشتر

توضیح رسمی Veeam درباره ۳-۲-۱-۱-۰ را ببینید. برای مقایسه زیرساخت نیز سرور فیزیکی و مجازی و صفحه بکاپ و بازیابی اطلاعات مفید است.