آیا تا به حال به این فکر کرده اید که اگر فردا هارد لپ تاپتان بسوزد، چه اتفاقی برای عکس ها، اسناد کاری و پروژه های چند ساله تان می افتد؟ بسیاری از ما می دانیم که «بکاپ» مهم است، اما دانستن با انجام دادن فاصله دارد. در این راهنمای گام به گام، قصد داریم استراتژی 3-2-1 بکاپ را نه به عنوان یک مفهوم انتزاعی، بلکه به عنوان یک برنامه عملیاتی که می توانید از همین امروز شروع کنید، بررسی کنیم. این استراتژی که ریشه در استانداردهای صنعتی و توصیه های سازمان هایی مانند CISA دارد، ساده، مقرون به صرفه و مؤثر است . در ادامه، ابتدا منطق پشت این قانون را می شکافیم و سپس با یک نقشه راه شش مرحله ای، آن را برای سناریوهای مختلف زندگی واقعی پیاده سازی می کنیم. استراتژی 3-2-1 در یک نگاه:
۳ نسخه از داده ها: یک نسخه اصلی (فایل هایی که روزانه با آن ها کار می کنید) به علاوه دو نسخه پشتیبان دیگر.
۲ نوع رسانه ذخیره سازی متفاوت: برای مثال، یک هارد اکسترنال و یک فضای ذخیره سازی ابری (یا NAS).
۱ نسخه خارج از محل (Offsite): نسخه ای که در مکانی فیزیکی متفاوت از محل اصلی داده ها نگهداری می شود تا در برابر بلایای محلی و سرقت محافظت شوید .
استراتژی 3-2-1 چیست و منطق پشت هر عدد
اگر فقط یک قانون در دنیای پشتیبان گیری وجود داشته باشد که تقریباً همه متخصصان امنیت و مدیران سیستم روی آن اتفاق نظر دارند، همان قانون 3-2-1 است. این استراتژی ساده اما عمیقاً مؤثر، از یک اصل بنیادین نشأت می گیرد: هیچ نقطه ای از شکست نباید بتواند به تنهایی تمام نسخه های داده شما را از بین ببرد. قانون 3-2-1 نخستین بار توسط پیتر کروگ (Peter Krogh)، عکاس و نویسنده حوزه مدیریت دارایی های دیجیتال، در کتابی که در سال ۲۰۰۹ منتشر کرد به شکلی ساختارمند معرفی شد . هرچند او ابداع کننده این مفهوم نبود، اما نخستین فردی بود که آن را به زبانی ساده و قابل اجرا ارائه داد؛ به گونه ای که در سال ۲۰۱۲، تیم واکنش به فوریت های رایانه ای آمریکا (US-CERT) نیز در سندی رسمی از نقش او در ترویج این مفهوم قدردانی کرد .
این قانون بر سه اصل استوار است که هر عدد آن، پاسخی به یک دسته مشخص از تهدیدهاست. در ادامه هر عدد را جداگانه می شکافیم تا منطق پشت آن برای شما روشن شود.
سه نسخه از داده ها — چرا یک یا دو نسخه کافی نیست
اولین عدد در قانون 3-2-1 به تعداد نسخه ها اشاره دارد: شما باید حداقل سه نسخه از داده ها داشته باشید. یک نسخه همان داده اصلی است که روزانه با آن کار می کنید (Production Data) و دو نسخه دیگر به عنوان سه کپی بکاپ نگهداری می شوند . این ساختار که با مفهوم افزونگی (Data Redundancy) گره خورده است، یک واقعیت تلخ را می پذیرد: خرابی، حذف تصادفی و حملات سایبری نه احتمال، بلکه اجتناب ناپذیرند.
چرا یک نسخه پشتیبان کافی نیست؟ چون خود آن نسخه نیز ممکن است قربانی همان رویدادی شود که داده اصلی را از بین برده است. اگر بکاپ شما روی همان دیسکی باشد که داده اصلی روی آن قرار دارد و آن دیسک خراب شود، هر دو نسخه با هم از بین می روند. دو نسخه کمی بهتر است، اما هنوز یک نقطه شکست مشترک باقی می ماند: اگر هر دو نسخه پشتیبان روی یک دستگاه ذخیره شده باشند و آن دستگاه دچار حریق شود یا باج افزار (Ransomware) آن را رمزگذاری کند، شما هر دو نسخه پشتیبان را از دست می دهید. نسخه سوم، این شکاف را پر می کند. با وجود سه نسخه، حتی اگر دو نسخه همزمان از بین بروند—مثلاً یک خرابی سخت افزاری و یک حذف تصادفی—هنوز یک نسخه سالم باقی می ماند که می توانید به آن تکیه کنید .
این عدد در واقع یک حاشیه امنیت ایجاد می کند: شما همیشه یک نسخه «اضافه» دارید که وقتی دو نسخه دیگر درگیر مشکل شده اند، به میدان می آید.
دو نوع رسانه ذخیره سازی — چرا تنوع رسانه حیاتی است
عدد دوم در 3-2-1 backup rule از یک درس ساده اما حیاتی می آید: اگر همه نسخه های پشتیبان روی یک نوع رسانه ذخیره سازی باشند، یک نقص یا خرابی مختص به آن رسانه می تواند همه آن ها را همزمان از بین ببرد. این پدیده که با نام نقطه شکست مشترک (Shared Failure Mode) شناخته می شود، دقیقاً همان چیزی است که قانون 3-2-1 با عدد «۲» از آن جلوگیری می کند.
منظور از انواع رسانه بکاپ چیست؟ در دنیای امروز، گزینه های متنوعی پیش روی شماست: HDD (هارد دیسک مکانیکی)، SSD (درایو حالت جامد)، Cloud Storage (ذخیره سازی ابری)، NAS (ذخیره سازی متصل به شبکه)، و Tape (نوار مغناطیسی). هر کدام از این رسانه ها الگوهای خرابی متفاوتی دارند. HDD ممکن است به دلیل خرابی مکانیکی از کار بیفتد، در حالی که SSD معمولاً به دلیل فرسودگی سلول های حافظه یا خطای فریمور از بین می رود . ذخیره سازی ابری در برابر بلایای محلی مقاوم است اما به دسترسی شبکه و پایداری ارائه دهنده وابسته است. Tape به طور ذاتی آفلاین است و همین ویژگی آن را در برابر باج افزار که فقط به نسخه های متصل به شبکه دسترسی دارد، مقاوم می کند .
در این بخش، یک جدول مقایسه می تواند انتخاب را برای شما روشن تر کند:
| رسانه | سرعت بازیابی | هزینه | امنیت در برابر باج افزار | مناسب برای |
|---|---|---|---|---|
| HDD | سریع (محلی) | پایین | ضعیف (اگر متصل باشد) | نسخه محلی |
| SSD | بسیار سریع | متوسط تا بالا | ضعیف (اگر متصل باشد) | نسخه محلی سریع |
| Cloud Storage | وابسته به اینترنت | متغیر (اشتراکی) | متوسط (به پیکربندی بستگی دارد) | نسخه Offsite |
| NAS | سریع (شبکه محلی) | متوسط | ضعیف تا متوسط (اگر به شبکه متصل باشد) | نسخه محلی/Offsite |
| Tape | کند | پایین (به ازای هر ترابایت) | بسیار قوی (آفلاین) | نسخه آرشیوی Offsite |
انتخاب دو نوع رسانه متفاوت، به این معنا نیست که باید گران ترین تجهیزات را بخرید. برای بسیاری از کاربران، ترکیب «هارد اکسترنال + فضای ابری» یا «NAS + فضای ابری» کافی است. نکته کلیدی این است که رسانه ها از نظر فنی و الگوی شکست، مستقل از یکدیگر باشند. دو پارتیشن روی یک دیسک، یا دو هارد از یک مدل در یک رک، دو رسانه متفاوت محسوب نمی شوند. اگر علاقه داشتید مقایسه انواع حافظه ابری و اکسترنال SSD و HDD را بیشتر بدانید حتما به مقاله مقایسه حافظه ابری و اکسترنال SSD و HDD در نیکس فایل سر بزنید.
یک نسخه خارج از محل — چرا offsite بودن کافی نیست
عدد سوم در استراتژی 3-2-1 به موقعیت فیزیکی نسخه های پشتیبان مربوط می شود: حداقل یکی از نسخه ها باید در مکانی جدا از محل اصلی داده ها نگهداری شود. این نسخه که با عنوان نسخه offsite یا بکاپ خارج از محل شناخته می شود، شما را در برابر سناریوهایی محافظت می کند که هیچ مقدار افزونگی محلی نمی تواند از عهده آن ها برآید: حریق، سیل، سرقت، یا حتی یک حمله فیزیکی که تمام تجهیزات یک اتاق را نابود می کند .
اما در اینجا یک نکته حیاتی وجود دارد که بسیاری از افراد از آن غافل می شوند: offsite بودن کافی نیست. یک نسخه offsite که از طریق شبکه به سیستم اصلی متصل است، هنوز در معرض خطر باج افزار قرار دارد. اگر مهاجم به شبکه شما نفوذ کند و اعتبارنامه های دسترسی به فضای ابری یا سرور راه دور شما را به دست آورد، می تواند نسخه offsite شما را نیز رمزگذاری یا حذف کند . اینجاست که مفهوم Air-gapped Backup (بکاپ جدا از شبکه) وارد می شود. یک نسخه air-gapped به طور فیزیکی از شبکه جدا شده است—مثل یک نوار مغناطیسی که در گاوصندوق نگهداری می شود یا یک هارد اکسترنالی که پس از اتمام بکاپ از سیستم جدا می شود .
پس تفاوت کلیدی این است: offsite یعنی «مکان متفاوت»، اما offline یعنی «عدم دسترسی شبکه ای». قانون 3-2-1 اصلی، offsite را الزامی می کند اما offline را نه. همین شکاف است که در سال های اخیر باعث تکامل این قانون به نسخه های پیشرفته تری مانند 3-2-1-1-0 شده است که در بخش های بعدی به آن خواهیم پرداخت.
چرا 3-2-1 یک استاندارد صنعتی شده است
قانون 3-2-1 صرفاً یک توصیه از یک متخصص نیست؛ این استراتژی توسط نهادهای معتبر و چارچوب های امنیتی در سراسر جهان به رسمیت شناخته شده است. آژانس امنیت سایبری و امنیت زیرساخت آمریکا (CISA) این قانون را به عنوان یک استاندارد پایه برای حفاظت از داده های کسب وکار توصیه می کند . این توصیه با کنترل های چارچوب امنیت سایبری NIST برای ایجاد، محافظت و تست بکاپ هم راستا است .
دلیل این پذیرش گسترده، سادگی و اثربخشی این قانون است. قانون 3-2-1 یک زبان مشترک ایجاد می کند: وقتی CISA، NIST و تقریباً همه فروشندگان بزرگ راهکارهای بکاپ درباره طراحی پشتیبان گیری صحبت می کنند، از همین سه عدد شروع می کنند. این یکدستی، قانون 3-2-1 را به یک «کف قابل اعتماد» تبدیل می کند؛ یک نقطه شروع که می توانید مطمئن باشید زیر آن، شکاف obvious وجود دارد .
علاوه بر این، قانون 3-2-1 با disaster recovery (بازیابی پس از فاجعه) گره خورده است. در دنیایی که حملات سایبری—به ویژه باج افزار—به یک تهدید روزمره تبدیل شده اند، داشتن یک استراتژی پشتیبان گیری که از نظر معماری مقاوم باشد، نه یک لوکس، بلکه یک ضرورت است. آمارها نشان می دهد که در حملات باج افزار، ۹۴٪ قربانیان گفته اند مهاجمان تلاش کرده اند بکاپ های آن ها را نیز compromise کنند و ۵۷٪ از این تلاش ها موفق بوده است . این آمار به خوبی توضیح می دهد چرا یک استراتژی ساده و آزموده مانند 3-2-1، همچنان پس از سال ها، استاندارد طلایی صنعت باقی مانده است.
پیتر کروگ و قانونی که او معرفی کرد، امروز توسط CISA و NIST به عنوان نقطه شروع توصیه می شود، اما خود این نهادها نیز اذعان دارند که در عصر باج افزار، 3-2-1 به تنهایی کافی نیست و باید با لایه های امنیتی بیشتری مانند immutable backup و تست بازیابی تکمیل شود—موضوعی که در ادامه این راهنما به آن خواهیم پرداخت.
گام های عملی پیاده سازی 3-2-1
تا اینجا فهمیدیم که قانون 3-2-1 چیست و چرا هر عدد آن اهمیت دارد. اما دانستن «چیستی» کافی نیست؛ آنچه یک استراتژی پشتیبان گیری را از یک ایده ذهنی به یک سیستم واقعی تبدیل می کند، پیاده سازی درست آن است. در این بخش، یک فرآیند شش مرحله ای را مرور می کنیم که شما را از نقطه صفر به یک سیستم 3-2-1 عملیاتی می رساند. این گام های پیاده سازی به گونه ای طراحی شده اند که هم برای کاربر خانگی و هم برای یک تیم IT قابل استفاده باشند. پیش از شروع، یک نمای کلی از این شش گام و خروجی هرکدام را ببینید.
| گام | عنوان | خروجی |
|---|---|---|
| گام ۱ | شناسایی و طبقه بندی داده های حیاتی | فهرست اولویت بندی شده داده ها |
| گام ۲ | تعیین RPO و RTO | اهداف بازیابی مشخص برای هر دسته داده |
| گام ۳ | انتخاب رسانه های ذخیره سازی | دو رسانه مستقل + یک مقصد offsite |
| گام ۴ | تنظیم زمان بندی و خودکارسازی | زمان بندی بکاپ فعال و خودکار |
| گام ۵ | امن سازی نسخه ها | نسخه های رمزگذاری شده و immutable |
| گام ۶ | تست و اعتبارسنجی | گزارش تست بازیابی موفق |
گام 1 — شناسایی و طبقه بندی داده های حیاتی
نخستین گام در پیاده سازی 3-2-1، پیش از خرید هر هارد یا اشتراک ابری، شناسایی داده حیاتی و طبقه بندی داده شماست. بسیاری از افراد بلافاصله سراغ ابزار و سخت افزار می روند، در حالی که بدون دانستن «چه چیزی را باید محافظت کنیم»، هر پیکربندی صرفاً یک تلاش کورکورانه است. در این گام باید مشخص کنید کدام داده ها واقعاً ارزش پشتیبان گیری دارند و کدام ها را می توان در صورت خرابی از نو ساخت.
داده ها را می توان به دو دسته بزرگ تقسیم کرد: داده غیرقابل بازسازی (Critical Data) و داده قابل بازسازی (Rebuildable Data). داده غیرقابل بازسازی شامل چیزهایی است که اگر از بین بروند، دیگر نمی توان آن ها را تولید کرد: عکس ها و ویدیوهای شخصی، اسناد مالی، قراردادها، پایگاه های داده مشتریان، کدهای منبع پروژه، و فایل های تنظیمات (Config) سرورها. داده قابل بازسازی شامل سیستم عامل، برنامه های نصب شده، فایل های کش، و داده هایی است که می توان آن ها را دوباره از منابع اصلی (مثل DVD نصب یا مخزن نرم افزار) تهیه کرد.
یک اولویت بندی ساده به شما کمک می کند منابع محدود خود را در جای درست متمرکز کنید. می توانید از یک جدول طبقه بندی مانند نمونه زیر استفاده کنید:
| نوع داده | اهمیت | محل ذخیره | نسخه اصلی/کپی | RPO تقریبی |
|---|---|---|---|---|
| اسناد کاری | بحرانی | لپ تاپ | اصلی + ۲ کپی | ۱ روز |
| عکس های خانوادگی | بحرانی | هارد داخلی | اصلی + ۲ کپی | ۷ روز |
| دیتابیس مشتریان | حیاتی | سرور | اصلی + ۲ کپی | ۱ ساعت |
| فایل های سیستمی | قابل بازسازی | SSD | فقط اصلی | ندارد |
| کش مرورگر | بی اهمیت | SSD | ندارد | ندارد |
پس از این طبقه بندی، نسخه ای از این جدول را در جای امنی نگه دارید. این سند در گام های بعدی—به ویژه هنگام تعیین RPO و RTO—به کارتان می آید.
گام 2 — تعیین RPO و RTO برای داده های مختلف
وقتی فهرست داده های حیاتی خود را دارید، نوبت به تعیین دو شاخص کلیدی می رسد که ستون فقرات هر استراتژی پشتیبان گیری را تشکیل می دهند: RPO و RTO. این دو مفهوم اغلب با هم اشتباه گرفته می شوند، در حالی که به دو سؤال کاملاً متفاوت پاسخ می دهند.
RPO یا هدف نقطه بازیابی (Recovery Point Objective) به این سؤال پاسخ می دهد: «چقدر داده می توانم از دست بدهم؟» این شاخص، حداکثر بازه زمانی قابل قبول بین آخرین بکاپ و لحظه خرابی را مشخص می کند. اگر RPO شما یک ساعت باشد، یعنی در بدترین حالت، یک ساعت داده (تغییرات پس از آخرین بکاپ) را از دست می دهید. RPO مستقیماً فرکانس بکاپ شما را تعیین می کند.
RTO یا هدف زمان بازیابی (Recovery Time Objective) به این سؤال پاسخ می دهد: «چقدر می توانم بدون دسترسی به داده ها بمانم؟» این شاخص، حداکثر زمان خرابی قابل تحمل است—یعنی چقدر طول می کشد تا سیستم را از بکاپ بازیابی کنید و به کار عادی برگردید. RTO به سرعت رسانه، اندازه داده، و پیچیدگی فرآیند بازیابی بستگی دارد.
تفاوت این دو را می توان در یک تصویر ساده خلاصه کرد: RPO به «عقب گرد» (چقدر داده از دست می رود) مربوط است و RTO به «جلو رو» (چقدر زمان تا بازگشت به حالت عادی). RPO پایین یعنی بکاپ های مکرر؛ RTO پایین یعنی بازیابی سریع و کارآمد.
| نوع داده | RPO | RTO | فرکانس پیشنهادی |
|---|---|---|---|
| دیتابیس تراکنشی | ۱۵ دقیقه | ۱ ساعت | هر ۱۵ دقیقه (snapshot) |
| اسناد کاری | ۱ روز | ۴ ساعت | روزانه |
| عکس و ویدیو | ۷ روز | ۲۴ ساعت | هفتگی |
| تنظیمات سرور | ۱ روز | ۲ ساعت | روزانه |
نکته کلیدی این است که RPO و RTO برای همه داده ها یکسان نیست. یک کسب وکار ممکن است برای دیتابیس تراکنشی RPO پانزده دقیقه ای تعیین کند، اما برای آرشیو عکس های قدیمی RPO یک هفته ای کافی باشد. این تفکیک، به شما اجازه می دهد منابع را هوشمندانه تخصیص دهید: بکاپ های مکرر فقط برای داده هایی که واقعاً نیاز دارند، و بکاپ های کم تکرار برای بقیه. اگر در تعیین RPO و RTO تازه کار هستید، از یک قاعده ساده شروع کنید: «چقدر داده از دست دادن برای من قابل تحمل است؟» و «چقدر زمان بدون داده می توانم دوام بیاورم؟» پاسخ صادقانه به این دو سؤال، اعداد اولیه شما را مشخص می کند.
گام 3 — انتخاب رسانه های ذخیره سازی
اکنون که می دانید چه داده هایی دارید و اهداف بازیابی شما چیست، زمان انتخاب رسانه بکاپ فرا رسیده است. این گام نیازمند یک تصمیم مقایسه ای آگاهانه است، زیرا رسانه انتخابی شما مستقیماً بر RTO (سرعت بازیابی) و هزینه کل تأثیر می گذارد.
بر اساس قانون 3-2-1، شما به دو رسانه مستقل و یک مقصد offsite نیاز دارید. رسانه های اصلی که در دسترس شما هستند عبارتند از External HDD (هارد اکسترنال)، NAS (ذخیره سازی متصل به شبکه)، و Cloud Storage (فضای ذخیره سازی ابری). انتخاب بین این ها به ظرفیت، سرعت، هزینه و امنیت مورد نیاز شما بستگی دارد.
| رسانه | مزایا | معایب | مناسب برای |
|---|---|---|---|
| External HDD | ارزان، ظرفیت بالا، سرعت خوب | شکننده، نیاز به اتصال دستی، در معرض سرقت | بکاپ محلی روزانه |
| NAS | دسترسی شبکه ای، RAID، چند کاربره | هزینه اولیه بالاتر، نیاز به تنظیمات شبکه | کسب وکار کوچک، بکاپ محلی متمرکز |
| Cloud Storage | دسترسی از هرجا، مقیاس پذیر، offsite ذاتی | وابسته به اینترنت، هزینه اشتراکی ماهانه، مسائل حریم خصوصی | نسخه offsite، تیم دورکار |
| Tape | آفلاین، عمر طولانی، هزینه به ازای ترابایت پایین | کند، نیاز به درایو مخصوص | آرشیو بلندمدت، انطباق |
نکته ای که بسیاری از افراد از آن غافل می شوند این است که «دو رسانه» نباید از یک جنس باشند. دو هارد اکسترنال از یک مدل، یا دو فضای ابری از یک ارائه دهنده، دو رسانه مستقل محسوب نمی شوند. اگر آن مدل هارد دچار یک نقص فریمور شود، یا آن ارائه دهنده ابری دچار قطعی سراسری شود، هر دو نسخه شما همزمان از دست می روند. استقلال رسانه به معنای استقلال در فناوری، ارائه دهنده و الگوی شکست است.
گام 4 — تنظیم زمان بندی و خودکارسازی
یک استراتژی پشتیبان گیری که به دست انسان وابسته باشد، دیر یا زود شکست می خورد. خودکارسازی بکاپ و زمان بندی بکاپ درست، تفاوت بین یک سیستم واقعی و یک آرزوی خوب است. در این گام، بکاپ های خود را طوری پیکربندی می کنید که بدون دخالت شما اجرا شوند.
ابزارهای زمان بندی بسته به سیستم عامل شما متفاوت اند. در لینوکس، Cron ابزار استاندارد برای زمان بندی وظایف است. در ویندوز، Task Scheduler این نقش را ایفا می کند. اکثر نرم افزارهای بکاپ تجاری نیز دارای زمان بند داخلی هستند که کار را ساده تر می کند. صرف نظر از ابزار، اصل کلی این است: یک بکاپ روزانه برای داده های فعال، یک بکاپ هفتگی برای داده های کم تغییر، و یک بکاپ شبانه برای حجم های بزرگ که در ساعات کم ترافیک اجرا می شود.
| نوع داده | فرکانس پیشنهادی | زمان اجرا |
|---|---|---|
| دیتابیس | هر ۱ ساعت یا ۱۵ دقیقه | ۲۴/۷ |
| اسناد کاری | روزانه | پایان روز کاری |
| ایمیل و تقویم | روزانه | نیمهشب |
| عکس و ویدیو | هفتگی | آخر هفته، شبانه |
| آرشیو بلندمدت | ماهانه | ابتدای ماه |
یک تنظیم نمونه در Task Scheduler ویندوز می تواند به این شکل باشد: یک وظیفه روزانه در ساعت ۲ بامداد که یک اسکریپت بکاپ را اجرا می کند، خروجی را به هارد اکسترنال می نویسد و سپس یک نسخه هم به فضای ابری آپلود می کند. در لینوکس، یک خط Cron مانند 0 2 * * * /usr/local/bin/backup.sh همین کار را انجام می دهد.
نکته مهم در خودکارسازی این است که بکاپ باید بی صدا و بدون نیاز به تأیید اجرا شود. اگر هر بار از شما بپرسد «آیا می خواهی بکاپ بگیری؟» دیر یا زود آن را رد می کنید. همچنین، بکاپ خودکار باید گزارش خطا تولید کند تا اگر بکاپی شکست خورد، شما مطلع شوید. یک بکاپ خودکار که بی سروصدا شکست می خورد، بدتر از یک بکاپ دستی است که می دانید انجام نشده.
گام 5 — امن سازی نسخه ها (رمزگذاری و immutable)
تا این مرحله، شما یک سیستم پشتیبان گیری منظم و خودکار دارید. اما در دنیای امروز، صرفاً داشتن بکاپ کافی نیست؛ بکاپ شما باید در برابر حمله نیز مقاوم باشد. باج افزار به طور خاص طراحی شده تا بکاپ ها را پیدا کند، رمزگذاری کند، و اخاذی را کامل کند. اگر بکاپ شما رمزگذاری نشده و قابل تغییر باشد، مهاجم می تواند آن را نیز قربانی کند.
دو لایه امنیتی کلیدی در این گام وجود دارد: رمزگذاری بکاپ و immutable backup (بکاپ غیرقابل تغییر).
رمزگذاری با الگوریتم هایی مانند AES-256 انجام می شود و تضمین می کند که حتی اگر مهاجم به فایل های بکاپ شما دسترسی پیدا کند، نتواند محتوای آن ها را بخواند. رمزگذاری باید در مبدأ (یعنی قبل از خروج داده از سیستم شما) انجام شود، نه در مقصد. اگر رمزگذاری در مقصد انجام شود، داده در مسیر انتقال در معرض خطر است. کلید رمزگذاری را جدا از بکاپ و در جای امنی نگهداری کنید—اگر کلید را گم کنید، بکاپ شما عملاً از بین رفته است.
Immutable backup یا بکاپ غیرقابل تغییر، لایه دوم دفاعی است. این ویژگی که با نام های Object Lock و WORM (Write Once Read Many) نیز شناخته می شود، تضمین می کند که پس از نوشته شدن یک نسخه بکاپ، هیچ کس—نه شما، نه مهاجم، نه حتی مدیر سیستم—نتواند آن را تغییر دهد یا حذف کند تا زمانی که دوره نگهداری (Retention Period) به پایان برسد . این ویژگی مستقیماً از air-gapped بودن الهام گرفته است: همان طور که یک نوار مغناطیسی فیزیکی در گاوصندوق در برابر دسترسی شبکه ای مقاوم است، یک نسخه immutable نیز در برابر هرگونه تغییر آنلاین مقاوم است.
در پیاده سازی 3-2-1 مدرن، توصیه می شود حداقل یکی از نسخه های offsite شما immutable باشد. بسیاری از ارائه دهندگان فضای ذخیره سازی ابری و NASهای سازمانی امروزه از Object Lock پشتیبانی می کنند. در سمت رمزگذاری، اگر از ابزارهایی مانند Duplicati، Restic یا Veeam استفاده می کنید، گزینه رمزگذاری به صورت داخلی وجود دارد.
یک اشتباه رایج این است که افراد فقط داده اصلی را رمزگذاری می کنند و بکاپ را فراموش می کنند. در حالی که یک بکاپ رمزگذاری نشده، یک در پشتی به تمام داده های شماست. رمزگذاری بکاپ را نه به عنوان یک گزینه، بلکه به عنوان یک پیش فرض در نظر بگیرید.
گام 6 — تست و اعتبارسنجی نسخه ها
آخرین گام، و شاید مهم ترین گامی که بیشتر افراد از آن غافل می شوند، تست بکاپ و اعتبارسنجی بکاپ است. یک بکاپ که هرگز تست نشده، یک بکاپ نیست؛ یک امید است. بسیاری از سازمان ها فاجعه هایی را تجربه کرده اند که در آن ها بکاپ وجود داشت اما در لحظه حساس، بازیابی آزمایشی شکست خورد—به دلیل نسخه خراب، خطای بازیابی، یا فراموش کردن رمز عبور.
تست بازیابی باید به یک رویه منظم تبدیل شود. حداقل هر سه ماه یک بار، یک فایل یا مجموعه ای از فایل ها را از بکاپ خود بازیابی کنید و بررسی کنید که محتوا سالم و کامل است. این کار را در یک محیط آزمایشی انجام دهید، نه روی سیستم اصلی. اگر بکاپ شما شامل دیتابیس است، یک نسخه از دیتابیس را بازیابی کنید و یک کوئری ساده روی آن اجرا کنید تا از صحت داده ها مطمئن شوید.
چند نکته کلیدی در اعتبارسنجی بکاپ:
- بررسی یکپارچگی فایل ها: آیا فایل های بازیابی شده دقیقاً همان هایی هستند که انتظار دارید؟ آیا اندازه و تاریخ آن ها درست است؟
- تست رمزگشایی: اگر بکاپ رمزگذاری شده، آیا کلید رمزگذاری کار می کند؟ آیا می توانید داده را رمزگشایی کنید؟
- تست از هر دو رسانه: هم نسخه محلی و هم نسخه offsite را جداگانه تست کنید. ممکن است یکی از آن ها خراب باشد و شما ندانید.
- مستندسازی نتایج: هر تست را با تاریخ، نوع داده، و نتیجه ثبت کنید. این سابقه به شما می گوید کدام بخش های استراتژی شما قابل اعتمادند و کدام ها نیاز به بهبود دارند.
یک چک لیست ساده برای تست دوره ای می تواند شامل این موارد باشد: انتخاب یک فایل تصادفی، بازیابی آن، باز کردن آن، مقایسه با نسخه اصلی، و ثبت نتیجه. برای دیتابیس ها، یک بازیابی کامل در محیط تست و اجرای چند کوئری اعتبارسنجی کافی است. در نهایت، به یاد داشته باشید که تست بازیابی نه یک کار یک باره، بلکه یک فرآیند مداوم است. هر تغییری در زیرساخت، ابزار، یا داده های شما می تواند بر قابلیت بازیابی تأثیر بگذارد، بنابراین تست ها باید همگام با تغییرات سیستم شما تکرار شوند.
با تکمیل این شش گام، شما یک سیستم 3-2-1 واقعی و عملیاتی دارید: داده های حیاتی تان شناسایی شده، اهداف بازیابی تان مشخص است، رسانه هایتان متنوع و مستقل اند، بکاپ ها خودکار اجرا می شوند، نسخه ها رمزگذاری شده و immutable هستند، و شما به طور منظم صحت آن ها را آزمایش می کنید.
هیچ دیدگاهی ثبت نشده است.