از دست رفتن اطلاعات همیشه نتیجه خرابی یک هارددیسک یا Storage نیست. حذف اشتباه فایل ها، خرابی تجهیزات، خطای انسانی، حملات باج افزاری، اختلال در دیتاسنتر، مشکلات نرم افزاری و حتی آسیب دیدن خود زیرساخت Backup می توانند باعث شوند اطلاعات حیاتی یک سازمان در دسترس نباشد. به همین دلیل داشتن یک نسخه Backup به تنهایی نمی تواند یک استراتژی مطمئن حفاظت از داده باشد. ممکن است همان نسخه پشتیبان نیز همراه با اطلاعات اصلی از بین برود، خراب شود یا در جریان یک حمله سایبری مورد هدف قرار گیرد. یکی از شناخته شده ترین روش ها برای کاهش چنین ریسک هایی، قانون بکاپ 3-2-1 یا 3-2-1 Backup Rule است؛ قانونی ساده که سال هاست در طراحی زیرساخت های Backup استفاده می شود و با وجود تغییر فناوری های ذخیره سازی، Cloud و ظهور تهدیدهایی مانند Ransomware، هنوز منطق اصلی آن معتبر است. اما قانون 3-2-1 دقیقاً چیست، چگونه باید آن را در یک سازمان اجرا کرد و آیا در شرایط امروزی به تنهایی کافی است؟
قانون بکاپ 3-2-1 چیست؟
قانون 3-2-1 یک اصل طراحی برای افزایش قابلیت بازیابی اطلاعات است. طبق این قانون باید حداقل سه نسخه از اطلاعات وجود داشته باشد، این نسخه ها روی حداقل دو نوع رسانه یا زیرساخت متفاوت نگهداری شوند و حداقل یک نسخه نیز در مکانی خارج از محل اصلی، مانند فضای ذخیره‌سازی ابری، قرار داشته باشد.
| عدد | مفهوم |
| 3 | سه نسخه از اطلاعات شامل اطلاعات اصلی و حداقل دو نسخه Backup |
| 2 | نگهداری نسخه ها روی حداقل دو رسانه یا زیرساخت ذخیره سازی متفاوت |
| 1 | نگهداری حداقل یک نسخه در خارج از سایت اصلی یا Offsite |
هدف اصلی این ساختار ساده است: نباید یک حادثه بتواند تمام نسخه های اطلاعات را هم زمان از بین ببرد. برای مثال اگر اطلاعات اصلی و Backup هر دو روی یک Storage یا در یک دیتاسنتر قرار داشته باشند، خرابی Storage، آتش سوزی، اختلال دیتاسنتر یا یک حمله سایبری گسترده ممکن است هر دو نسخه را تحت تأثیر قرار دهد. در معماری 3-2-1 تلاش می شود چنین نقاط شکست مشترکی تا حد امکان حذف شوند.
عدد 3 در قانون 3-2-1 به چه معناست؟
عدد 3 به این معناست که سازمان باید حداقل سه Copy از اطلاعات داشته باشد. یکی از این نسخه ها همان اطلاعات Production است که کاربران و سرویس ها به صورت روزمره از آن استفاده می کنند. دو نسخه دیگر باید نسخه های پشتیبان باشند. فرض کنید پایگاه داده اصلی یک سازمان روی Storage دیتاسنتر قرار دارد. اگر فقط یک Backup از آن روی همان Storage یا یک Repository محلی وجود داشته باشد، سازمان همچنان به تعداد محدودی نقطه شکست وابسته است. اما وجود دو نسخه مستقل Backup احتمال اینکه یک حادثه تمام مسیرهای بازیابی را از بین ببرد کاهش می دهد. نکته مهم این است که سه نسخه از اطلاعات صرفاً به معنای سه فایل کپی شده در سه پوشه مختلف نیست. نسخه ها باید به شکلی طراحی شوند که خرابی یا Compromise شدن یک بخش، سایر نسخه ها را نیز تحت تأثیر قرار ندهد.
عدد 2 در قانون بکاپ به چه معناست؟
بخش دوم قانون می گوید اطلاعات باید روی حداقل دو نوع رسانه یا زیرساخت ذخیره سازی متفاوت قرار گیرند. در گذشته این موضوع معمولاً به معنای نگهداری Backup روی Disk و Tape بود. امروزه گزینه های بیشتری وجود دارد؛ برای مثال می توان اطلاعات Production را روی SAN Storage نگهداری کرد و Backup را روی یک Backup Repository مستقل و نسخه دیگری را در Object Storage قرار داد. هدف اصلی الزاماً استفاده از دو فناوری کاملاً متفاوت نیست؛ هدف این است که تمام نسخه های اطلاعات به یک سیستم، تجهیزات، Credential، Failure Domain یا زیرساخت مشترک وابسته نباشند. برای مثال اگر Production و Backup روی دو Volume مختلف از یک Storage فیزیکی قرار داشته باشند، از نظر ظاهری دو محل ذخیره سازی داریم، اما خرابی همان Storage می تواند هر دو نسخه را از بین ببرد. بنابراین باید استقلال واقعی میان نسخه ها وجود داشته باشد.
عدد 1 در قانون 3-2-1 به چه معناست؟
عدد 1 به نگهداری حداقل یک نسخه Backup در یک محل Offsite اشاره دارد. یعنی حداقل یکی از نسخه های Backup نباید در همان محل فیزیکی Production قرار گرفته باشد. این نسخه می تواند در یک دیتاسنتر دوم، Disaster Recovery Site، Object Storage ابری یا زیرساخت Backup خارج از محل اصلی سازمان نگهداری شود. وجود Backup خارج از سایت در برابر حوادثی مانند آتش سوزی، قطعی گسترده برق، خرابی دیتاسنتر، سرقت تجهیزات، بلایای طبیعی یا آسیب فیزیکی گسترده اهمیت زیادی پیدا می کند. اگر تمام Backupها در همان رک یا همان دیتاسنتر Production باشند، در واقع سازمان هنوز یک Single Point of Failure در سطح سایت دارد.
یک نمونه ساده از معماری Backup 3-2-1
فرض کنید یک سازمان تعدادی ماشین مجازی روی VMware دارد و اطلاعات اصلی آن روی Storage داخلی دیتاسنتر قرار گرفته است.
- در یک معماری ساده، نسخه اول همان VMها و اطلاعات Production هستند.
- نسخه دوم از طریق نرم افزار Backup روی یک Backup Repository مستقل در دیتاسنتر سازمان ذخیره می شود.
- نسخه سوم نیز از طریق Backup Copy Job به یک Object Storage یا دیتاسنتر دوم منتقل می شود.
در چنین معماری ای حتی اگر Storage اصلی خراب شود، امکان بازیابی از Backup Repository وجود دارد. اگر کل سایت اصلی دچار حادثه شود، نسخه Offsite همچنان باقی خواهد ماند. این همان منطق اصلی قانون 3-2-1 است: هر حادثه نباید تمام مسیرهای Recovery را تحت تأثیر قرار دهد.
چرا قانون 3-2-1 هنوز اهمیت دارد؟
فناوری Backup در سال های اخیر تغییر زیادی کرده است. Object Storage، Cloud Backup، Snapshot، Replication و Immutable Storage امکانات جدیدی برای حفاظت از اطلاعات ایجاد کرده اند. با این حال مشکلی که قانون 3-2-1 تلاش می کند حل کند هنوز تغییر نکرده است: جلوگیری از وابستگی تمام نسخه های اطلاعات به یک نقطه شکست مشترک. حتی پیشرفته ترین Storageها نیز ممکن است خراب شوند. کاربران همچنان ممکن است اطلاعات را اشتباه حذف کنند. نرم افزارها ممکن است داده ها را Corrupt کنند و مهاجمان نیز می توانند مستقیماً زیرساخت Backup را هدف قرار دهند. به همین دلیل NIST بر طراحی و آزمایش منظم فرآیند Backup و Restore تأکید می کند و CISA نیز در راهنمای مقابله با Ransomware توصیه می کند Backupها به صورت جداشده یا Offline نگهداری شده و به طور منظم آزمایش شوند.
باج افزارها نگاه ما به Backup را تغییر داده اند
در گذشته Backup بیشتر برای مقابله با خرابی سخت افزار، حذف اطلاعات یا Disaster طراحی می شد. امروز مهاجمان می دانند وجود Backup می تواند سازمان را از پرداخت باج بی نیاز کند. به همین دلیل در بسیاری از حملات، مهاجمان تلاش می کنند قبل از رمزگذاری اطلاعات Production، Backup Repository، Backup Server و حساب های مدیریتی مرتبط با Backup را نیز شناسایی و تخریب کنند. اینجاست که یکی از ضعف های اجرای سنتی 3-2-1 مشخص می شود. ممکن است سازمان سه نسخه از اطلاعات داشته باشد، اما اگر مهاجم با یک حساب مدیریتی بتواند تمام آنها را حذف کند، عملاً تعداد نسخه ها کمکی به Recovery نخواهد کرد. به همین دلیل امروزه جداسازی Backup Infrastructure، محدود کردن دسترسی ها و استفاده از نسخه های Immutable یا Air-Gapped اهمیت بسیار بیشتری پیدا کرده است.
Immutable Backup چیست و چه ارتباطی با 3-2-1 دارد؟
Immutable Backup نسخه ای از Backup است که در یک بازه زمانی مشخص امکان تغییر یا حذف آن وجود ندارد؛ حتی اگر یک حساب کاربری دارای دسترسی بالا Compromise شود. یکی از کاربردهای رایج این قابلیت در Object Storageهایی است که از قابلیت هایی مانند Object Lock پشتیبانی می کنند. برای مثال می توان Backupهای یک سازمان را برای مدت مشخصی Immutable کرد. در نتیجه مهاجم نمی تواند پس از نفوذ به محیط Production به سادگی این نسخه ها را حذف یا رمزگذاری کند. بنابراین در معماری های امروزی، داشتن یک نسخه Offsite خوب است، اما داشتن یک نسخه Offsite و Immutable بسیار مطمئن تر است.
قانون 3-2-1-1-0 چیست؟
با افزایش حملات سایبری، نسخه پیشرفته تری از قانون 3-2-1 با عنوان 3-2-1-1-0 مطرح شده است. Veeam این مدل را به عنوان توسعه ای برای قانون سنتی 3-2-1 مطرح می کند. در این رویکرد، همان سه نسخه اطلاعات، دو نوع رسانه و یک نسخه Offsite حفظ می شود، اما یک لایه دیگر برای مقابله با Ransomware و یک لایه برای اطمینان از قابلیت Recovery اضافه می شود.
- عدد دوم 1 به وجود حداقل یک نسخه Offline، Air-Gapped یا Immutable اشاره دارد.
- عدد 0 نیز به این معناست که Backup باید به صورت منظم بررسی و Recovery آن آزمایش شود تا در زمان نیاز با خطای بازیابی مواجه نشویم.
این بخش بسیار مهم است؛ زیرا وجود Backup با امکان Restore واقعی دو مفهوم متفاوت هستند.
داشتن Backup کافی نیست؛ Restore مهم تر است
یکی از رایج ترین اشتباهات سازمان ها این است که موفق بودن Backup Job را معادل سالم بودن استراتژی Backup در نظر می گیرند. ممکن است نرم افزار Backup هر شب وضعیت Successful نمایش دهد، اما در زمان حادثه مشخص شود فایل Backup خراب است، Application به درستی Restore نمی شود، Credential مورد نیاز وجود ندارد یا سرعت Recovery بسیار کمتر از چیزی است که کسب وکار انتظار دارد. بنابراین Backup زمانی ارزش واقعی دارد که سازمان بتواند اطلاعات را در زمان مورد انتظار بازیابی کند. به همین دلیل باید Restore Test بخشی از فرآیند Backup باشد، نه اقدامی که فقط پس از وقوع بحران انجام شود. NIST نیز در توصیه های مرتبط با Ransomware بر آزمایش منظم Backup و فرآیند Restoration تأکید می کند.
تفاوت Backup با Snapshot چیست؟
یکی از اشتباهات متداول این است که Snapshot به عنوان جایگزین Backup در نظر گرفته می شود. Snapshot معمولاً وضعیت یک سیستم یا Volume را در یک نقطه زمانی ثبت می کند و برای Rollback سریع بسیار مفید است. اما در بسیاری از معماری ها Snapshot همچنان به همان Storage اصلی وابسته است. اگر Storage اصلی از بین برود یا مهاجم بتواند Snapshotها را حذف کند، این نسخه ها نیز ممکن است از دسترس خارج شوند. بنابراین Snapshot می تواند بخشی از Data Protection Strategy باشد، اما معمولاً نباید تنها مکانیزم حفاظت از اطلاعات باشد. Backup مستقل باید خارج از Failure Domain اصلی نگهداری شود.
تفاوت Backup با Replication چیست؟
Replication نیز جایگزین کامل Backup نیست.
- در Replication، اطلاعات از یک سیستم به سیستم دیگری منتقل می شوند تا در صورت خرابی سیستم اصلی، سرویس بتواند سریع تر از محل دوم فعالیت خود را ادامه دهد. اما مشکل اینجاست که بعضی خطاها نیز Replicate می شوند. اگر یک فایل حذف شود، داده Corrupt شود یا تغییر مخربی روی اطلاعات صورت گیرد، ممکن است همان تغییر به Replica نیز منتقل شود.
- Backup امکان نگهداری Restore Pointهای تاریخی را فراهم می کند، در حالی که هدف اصلی Replication معمولاً افزایش Availability و کاهش زمان Downtime است.
در یک طراحی حرفه ای، Backup و Replication مکمل یکدیگر هستند.
آیا Cloud Backup با قانون 3-2-1 سازگار است؟
بله. اتفاقاً Cloud و Object Storage اجرای بخش Offsite قانون 3-2-1 را برای بسیاری از سازمان ها ساده تر کرده اند. سازمان دیگر لزوماً مجبور نیست برای نگهداری یک نسخه خارج از سایت، دیتاسنتر دوم ایجاد کند. می توان نسخه Backup را به یک Object Storage منتقل کرد و در صورت پشتیبانی زیرساخت، قابلیت هایی مانند Encryption، Versioning و Immutability را نیز فعال کرد. البته صرف انتقال Backup به Cloud به معنای امن شدن آن نیست. دسترسی ها، Credentialها، Retention Policy، Encryption، MFA، Immutability و جداسازی حساب های مدیریتی همچنان باید به درستی طراحی شوند. Cloud یک مقصد Backup است؛ نه جایگزینی برای معماری امنیتی صحیح.
آیا دو Backup روی یک Storage قانون 3-2-1 را رعایت می کنند؟
خیر، حداقل از منظر هدف اصلی این قانون چنین طراحی ای مناسب نیست. فرض کنید دو Backup مختلف روی دو Volume از یک Storage نگهداری می شوند. اگر Storage دچار خرابی جدی شود، هر دو نسخه ممکن است هم زمان از دسترس خارج شوند. به همین دلیل، هنگام بررسی بهترین روش های ذخیره سازی اطلاعات برای سازمان ها باید علاوه بر ظرفیت و نوع Storage، میزان استقلال نسخه های پشتیبان از زیرساخت اصلی نیز در نظر گرفته شود. همین مسئله درباره دو Backup Repository که هر دو به یک Credential مدیریتی، یک Domain یا یک سیستم ذخیره سازی مشترک وابسته هستند نیز وجود دارد. در طراحی Backup نباید تنها به تعداد Copyها نگاه کرد؛ بلکه باید Failure Domain هر نسخه را نیز بررسی کرد
اشتباهات رایج در اجرای قانون 3-2-1
- یکی از رایج ترین خطاها نگهداری تمام Backupها در همان دیتاسنتر Production است. مشکل دیگر متصل بودن دائمی تمام Repositoryها به محیط اصلی سازمان است.
- گاهی نیز سازمان نسخه Offsite دارد اما همان حساب Domain Administrator روی Backup Server و Production استفاده می شود. در چنین شرایطی نفوذ به Domain می تواند مسیر حمله به Backup Infrastructure را نیز فراهم کند.
- یکی دیگر از اشتباهات مهم نداشتن Restore Test است. Backupهایی که ماه ها ایجاد شده اند اما هیچ گاه آزمایش نشده اند، نمی توانند تضمین کنند که در روز بحران واقعاً قابل استفاده خواهند بود.
- نداشتن Retention Policy مناسب، Backup نگرفتن از سرویس های SaaS، وابستگی کامل به Snapshot و نداشتن Monitoring برای Jobهای Backup نیز از خطاهای متداول هستند.
RPO و RTO چه ارتباطی با قانون 3-2-1 دارند؟
قانون 3-2-1 مشخص می کند نسخه های اطلاعات چگونه توزیع شوند، اما مشخص نمی کند Backup هر چند ساعت یک بار گرفته شود یا Recovery چقدر باید طول بکشد. برای پاسخ به این سؤال باید دو شاخص مهم یعنی RPO و RTO مشخص شوند.
- RPO یا Recovery Point Objective مشخص می کند سازمان حداکثر چه میزان از اطلاعات اخیر را می تواند از دست بدهد. برای مثال اگر RPO یک سیستم چهار ساعت باشد، باید معماری Backup به شکلی طراحی شود که در بدترین حالت بیشتر از چهار ساعت Data Loss نداشته باشیم.
- RTO یا Recovery Time Objective نیز مشخص می کند سرویس حداکثر چه مدت می تواند Down باشد. ممکن است یک سازمان Backup بسیار امنی داشته باشد، اما Restore چندین ترابایت اطلاعات دو روز طول بکشد؛ در حالی که کسب وکار فقط چهار ساعت Downtime را تحمل می کند.
بنابراین یک Backup Strategy حرفه ای باید همزمان 3-2-1، RPO و RTO را در نظر بگیرد.
آیا تمام اطلاعات باید Backup یکسانی داشته باشند؟
خیر. یکی دیگر از اصول مهم طراحی Backup این است که همه اطلاعات ارزش و حساسیت یکسانی ندارند. Database یک سامانه مالی ممکن است نیازمند Backupهای متعدد در طول روز، Retention طولانی و نسخه Immutable باشد، در حالی که یک File Server کم اهمیت شاید بتواند با Backup روزانه محافظت شود. به همین دلیل پیش از طراحی Backup باید سرویس ها طبقه بندی شوند. سیستم های Mission Critical معمولاً RPO و RTO سخت گیرانه تری دارند و باید Recovery آنها نیز با دفعات بیشتری آزمایش شود. در نتیجه قانون 3-2-1 چارچوب کلی را مشخص می کند، اما جزئیات اجرای آن باید متناسب با اهمیت هر سرویس طراحی شود.
یک معماری مناسب 3-2-1 برای سازمان ها چگونه است؟
فرض کنید اطلاعات Production سازمان روی SAN Storage قرار دارد. یک Backup Repository مستقل می تواند نسخه Backup محلی را نگهداری کند تا Restoreهای روزمره با سرعت بالا انجام شوند. نسخه دوم Backup نیز می تواند به Object Storage خارج از سایت منتقل شود و برای آن Immutability فعال شود. در چنین معماری ای Repository محلی برای Recovery سریع استفاده می شود و Object Storage نقش آخرین خط دفاع در برابر Disaster یا Ransomware را دارد. برای سرویس های بسیار حیاتی می توان Replication به DR Site را نیز به این معماری اضافه کرد. در این حالت سازمان هم Recovery سریع دارد، هم Backup تاریخی و هم نسخه ای مستقل برای مقابله با حوادث گسترده.
آیا Tape هنوز در قانون 3-2-1 کاربرد دارد؟
با وجود گسترش Cloud و Object Storage، Tape هنوز در برخی سازمان ها استفاده می شود. یکی از مزایای مهم Tape این است که پس از خارج شدن Media از Tape Library می تواند به صورت فیزیکی از شبکه جدا شود و یک Air Gap واقعی ایجاد کند. به همین دلیل برخی سازمان های بزرگ، بانک ها و محیط هایی با Retention طولانی همچنان از Tape در کنار Disk و Object Storage استفاده می کنند. با این حال مدیریت Tape، زمان Recovery، نگهداری فیزیکی و فرآیندهای عملیاتی آن باید در طراحی در نظر گرفته شوند.
آیا قانون 3-2-1 به تنهایی در برابر Ransomware کافی است؟
خیر. 3-2-1 همچنان پایه مناسبی برای طراحی Backup است، اما تهدیدهای امروزی نیازمند کنترل های بیشتری هستند. اگر تمام Backupها Online باشند و مهاجم بتواند با Credentialهای مدیریتی آنها را حذف کند، تعداد نسخه ها اهمیت خود را از دست می دهد. به همین دلیل در معماری های جدید باید حداقل یک نسخه غیرقابل تغییر، جداشده یا Air-Gapped وجود داشته باشد. همچنین Backup Infrastructure باید تا حد امکان از Production جدا شود و دسترسی مدیریتی آن محدود باشد. این دقیقاً همان دلیلی است که باعث شده مدل هایی مانند 3-2-1-1-0 به عنوان توسعه قانون سنتی مطرح شوند.
چگونه بفهمیم استراتژی Backup سازمان واقعاً مناسب است؟
بهترین معیار این نیست که بپرسیم آیا Backup داریم؟ سؤال صحیح این است:
- اگر همین امروز Storage اصلی کاملاً از بین برود، از کجا Recovery انجام می دهیم؟
- اگر کل دیتاسنتر اصلی از دسترس خارج شود چه اتفاقی می افتد؟
- اگر Domain Administrator Compromise شود، آیا مهاجم می تواند Backupها را نیز حذف کند؟
- اگر آخرین Backupها آلوده یا Corrupt باشند، چند Restore Point سالم در اختیار داریم؟
- و مهم تر از همه، آخرین بار چه زمانی Restore واقعی یک سرویس را آزمایش کرده ایم؟
اگر پاسخ این سؤالات مشخص نباشد، احتمالاً Backup Strategy هنوز به اندازه کافی بالغ نیست.
چگونه قانون 3-2-1 را در سازمان اجرا کنیم؟
اجرای صحیح این قانون باید از شناخت اطلاعات و سرویس های حیاتی شروع شود.
- ابتدا باید مشخص شود چه اطلاعاتی برای ادامه فعالیت کسب وکار حیاتی هستند. سپس RPO، RTO و Retention مورد انتظار برای هر سرویس تعیین شود.
- بعد از آن باید Repository محلی، مقصد Offsite و در صورت نیاز Immutable Storage طراحی شوند.
- در مرحله بعد نحوه دسترسی به Backup Infrastructure اهمیت پیدا می کند. Backup Server و Repositoryها نباید بدون کنترل مناسب با محیط Production Credential مشترک داشته باشند.
- در نهایت Monitoring، گزارش گیری و Restore Test باید به بخشی از عملیات مستمر Backup تبدیل شوند.
Backup یک پروژه یک باره نیست؛ یک فرآیند دائمی است.
آینده قانون 3-2-1
قانون 3-2-1 بیش از آنکه درباره یک فناوری خاص باشد، درباره حذف نقاط شکست مشترک است. ممکن است امروز از NAS، Object Storage، Cloud و Immutable Repository استفاده کنیم و در آینده فناوری های دیگری جایگزین آنها شوند، اما اصل موضوع تغییر نمی کند: اطلاعات حیاتی نباید تنها در یک مکان، روی یک فناوری و تحت کنترل یک دامنه امنیتی قرار داشته باشند. به همین دلیل 3-2-1 هنوز ارزش خود را حفظ کرده است. حتی راهنماهای جدید حوزه Backup نیز همچنان بر مفاهیمی مانند ایجاد منظم Backup، تست Recovery و ادغام Backup با فرآیندهای Recovery تأکید دارند. برای نمونه، NIST در راهنمای Backup منتشرشده در سال 2026 برای محیط های OT نیز ایجاد منظم Backup، تست آنها و بررسی Backupها در تمرین های Recovery را از اصول مهم مدیریت Backup می داند.
قانون 3-2-1 بهتر است یا 3-2-1-1-0؟
این دو قانون در مقابل یکدیگر نیستند. 3-2-1 پایه معماری حفاظت از داده را مشخص می کند و 3-2-1-1-0 آن را برای شرایط امنیتی امروز تکمیل می کند. برای بسیاری از سازمان ها، هدف مناسب این است که ابتدا معماری 3-2-1 به درستی پیاده سازی شود و سپس حداقل یک نسخه Immutable یا Air-Gapped و فرآیند منظم Recovery Verification نیز به آن اضافه شود. به این ترتیب سازمان فقط چند نسخه از اطلاعات ندارد، بلکه نسخه هایی دارد که احتمال بیشتری دارد در زمان یک حادثه واقعی قابل بازیابی باشند.
جمع بندی
قانون بکاپ 3-2-1 یکی از ساده ترین اما مهم ترین اصول طراحی استراتژی Backup است. سه نسخه از اطلاعات، نگهداری روی دو زیرساخت یا رسانه متفاوت و قرار دادن حداقل یک نسخه خارج از سایت باعث می شود احتمال از دست رفتن کامل اطلاعات به طور قابل توجهی کاهش پیدا کند. اما تهدیدهای امروزی نشان داده اند که تعداد Backupها به تنهایی کافی نیست. سازمان ها باید علاوه بر رعایت 3-2-1، حداقل یک نسخه Immutable، Offline یا Air-Gapped داشته باشند، Backup Infrastructure را از Production جدا کنند و مهم تر از همه، قابلیت Restore را به طور منظم آزمایش کنند. به همین دلیل می توان گفت قانون 3-2-1 هنوز منسوخ نشده است؛ بلکه باید متناسب با تهدیدهای امروز تکمیل شود. یک استراتژی Backup موفق زمانی ارزش خود را نشان می دهد که سازمان در لحظه بحران بتواند با اطمینان پاسخ دهد: نسخه سالم اطلاعات ما کجاست و چقدر طول می کشد آن را بازیابی کنیم؟
سوالات متداول درباره قانون بکاپ 3-2-1
- قانون بکاپ 3-2-1 چیست؟
قانون 3-2-1 توصیه می کند حداقل سه نسخه از اطلاعات وجود داشته باشد، این نسخه ها روی حداقل دو نوع رسانه یا زیرساخت متفاوت نگهداری شوند و حداقل یک Backup نیز خارج از سایت اصلی قرار داشته باشد. - آیا قانون 3-2-1 هنوز کاربرد دارد؟
بله. اصل جداسازی نسخه های اطلاعات همچنان معتبر است، اما برای مقابله بهتر با تهدیدهایی مانند Ransomware توصیه می شود یک نسخه Immutable، Offline یا Air-Gapped نیز به معماری اضافه شود. - قانون 3-2-1-1-0 چیست؟
این مدل نسخه تکامل یافته 3-2-1 است. عدد 1 اضافه شده به وجود یک Backup Immutable، Offline یا Air-Gapped اشاره می کند و صفر بر انجام Recovery Verification و اطمینان از نبود خطای بازیابی تأکید دارد. - آیا Cloud Backup می تواند نسخه Offsite باشد؟
بله. Object Storage و Cloud Backup از گزینه های رایج برای ایجاد Backup خارج از سایت هستند. با این حال باید دسترسی، Encryption، Retention و Immutability آنها نیز به درستی پیکربندی شود. - آیا Snapshot جایگزین Backup است؟
خیر. Snapshot برای بازگشت سریع به وضعیت قبلی مفید است، اما معمولاً به زیرساخت Storage اصلی وابسته است و نباید تنها مکانیزم حفاظت از اطلاعات باشد. - آیا Replication جایگزین Backup محسوب می شود؟
خیر. هدف اصلی Replication افزایش Availability و کاهش Downtime است، در حالی که Backup امکان نگهداری Restore Pointهای تاریخی را فراهم می کند. در معماری های حرفه ای معمولاً از هر دو استفاده می شود. - آیا نگهداری چند Backup روی یک Storage قانون 3-2-1 را رعایت می کند؟
خیر. اگر تمام نسخه ها به یک Storage وابسته باشند، خرابی یا Compromise شدن آن Storage می تواند تمام Backupها را هم زمان تحت تأثیر قرار دهد. - مهم ترین بخش یک استراتژی Backup چیست؟
توانایی موفق بودن Backup Job به تنهایی کافی نیست. سازمان باید مطمئن باشد Backup سالم است، Restore آن آزمایش شده و اطلاعات می توانند در RTO مورد انتظار کسب وکار بازیابی شوند.
