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

- Link: https://itnetworkcare.ir/%d8%a8%da%a9%d8%a7%d9%be-%db%b3-%db%b2-%db%b1-%d9%88-%db%b3-%db%b2-%db%b1-%db%b1-%db%b0%d8%9b-%d8%b7%d8%b1%d8%a7%d8%ad%db%8c-%d9%86%d8%b3%d8%ae%d9%87-%d9%be%d8%b4%d8%aa%db%8c%d8%a8%d8%a7%d9%86-%d9%85/
- Published: 2026-10-04T18:32:57+03:30
- Author: علیرضا بهشتی

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

[⌊ذخیره‌سازی و طراحی بکاپ ۳-۲-۱ سازمانی⌉⌊ذخیره‌سازی و طراحی بکاپ ۳-۲-۱ سازمانی⌉[

Photo by [İsmail Enes Ayhan](https://unsplash.com/@ismailenesayhan?utm_source=WP+Agent&utm_medium=referral)
on [Unsplash](https://unsplash.com/?utm_source=WP+Agent&utm_medium=referral)

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

سه نسخه یعنی داده اصلی و دست‌کم دو کپی پشتیبان. دو نوع رسانه کمک می‌کند خرابی یک
فناوری یا سامانه همه نسخه‌ها را هم‌زمان از بین نبرد. یک نسخه خارج از محل، ریسک آتش‌سوزی،
سرقت یا خرابی کامل سایت را کاهش می‌دهد. دو 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 درباره ۳-۲-۱-۱-۰](https://www.veeam.com/blog/321-backup-rule.html)
را ببینید. برای مقایسه زیرساخت نیز [سرور فیزیکی و مجازی](https://itnetworkcare.ir/physical-vs-virtual-server/)
و صفحه [بکاپ و بازیابی اطلاعات](https://itnetworkcare.ir/service/backup-data-recovery/)
مفید است.

## آزمون عملی بازیابی؛ فراتر از موفق بودن Job

ماهانه یک فایل نمونه و در بازه مناسب یک ماشین مجازی آزمایشی را از نسخه پشتیبان بازیابی
کنید. زمان بازیابی، صحت فایل و امکان ورود به سرویس را ثبت کنید. برای محافظت در برابر
باج‌افزار، جداسازی دسترسی مخزن بکاپ از حساب‌های روزمره ضروری است.

بخش مکمل: [خدمات بکاپ و بازیابی اطلاعات](https://itnetworkcare.ir/service/backup-data-recovery/)
و [راه‌اندازی حفاظت Endpoint سازمانی](https://itnetworkcare.ir/eset-business-antivirus-installation-license/).

## فرم ارزیابی استقلال نسخه‌های پشتیبان

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

### دامنه و تناوب آزمون بازیابی را چگونه انتخاب کنیم؟

برای همه شرکت‌ها یک برنامه زمانی ثابت کافی نیست. اهمیت سرویس، تعداد تغییرات و هدف
بازیابی را مبنا قرار دهید و پس از تغییر مهم، سناریوی مربوط را بازبینی کنید. آزمون
باید نتیجه و مسئول تأیید داشته باشد. برای شناخت وابستگی سرویس‌ها، [راهنمای راه‌اندازی سرور](https://itnetworkcare.ir/server-setup/)
و برای حفاظت زیرساخت [چک‌لیست امنیت شبکه](https://itnetworkcare.ir/network-security-tips/)
را بخوانید.