اینجاست که قانون بکاپ 3-2-1 اهمیت پیدا می‌کند؛ یک استراتژی شناخته‌شده برای طراحی سیستم بکاپ سازمانی که بر نگهداری چند نسخه مستقل از اطلاعات، استفاده از بسترهای ذخیره‌سازی متفاوت و انتقال حداقل یک نسخه به خارج از محل اصلی تأکید دارد. بااین‌حال، اجرای صحیح این قانون فقط به داشتن «سه نسخه از فایل‌ها» خلاصه نمی‌شود. RPO، RTO، Retention، امنیت دسترسی و امکان Restore واقعی مشخص می‌کنند که سیستم پشتیبان‌گیری در زمان بحران واقعاً قابل اعتماد است یا خیر.
در ادامه بررسی می‌کنیم قانون 3-2-1 بکاپ دقیقاً چیست، هر عدد چه مفهومی دارد و چگونه می‌توان بر اساس اندازه شرکت، نوع داده‌ها و سطح حساسیت سرویس‌ها، یک معماری Backup مطمئن و قابل بازیابی طراحی کرد.
قانون پشتیبان‌گیری 3-2-1 چیست؟
قانون پشتیبان‌گیری 3-2-1 یک استراتژی پشتیبان‌گیری است که بر اساس آن باید حداقل سه نسخه از داده‌های مهم، روی دو بستر یا رسانه ذخیره‌سازی متفاوت نگهداری شود و حداقل یک نسخه نیز خارج از محل اصلی سازمان قرار داشته باشد. هدف این روش، کاهش احتمال از دست رفتن هم‌زمان داده اصلی و نسخه‌های پشتیبان در یک حادثه واحد است.
منطق این قانون بر کاهش وابستگی نسخه‌ها به یک نقطه خرابی مشترک استوار است. هرچه نسخه‌های اطلاعات از نظر محل، بستر و دسترسی مستقل‌تر باشند، احتمال اینکه یک خرابی واحد همه آن‌ها را از بین ببرد کمتر می‌شود.
عدد 3؛ سه نسخه از اطلاعات
منظور از عدد 3 معمولاً این ترکیب است:
- نسخه اصلی یا Production Data
- نسخه پشتیبان اول
- نسخه پشتیبان دوم
برای مثال، اگر دیتابیس حسابداری روی سرور اصلی قرار دارد، یک نسخه می‌تواند روی Backup Repository داخلی و نسخه دیگر روی مقصدی مستقل نگهداری شود. سه کپی روی یک Storage واحد، از نظر تاب‌آوری معادل سه نسخه مستقل نیست؛ زیرا خرابی همان زیرساخت می‌تواند هر سه را تحت تأثیر قرار دهد.
عدد 2؛ دو بستر یا رسانه متفاوت
عدد 2 به این معناست که نسخه‌ها نباید همگی به یک فناوری یا یک نقطه خرابی مشترک وابسته باشند. ترکیب‌هایی مانند Storage اصلی + NAS، Disk Backup + Tape یا Local Repository + Object Storage نمونه‌هایی از این رویکرد هستند.
هدف صرفاً متفاوت بودن نام تجهیزات نیست؛ مهم این است که خرابی یکی از بسترها، دسترسی به تمام نسخه‌های اطلاعات را از بین نبرد.
عدد 1؛ یک نسخه خارج از محل اصلی
حداقل یک نسخه باید Off-site باشد؛ یعنی در محلی مستقل از زیرساخت اصلی سازمان نگهداری شود. این مقصد می‌تواند دیتاسنتر دوم، شعبه دیگر، فضای ابری یا یک محل فیزیکی مستقل باشد.
| عدد | مفهوم | نمونه سازمانی |
|---|---|---|
| 3 | سه نسخه از داده‌ها | Production + Backup اول + Backup دوم |
| 2 | دو بستر متفاوت | Server Storage + NAS / Object Storage |
| 1 | یک نسخه خارج از محل اصلی | Cloud، دیتاسنتر دوم یا شعبه دیگر |
پس قانون 3-2-1 درباره «زیاد کردن تعداد فایل‌های کپی‌شده» نیست؛ هدف، جدا کردن نقاط خرابی و ایجاد مسیرهای مستقل برای بازیابی است.
چرا شرکت‌ها به قانون Backup 3-2-1 نیاز دارند؟
در یک شرکت، از دست رفتن اطلاعات می‌تواند سرویس‌های مالی، فایل‌های مشترک یا ماشین‌های مجازی را متوقف کند. سؤال این است: اگر سرور اصلی همین امروز از دسترس خارج شود، آیا نسخه‌ای مستقل و قابل بازیابی دارید؟
خرابی سخت‌افزار یا Storage
هارددیسک، SSD، کنترلر RAID، Storage و حتی خود سرور ممکن است خراب شوند. اگر Backup روی همان تجهیز یا زیرساخت وابسته قرار داشته باشد، یک خرابی گسترده می‌تواند چند نسخه را هم‌زمان از دسترس خارج کند.
خطای انسانی و خرابی نرم‌افزار
حذف اشتباهی فایل، تغییر ناخواسته تنظیمات، Corruption دیتابیس یا به‌روزرسانی ناموفق از سناریوهای رایج هستند. در این وضعیت، ارزش Backup زمانی مشخص می‌شود که بتوان نسخه سالم مربوط به قبل از تغییر را بازگرداند.
باج‌افزار و نفوذ امنیتی
در حملات Ransomware، Backup Repositoryها نیز ممکن است حذف یا رمزگذاری شوند. اگر همه نسخه‌ها با همان حساب مدیریتی قابل دسترسی باشند، تعداد بیشتر Backup الزاماً مقاومت بیشتری ایجاد نمی‌کند.
حوادث فیزیکی
آتش‌سوزی، آب‌گرفتگی، سرقت یا آسیب گسترده به اتاق سرور می‌تواند چند تجهیز را هم‌زمان از دسترس خارج کند. نسخه Off-site برای کاهش همین ریسک طراحی می‌شود.
در نتیجه، ارزش اصلی قانون 3-2-1 در کاهش Single Point of Failure است؛ یعنی سازمان به یک دستگاه، یک Storage یا یک محل برای بازیابی اطلاعات وابسته نمی‌ماند.
چرا RAID، Snapshot و Replication جای Backup را نمی‌گیرند؟
RAID، Snapshot و Replication ابزارهای ارزشمندی هستند، اما هدف هرکدام با Backup تفاوت دارد. برای سنجش ساده، بپرسید: اگر یک فایل مهم امروز حذف شود یا دیتابیس به وضعیت خراب تغییر کند، آیا می‌توانید نسخه سالم مربوط به قبل از حادثه را برگردانید؟ اگر پاسخ منفی است، آن راهکار به‌تنهایی Backup محسوب نمی‌شود.
تفاوت RAID با Backup
RAID بسته به سطح انتخاب‌شده می‌تواند تحمل خرابی یک یا چند دیسک را افزایش دهد و Availability را حفظ کند. اما حذف فایل، خرابی منطقی دیتابیس یا رمزگذاری داده‌ها معمولاً روی همان آرایه نیز اعمال می‌شود.
خلاصه روشن است: RAID برای تحمل خرابی دیسک است؛ Backup برای بازگرداندن اطلاعات به وضعیت سالم قبلی. این دو مکمل یکدیگرند.
آیا Snapshot همان Backup است؟
Snapshot وضعیت داده را در یک نقطه زمانی ثبت می‌کند و برای Rollback سریع فایل، Volume یا ماشین مجازی مفید است. اما اگر Snapshot و داده اصلی روی همان Storage باشند، خرابی کامل آن Storage می‌تواند هر دو را از بین ببرد. بنابراین Snapshot بهتر است مکمل Backup مستقل باشد.
Replication چه تفاوتی با Backup دارد؟
Replication داده یا سرویس را به سیستم یا سایت دیگری منتقل می‌کند و برای کاهش Downtime و Disaster Recovery بسیار مفید است. بااین‌حال، حذف اشتباهی، Corruption یا داده آلوده ممکن است به Replica نیز منتقل شود. نگهداری نسخه‌های تاریخی و مستقل همان چیزی است که Backup به این معماری اضافه می‌کند.
| راهکار | هدف اصلی | نسخه تاریخی | مناسب برای حذف اشتباهی | کاربرد اصلی |
|---|---|---|---|---|
| RAID | تحمل خرابی دیسک | خیر | خیر | Availability |
| Snapshot | بازگشت سریع | محدود | بله، در صورت وجود Snapshot سالم | Recovery سریع |
| Replication | کپی سرویس در مقصد دیگر | معمولاً محدود | وابسته به طراحی | HA و DR |
| Backup | نگهداری نسخه مستقل | بله | بله | حفاظت و بازیابی داده |
قبل از طراحی سیستم بکاپ سازمان چه چیزهایی باید مشخص شود؟
طراحی سیستم بکاپ نباید از خرید NAS، Tape یا Backup Server شروع شود. ابتدا باید بدانید از چه داده‌ای محافظت می‌کنید، چه مقدار از دست رفتن اطلاعات قابل قبول است و سرویس‌ها چه مدت می‌توانند از دسترس خارج بمانند. دو سازمان با حجم داده مشابه ممکن است به معماری کاملاً متفاوتی نیاز داشته باشند.
داده‌ها و سرویس‌های حیاتی را مشخص کنید
دیتابیس‌های مالی، File Server، ماشین‌های مجازی، Active Directory و سامانه‌های سازمانی می‌توانند Workload حیاتی باشند. سرویس‌ها را بر اساس اهمیت کسب‌وکار، سرعت تغییر داده و اثر Downtime دسته‌بندی کنید.
RPO چیست؟
RPO یا Recovery Point Objective مشخص می‌کند سازمان حداکثر چه مقدار از داده‌های اخیر را می‌تواند از دست بدهد. اگر RPO یک سیستم یک ساعت باشد، فاصله ایجاد Restore Pointها باید طوری باشد که در بدترین حالت بیش از یک ساعت داده از دست نرود.
برای مثال، Backup روزانه برای سیستمی که فقط تحمل از دست رفتن یک ساعت تراکنش را دارد مناسب نیست. بنابراین Frequency باید از RPO واقعی کسب‌وکار استخراج شود، نه از یک برنامه عمومی.
RTO چیست؟
RTO یا Recovery Time Objective مشخص می‌کند یک سرویس پس از حادثه حداکثر چه مدت می‌تواند از دسترس خارج باشد. اگر RTO سامانه فروش دو ساعت است، معماری Backup باید امکان بازگرداندن آن را در همین بازه فراهم کند.
به‌صورت خلاصه:
- RPO می‌پرسد: چقدر داده می‌توانیم از دست بدهیم؟
- RTO می‌پرسد: چقدر زمان برای بازیابی قابل قبول است؟
Retention Policy چیست؟
Retention Policy تعیین می‌کند نسخه‌های Backup چه مدت نگهداری شوند. برای نمونه، ممکن است نسخه‌های روزانه 14 روز، هفتگی 8 هفته و ماهانه 12 ماه حفظ شوند. Retention کوتاه می‌تواند Restore Point موردنیاز را حذف کند و Retention بیش از حد نیز هزینه و ظرفیت مصرفی را بالا می‌برد.
ظرفیت، رشد داده و Backup Window
در Capacity Planning علاوه بر حجم فعلی، نرخ رشد داده، تعداد Restore Pointها، Retention، Compression و Deduplication را لحاظ کنید. Backup Window و پهنای باند نیز روی انتقال داده به مقصد Off-site یا Cloud اثر مستقیم دارند.
چگونه یک سیستم بکاپ 3-2-1 برای شرکت طراحی کنیم؟
پس از مشخص شدن نیازهای بازیابی، نوبت طراحی مسیرهای مستقل می‌رسد. هدف این است که خرابی یک جزء، تمام راه‌های Recovery را مسدود نکند.
مرحله اول؛ محدوده Production را مشخص کنید
فهرست Workloadهای حیاتی و مالک هر سرویس را نهایی کنید و مشخص کنید چه داده‌ای باید Backup شود. در قانون 3-2-1، داده اصلی یکی از سه نسخه محسوب می‌شود و دو نسخه پشتیبان دیگر باید مستقل از آن طراحی شوند.
مرحله دوم؛ Local Backup سریع ایجاد کنید
اولین Backup معمولاً روی Backup Server، NAS یا Repository داخلی قرار می‌گیرد تا Restoreهای روزمره سریع باشند.
Production Server → Local Backup Repository
این Repository نباید همان Storageای باشد که داده اصلی روی آن قرار دارد؛ زیرا در آن صورت همچنان نقطه خرابی مشترک دارید.
مرحله سوم؛ Backup Copy مستقل بسازید
نسخه دوم باید روی مقصدی جدا مانند NAS مستقل، Backup Server دوم، Object Storage، Tape یا Repository سایت دیگر قرار گیرد. Job مربوط به Backup Copy نیز باید جداگانه پایش شود؛ موفق بودن Backup اول، موفق بودن نسخه دوم را تضمین نمی‌کند.
مرحله چهارم؛ یک نسخه Off-site داشته باشید
حداقل یک نسخه را خارج از محل اصلی نگهداری کنید. دو Backup Server در یک رک یا یک ساختمان از نظر جغرافیایی مستقل نیستند. مقصد Off-site باید حادثه محل اصلی را به‌صورت مشترک تجربه نکند.
مشاهده کانفیگ‌های پیشنهادی
مرحله پنجم؛ دسترسی Backup را از Production جدا کنید
Accountهای Backup را تا حد ممکن مستقل کنید، دسترسی Repository را محدود نگه دارید و Permissionها را بر اساس Least Privilege تعریف کنید. یک حساب مدیریتی نباید بتواند هم Production و هم Backupها را حذف کند.
مرحله ششم؛ Jobها و ظرفیت را مانیتور کنید
وضعیت آخرین Backup، مدت اجرای Job، فضای Repository، خطاهای اتصال، Backup Copy و تعداد Restore Pointهای معتبر باید پایش شوند. پر شدن Repository یا توقف چندروزه Copy Job می‌تواند بدون هشدار مناسب، سازمان را از سیاست 3-2-1 خارج کند.
مرحله هفتم؛ بازیابی را آزمایش کنید
حداقل به‌صورت دوره‌ای یک فایل، دیتابیس یا ماشین مجازی را Restore کنید. جزئیات Recovery Testing در بخش اختصاصی مقاله بررسی می‌شود، اما اصل مهم این است: وجود فایل Backup بدون آزمون بازیابی کافی نیست.
ساختار ساده را می‌توان چنین دید:
Production Data → Local Backup سریع → Backup Copy مستقل → Off-site Repository
برای دو بستر متفاوت در قانون 3-2-1 از چه Storageهایی می‌توان استفاده کرد؟
رسانه را بر اساس سرعت Restore، ظرفیت، هزینه، Retention و سطح ریسک انتخاب کنید. دو هارد داخل یک Storage الزاماً دو بستر مستقل نیستند.
Backup Server و HDD
Backup Server اختصاصی کنترل مناسبی روی ظرفیت، Performance و Retention می‌دهد و برای Restore سریع مناسب است. اگر این سرور در سایت اصلی باشد، همچنان به مقصد دیگری برای نسخه مستقل نیاز دارید.
NAS
NAS برای Repository محلی، به‌ویژه در شرکت‌های کوچک و متوسط، گزینه‌ای ساده و قابل توسعه است. اگر دائماً به شبکه Production متصل باشد، کنترل دسترسی و ایزوله‌سازی آن اهمیت زیادی پیدا می‌کند.
Tape
Tape برای آرشیو طولانی‌مدت و ایجاد نسخه‌ای که بتوان آن را از شبکه خارج کرد همچنان کاربرد دارد. مزیت آن امکان Air Gap فیزیکی است؛ در مقابل Restore معمولاً از Disk کندتر است و مدیریت رسانه باید منظم باشد.
Cloud و Object Storage
Cloud Storage و Object Storage می‌توانند مقصد Off-site مناسبی باشند. پیش از انتخاب، هزینه نگهداری، پهنای باند و زمان Restore را بررسی کنید.
| بستر | سرعت Restore | Off-site | Immutability | کاربرد پیشنهادی |
|---|---|---|---|---|
| Backup Server | بالا | محدود | وابسته به راهکار | Backup محلی |
| NAS | بالا | در صورت استقرار خارج از سایت | وابسته به مدل | شرکت کوچک و متوسط |
| Tape | متوسط تا پایین | بله | با جداسازی فیزیکی | آرشیو و Air Gap |
| Cloud Storage | وابسته به اینترنت | بله | در برخی سرویس‌ها | Off-site Backup |
| Object Storage | متوسط تا بالا | بله | در برخی پلتفرم‌ها | Backup سازمانی |
نمونه طراحی Backup برای شرکت کوچک، متوسط و سازمان بزرگ
قانون 3-2-1 چارچوب مشترک است، اما اجرای آن باید با اندازه و حساسیت کسب‌وکار تطبیق پیدا کند. تعداد کاربران به‌تنهایی معیار کافی نیست؛ نوع Workload، RPO، RTO، حجم داده و هزینه Downtime تعیین‌کننده‌ترند.
شرکت کوچک با 10 تا 30 کاربر
در یک شرکت کوچک ممکن است یک سرور فیزیکی یا چند VM، نرم‌افزار حسابداری و File Server وجود داشته باشد. معماری ساده می‌تواند چنین باشد:
Production Server → NAS یا Backup Storage محلی → Cloud / Off-site Backup
تمرکز باید روی اتوماسیون Jobها، کنترل ظرفیت و به‌روزرسانی منظم نسخه Off-site باشد. پیچیده کردن بیش از حد زیرساخت معمولاً ارزش افزوده‌ای ایجاد نمی‌کند.
شرکت متوسط با 30 تا 100 کاربر
با افزایش تعداد سرویس‌ها، Dedicated Backup Repository و یک مقصد ثانویه منطقی‌تر می‌شود:
Physical / Virtual Servers → Dedicated Backup Repository → Secondary Repository → Off-site Storage
در این سطح، Scheduling، Retention، Monitoring و Verification اهمیت بیشتری دارند. پوشش Workloadهای حیاتی و زمان بازیابی سرویس‌ها باید مشخص باشد.
سازمان بزرگ یا Enterprise
در محیط Enterprise معمولاً معماری چندلایه لازم است:
Virtualization / Database / File Services → Dedicated Backup Infrastructure → Secondary Repository → Immutable یا Air-gapped Copy → DR Site / Cloud
در این سطح، Policyها بر اساس Business Criticality تفکیک می‌شوند و سرویس‌های حیاتی ممکن است به Immutable Storage، DR Site یا Replication در کنار Backup نیاز داشته باشند.
| نوع سازمان | Backup محلی | نسخه دوم | Off-site | رویکرد پیشنهادی |
|---|---|---|---|---|
| کوچک | NAS / Backup Storage | Backup Copy | Cloud یا محل دوم | 3-2-1 |
| متوسط | Dedicated Repository | NAS / Object Storage | Off-site Storage | 3-2-1 یا 3-2-1-1-0 |
| Enterprise | زیرساخت اختصاصی | Secondary Repository | DR Site / Cloud / Tape | 3-2-1-1-0 |
این جدول یک الگوی طراحی است، نه کانفیگ قطعی. دو سازمان با تعداد کاربر مشابه ممکن است به دلیل تفاوت در حساسیت داده و RTO به معماری‌های متفاوتی برسند.
آیا قانون 3-2-1 برای مقابله با باج‌افزار کافی است؟
قانون 3-2-1 پایه مناسبی برای Backup است، اما در برابر حملات پیشرفته باج‌افزاری به‌تنهایی کافی نیست. اگر مهاجم بتواند به Repositoryها یا حساب‌های مدیریتی دسترسی پیدا کند، Backupها نیز ممکن است حذف یا رمزگذاری شوند.
سؤال کلیدی این است: اگر حساب Administrator شبکه در اختیار مهاجم قرار بگیرد، آیا او می‌تواند همه Backupهای شما را نیز حذف کند؟ اگر پاسخ مثبت است، باید لایه حفاظتی دیگری اضافه شود.
قانون بکاپ 3-2-1-1-0 چیست؟
مدل 3-2-1-1-0 نسخه توسعه‌یافته این استراتژی است:
- 3: حداقل سه نسخه از اطلاعات
- 2: دو بستر متفاوت
- 1: یک نسخه Off-site
- 1: یک نسخه Offline، Air-gapped یا Immutable
- 0: صفر خطای تأییدنشده در Verification و Recovery Test
Immutable Backup چیست؟
Immutable Backup نسخه‌ای است که در بازه مشخص نباید قابل تغییر یا حذف باشد. این ویژگی در برابر تلاش مهاجم برای پاک کردن Backupها ارزشمند است. البته امنیت واقعی به فناوری، تنظیم Policy و حفاظت از Credentialها نیز وابسته است.
Air Gap Backup چیست؟
Air Gap بر جداسازی دسترسی تمرکز دارد؛ یعنی نسخه Backup به‌صورت دائمی از شبکه Production قابل دسترسی نباشد. Tape خارج‌شده از Library یا Repository ایزوله می‌تواند نمونه‌ای از این رویکرد باشد.
عدد صفر چه مفهومی دارد؟
عدد صفر یادآوری می‌کند که Success شدن Job با Recovery موفق یکسان نیست. نسخه باید قابل Verify و قابل Restore باشد؛ در غیر این صورت وجود آن در زمان بحران تضمینی ایجاد نمی‌کند.
آیا هر شرکتی به 3-2-1-1-0 نیاز دارد؟
سطح ریسک تعیین‌کننده است. برای یک شرکت کوچک، اجرای صحیح 3-2-1 ممکن است کافی باشد؛ اما هرچه وابستگی به داده، هزینه Downtime و تهدیدهای امنیتی بیشتر شود، Immutable Backup، Air Gap و Recovery Verification ارزش بیشتری پیدا می‌کنند.
چه زمانی و با چه روشی از اطلاعات Backup بگیریم؟
نوع Backup و دفعات اجرا باید با میزان تغییر داده و RPO هماهنگ باشند. دیتابیسی با صدها تراکنش روزانه نمی‌تواند همان برنامه آرشیو کم‌تغییر را داشته باشد.
Full Backup
در Full Backup تمام داده‌های انتخاب‌شده ذخیره می‌شوند. Restore ساده‌تر است، اما زمان و فضای بیشتری مصرف می‌شود؛ بنابراین معمولاً به‌صورت دوره‌ای انجام می‌شود.
Incremental Backup
Incremental فقط تغییرات پس از آخرین Backup را ذخیره می‌کند. سریع‌تر و کم‌حجم‌تر است، اما Restore ممکن است به زنجیره‌ای از Restore Pointها وابسته باشد و سلامت این زنجیره اهمیت دارد.
مشاهده کانفیگ‌های پیشنهادی
Differential Backup
Differential تمام تغییرات پس از آخرین Full Backup را نگهداری می‌کند. از نظر حجم و سرعت بین Full و Incremental قرار می‌گیرد و می‌تواند Restore را نسبت به زنجیره طولانی Incremental ساده‌تر کند.
Frequency و Retention را چگونه تعیین کنیم؟
برای هر گروه داده Policy جداگانه تعریف کنید. جدول زیر فقط نمونه است:
| نوع داده | حساسیت | نمونه Frequency | نمونه Retention |
|---|---|---|---|
| دیتابیس مالی | بسیار بالا | چند بار در روز یا بیشتر | روزانه + هفتگی + ماهانه |
| VM حیاتی | بالا | چند بار در روز | متناسب با RPO |
| File Server | متوسط تا بالا | روزانه | چند هفته تا چند ماه |
| آرشیو کم‌تغییر | پایین‌تر | هفتگی یا دوره‌ای | بلندمدت |
Frequency نهایی باید از RPO استخراج شود. Backup پرتکرار برای داده کم‌تغییر منابع را هدر می‌دهد و Backup کم‌تکرار برای دیتای حیاتی ریسک از دست رفتن اطلاعات را بالا می‌برد.
چگونه مطمئن شویم Backup واقعاً قابل بازیابی است؟
معیار موفقیت، صرفاً وجود فایل Backup یا سبز شدن Job نیست. باید بتوان داده یا سرویس را در زمان موردنیاز از همان نسخه بازیابی کرد.
وضعیت Backup Job و Repository را بررسی کنید
آخرین زمان Backup، مدت Job، خطاها، فضای آزاد Repository، تعداد Restore Pointها و وضعیت Backup Copy را پایش کنید. Warningهای تکرارشونده می‌توانند نشانه مشکل در Recovery Chain باشند.
Integrity Verification انجام دهید
Integrity Check سلامت ساختار Backup و قابل خواندن بودن فایل‌ها و Metadata را بررسی می‌کند. بااین‌حال، سلامت ساختاری تضمین نمی‌کند سرویس بعد از Restore درست کار کند؛ بنابراین آزمون عملی نیز لازم است.
File، Database و VM Restore را آزمایش کنید
یک فایل را به مسیر آزمایشی Restore کنید و صحت محتوا و Permissionها را بسنجید. برای دیتابیس، Restore روی Test Instance مفید است. در VM نیز علاوه بر Boot شدن، عملکرد سرویس‌ها و ارتباطات اصلی را بررسی کنید.
مشاهده کانفیگ های پیشنهادی
Disaster Recovery Drill اجرا کنید
برای سرویس‌های حیاتی، سناریوی از دسترس خارج شدن سایت اصلی را تمرین و زمان Recovery را با RTO مقایسه کنید. اختلاف معنادار نشان می‌دهد معماری یا فرآیند باید اصلاح شود.
فاصله تست برای همه یکسان نیست و باید با اهمیت سرویس و سرعت تغییر زیرساخت تنظیم شود. اصل مهم این است که Restore Test نباید برای اولین بار پس از حادثه انجام شود.
اشتباهات رایج در اجرای قانون بکاپ 3-2-1
حتی با وجود چند Backup، این خطاها می‌توانند معماری را آسیب‌پذیر کنند:
- نگهداری Backup روی همان سرور یا Storage اصلی
- در نظر گرفتن RAID به‌عنوان جایگزین Backup
- اتصال دائمی همه Repositoryها به شبکه Production
- استفاده از حساب مدیریتی مشترک برای Production و Backup
- نداشتن نسخه Off-site
- نداشتن Retention Policy
- تست نکردن Restore
- بی‌توجهی به ظرفیت Repository و خطاهای Job
- اشتباه گرفتن File Sync با Backup
- اجرای یک Policy یکسان برای همه Workloadها
اگر چند مورد از این خطاها در زیرساخت وجود دارد، پیش از افزایش تعداد نسخه‌ها، معماری را اصلاح کنید. استقلال مسیرهای Backup و قابلیت بازیابی از تعداد فایل‌های پشتیبان مهم‌تر است.
چک‌لیست طراحی سیستم بکاپ سازمانی
برای ارزیابی سریع وضعیت فعلی، این پرسش‌ها را بررسی کنید:
- □ داده‌ها و سرویس‌های حیاتی مشخص شده‌اند؟
- □ برای سرویس‌های مهم RPO و RTO تعریف شده است؟
- □ سه نسخه از اطلاعات حیاتی وجود دارد؟
- □ نسخه‌ها به Failure Domain واحد وابسته نیستند؟
- □ حداقل یک نسخه Off-site دارید؟
- □ برای داده‌های حساس، Immutable یا Air-gapped Copy در نظر گرفته شده است؟
- □ Retention Policy مستند دارید؟
- □ ظرفیت Repository با رشد آینده داده هماهنگ است؟
- □ Backup Job و Backup Copy به‌صورت منظم مانیتور می‌شوند؟
- □ دسترسی مدیریتی Backup از Production تا حد امکان جداست؟
- □ File، Database یا VM Restore به‌صورت دوره‌ای آزمایش می‌شود؟
- □ زمان Recovery واقعی با RTO مقایسه شده است؟
- □ برای از دسترس خارج شدن کامل سایت اصلی، سناریوی بازیابی دارید؟
اگر چند پاسخ «خیر» است، سیستم فعلی احتمالاً هنوز یک استراتژی بکاپ سازمانی کامل نیست.
کلام آخر؛ آیا قانون 3-2-1 برای سازمان شما کافی است؟
قانون بکاپ 3-2-1 نقطه شروع مناسبی برای طراحی سیستم پشتیبان‌گیری است، اما ارزش واقعی آن زمانی مشخص می‌شود که با RPO، RTO، Retention، کنترل دسترسی، Monitoring و Restore Test همراه شود. برای محیط‌های حساس‌تر، مدل 3-2-1-1-0 و نسخه‌های Immutable یا Air-gapped می‌توانند لایه حفاظتی بیشتری ایجاد کنند.
بهترین سیستم Backup سیستمی است که هنگام بحران نسخه سالم داده را در بازه مورد انتظار بازیابی کند. بنابراین انتخاب Backup Server، Storage یا مقصد Off-site باید بر اساس Workload، حجم داده، نرخ رشد، RPO و RTO باشد.
سوالات متداول درباره قانون بکاپ 3-2-1
قانون بکاپ 3-2-1 چیست؟
قانون بکاپ 3-2-1 می‌گوید از داده‌های مهم حداقل سه نسخه داشته باشید، آن‌ها را روی دو بستر متفاوت نگهداری کنید و حداقل یک نسخه را خارج از محل اصلی قرار دهید.
منظور از سه نسخه در قانون 3-2-1 چیست؟
معمولاً داده اصلی یا Production به‌علاوه دو نسخه Backup مستقل. سه کپی روی یک Storage واحد، سه نسخه مستقل محسوب نمی‌شوند.
آیا RAID یکی از نسخه‌های Backup است؟
خیر. RAID تحمل خرابی دیسک را افزایش می‌دهد، اما به‌تنهایی نسخه تاریخی مستقل ایجاد نمی‌کند.
آیا NAS برای اجرای قانون 3-2-1 کافی است؟
NAS می‌تواند یکی از مقصدهای Backup باشد، اما اگر Production و NAS هر دو در یک سایت باشند، برای تکمیل 3-2-1 به نسخه Off-site نیز نیاز دارید.
آیا Cloud Backup می‌تواند نسخه Off-site باشد؟
بله، اگر از زیرساخت اصلی مستقل باشد و دسترسی، Retention و امنیت آن به‌درستی تنظیم شوند.
قانون 3-2-1-1-0 چیست؟
نسخه توسعه‌یافته 3-2-1 است که یک نسخه Offline، Air-gapped یا Immutable و همچنین Verification بدون خطای تأییدنشده را به مدل اضافه می‌کند.
هر چند وقت یک‌بار باید Backup بگیریم؟
فاصله Backup باید از RPO استخراج شود. هرچه تحمل از دست رفتن داده کمتر باشد، Restore Pointها باید با فاصله کوتاه‌تری ایجاد شوند.
تفاوت RPO و RTO چیست؟
RPO مقدار قابل قبول از دست رفتن داده از نظر زمانی را مشخص می‌کند؛ RTO حداکثر زمان قابل قبول برای بازگرداندن سرویس است.
آیا Snapshot جای Backup را می‌گیرد؟
خیر. Snapshot برای Rollback سریع مفید است، اما اگر به همان Storage اصلی وابسته باشد، خرابی آن Storage می‌تواند Snapshot را نیز از بین ببرد.
چگونه بفهمیم Backup سالم است؟
با Integrity Verification و Restore Test دوره‌ای؛ فقط Success شدن Backup Job کافی نیست.
آیا قانون 3-2-1 از باج‌افزار جلوگیری می‌کند؟
این قانون ریسک از دست رفتن همه نسخه‌ها را کاهش می‌دهد، اما برای مقاومت بیشتر در برابر Ransomware بهتر است حداقل یک نسخه Immutable، Offline یا Air-gapped نیز وجود داشته باشد.
انتخاب تجهیزات مناسب، تنها به خرید یک مدل خاص محدود نمی‌شود؛ بلکه به انتخاب کانفیگی متناسب با نیاز واقعی سازمان بستگی دارد. در ماهان شبکه ایرانیان، کارشناسان فنی با بررسی تعداد کاربران، نوع نرم‌افزارهای سازمانی، نیازهای پردازشی و بودجه شما، مناسب‌ترین مدل و کانفیگ را پیشنهاد می‌دهند. اگر برای خرید سرور اچ پی یا سایر تجهیزات شبکه جهت ارتقاء زیرساخت خود به راهنمایی نیاز دارید، پیش از تصمیم‌گیری با کارشناسان ما مشورت کنید تا با اطمینان، راهکاری متناسب با نیاز امروز و توسعه آینده کسب‌وکار خود انتخاب کنید.
