آیا تا به حال به این فکر کرده اید که اگر فردا هارد لپ تاپتان بسوزد، چه اتفاقی برای عکس ها، اسناد کاری و پروژه های چند ساله تان می افتد؟ بسیاری از ما می دانیم که بکاپ چیست و چرا اهمیت دارد، اما دانستن با انجام دادن فاصله دارد. در این راهنمای گام به گام، قصد داریم استراتژی 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 (فضای ذخیره سازی ابری). انتخاب بین این ها به ظرفیت، سرعت، هزینه و امنیت مورد نیاز شما بستگی دارد. اگر به دنبال یک راهکار ساده و در دسترس برای نسخه offsite هستید، می توانید از یک سرویس داخلی برای آپلود فایل و نگهداری نسخه پشتیبان در فضای ابری استفاده کنید.
| رسانه | مزایا | معایب | مناسب برای |
|---|
| 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 هستند، و شما به طور منظم صحت آن ها را آزمایش می کنید.
پیاده سازی 3-2-1 در سناریوهای مختلف
قانون 3-2-1 یک اصل کلی است، اما پیاده سازی 3-2-1 برای کسب و کار یا کاربر خانگی بسته به اندازه زیرساخت، تعداد دستگاه ها و سطح حساسیت داده ها متفاوت می شود . در این بخش، پنج سناریوی 3-2-1 رایج را بررسی می کنیم؛ از یک رایانه شخصی تا محیط های مجازی شده. هر سناریو نشان می دهد چگونه می توان سه اصل «۳ نسخه، ۲ رسانه، ۱ offsite» را با منابع و محدودیت های همان محیط تطبیق داد.
| سناریو | ۳ نسخه | ۲ رسانه | ۱ Offsite |
|---|
| کاربر خانگی | SSD داخلی + هارد اکسترنال + فضای ابری | HDD + Cloud | فضای ابری |
| کسب وکار کوچک | سرور/NAS + هارد اکسترنال + فضای ابری | NAS + Cloud | فضای ابری یا هارد چرخشی |
| تیم دورکار | لپ تاپ + فضای ابری مرکزی + آرشیو سرور | Endpoint + Cloud | فضای ابری |
| سرور لینوکس/ویندوز | دیسک اصلی + دیسک بکاپ + فضای ابری | دیسک محلی + Cloud | فضای ابری |
| ماشین مجازی | VM اصلی + Image بکاپ + Cloud | Datastore + Cloud | فضای ابری |
سناریوی 1 — کاربر خانگی با یک رایانه شخصی
برای یک کاربر خانگی با یک کامپیوتر شخصی، پیاده سازی 3-2-1 ساده تر از آن است که تصور می شود. داده هایی که باید محافظت شوند معمولاً شامل اسناد، عکس و فایل های شخصی هستند . یک ترکیب عملی و کم هزینه می تواند به این شکل باشد: External HDD به عنوان نسخه محلی دوم، و Cloud Storage (مانند OneDrive یا Google Drive) به عنوان نسخه offsite.
نکته کلیدی برای کاربر خانگی این است که Sync را با Backup اشتباه نگیرد. سرویس هایی مانند OneDrive یا Google Drive فایل ها را بین دستگاه ها همگام می کنند، اما اگر یک فایل حذف شود یا باج افزار آن را رمزگذاری کند، این تغییرات به نسخه ابری نیز منتقل می شود . بنابراین، فضای ابری باید به عنوان یک نسخه مستقل پیکربندی شود، نه صرفاً یک پوشه همگام شده.
یک راهکار ساده: یک هارد اکسترنال تهیه کنید و یک اسکریپت یا نرم افزار بکاپ (مانند Macrium Reflect یا Veeam Agent Free) را طوری تنظیم کنید که هر هفته یک نسخه کامل به هارد بنویسد. همزمان، یک سرویس ابری با versioning (تاریخچه نسخه ها) فعال کنید تا اگر فایلی به طور تصادفی حذف شد، بتوانید نسخه قدیمی تر را بازیابی کنید . این ترکیب، قانون 3-2-1 را با هزینه ای معقول برآورده می کند.
سناریوی 2 — کسب وکار کوچک (سرور محلی و چند ایستگاه کاری)
برای یک کسب وکار کوچک (SMB) که یک سرور محلی و چند ایستگاه کاری دارد، داده های حیاتی شامل داده مشتری، اسناد مالی و فایل های عملیاتی می شود. در این سطح، پیاده سازی 3-2-1 نیازمند یک رویکرد متمرکزتر است .
یک معماری رایج شامل سه لایه است: بکاپ محلی سریع روی یک NAS (برای بازیابی های روزمره با سرعت بالا)، بکاپ دوم روی یک هارد اکسترنال که به صورت دوره ای به مکان دیگری منتقل می شود (یا یک نسخه immutable در فضای ابری)، و نسخه offsite روی Cloud Storage. برای ایستگاه های کاری، نرم افزار Endpoint Backup روی هر دستگاه نصب می شود تا فایل های محلی کاربران نیز پوشش داده شوند .
یک اشتباه رایج در SMBها این است که تصور می کنند فقط سرور نیاز به بکاپ دارد. در حالی که بسیاری از اسناد حیاتی روی لپ تاپ های کارکنان پراکنده اند . راه حل، استقرار یک نرم افزار بکاپ مرکزی است که هم سرور و هم ایستگاه های کاری را از یک داشبورد مدیریت کند. همچنین، تنظیمات سرور (کانفیگ ها، اسکریپت ها) باید جداگانه بکاپ گرفته شوند، زیرا بازیابی آن ها معمولاً سریع تر از داده های حجیم است.
سناریوی 3 — تیم دورکار و دستگاه های پراکنده
بکاپ تیم دورکار و بکاپ دورکاری یکی از چالش برانگیزترین سناریوهاست، زیرا دستگاه ها در مکان های مختلف پراکنده اند و اغلب از شبکه سازمانی خارج می شوند . در این حالت، دستگاه های پراکنده ممکن است هرگز به بکاپ محلی متصل نشوند و داده های روی لپ تاپ ها در معرض خطر بیشتری قرار دارند.
راه حل اصلی، استقرار Endpoint Backup روی هر دستگاه است که مستقیماً به یک Cloud Backup مرکزی متصل شود . نکته مهم این است که Remote devices نباید به عنوان استثنا در نظر گرفته شوند. همه لپ تاپ ها—چه در خانه و چه در اداره—باید در یک سیاست بکاپ یکسان قرار بگیرند. برای داده های حساس تر، می توان یک VPS یا سرور ابری به عنوان نسخه offsite اضافه کرد تا حتی در صورت از دست رفتن دستگاه، داده ها در یک مکان امن باقی بمانند .
سناریوی 4 — سرور لینوکس یا ویندوز
بکاپ سرور لینوکس یا بکاپ سرور ویندوز نیازمند دقت بیشتری است، زیرا دیتابیس ها، کانفیگ ها و اسکریپت های در حال اجرا باید به صورت consistent بکاپ گرفته شوند . برای سرور لینوکس، ابزارهایی مانند Rsync و Duplicati گزینه های رایجی هستند. Rsync با استفاده از یک اسکریپت ساده و زمان بندی Cron می تواند فایل ها را به یک مقصد محلی و سپس به یک مقصد offsite منتقل کند .
برای سرور ویندوز، Windows Backup یا ابزارهای شخص ثالث مانند Veeam Agent و Duplicati قابل استفاده اند. در هر دو سیستم عامل، یک الگوی رایج این است: بکاپ روزانه به یک دیسک محلی (برای بازیابی سریع)، بکاپ هفتگی به یک هارد اکسترنال که خارج از سرور نگهداری می شود، و بکاپ شبانه به فضای ابری. برای دیتابیس ها، حتماً از Application-consistent backup استفاده کنید تا تراکنش های در حال اجرا از دست نروند .
نکته فنی مهم: اگر از SAS یا دیسک های enterprise استفاده می کنید، این دیسک ها به خودی خود بکاپ نمی گیرند و باید در یک چارچوب نرم افزاری قرار بگیرند . برای کانفیگ های سرور، یک بکاپ ساده از فایل های تنظیمات (مثل /etc در لینوکس یا Registry در ویندوز) کافی است، اما حتماً آن را در چرخه بکاپ بگنجانید.
سناریوی 5 — ماشین های مجازی و زیرساخت مجازی
بکاپ ماشین مجازی (VM) با بکاپ فایل های معمولی تفاوت اساسی دارد، زیرا شما با یک Image کامل از سیستم عامل، اپلیکیشن ها و تنظیمات سر و کار دارید . مهم ترین تمایز در این سناریو، تفاوت بین VM Snapshot و بکاپ است. یک Snapshot یک تصویر لحظه ای از وضعیت دیسک است که در همان Datastore ذخیره می شود و برای rollback سریع در چند ساعت یا چند روز مناسب است، اما جایگزین بکاپ نیست. Snapshot روی همان storage تولید است و اگر آن storage از بین برود، snapshot نیز از بین می رود.
برای پیاده سازی 3-2-1 در محیط VMware یا Hyper-V، بهترین رویکرد استفاده از Image-level backup است. این نوع بکاپ کل ماشین مجازی را به صورت یک image قابل بازیابی ذخیره می کند و می تواند روی ماشین میزبان دیگر یا حتی هایپروایزر متفاوت بازیابی شود . بکاپ agentless برای Hyper-V و VMware رایج است و از Snapshot فقط به عنوان مکانیزم خواندن داده consistent استفاده می کند، نه به عنوان نسخه نهایی.
در این سناریو، هایپروایزر نقش کلیدی دارد: بکاپ باید از لایه هایپروایزر گرفته شود تا همه VMها به صورت متمرکز پوشش داده شوند. سپس نسخه ها به یک NAS یا Cloud منتقل شوند تا قانون 3-2-1 برآورده شود. برای ماشین های حیاتی مانند SQL Server یا Domain Controller، حتماً Application-consistent backup را فعال کنید تا داده ها در حالت قابل بازیابی باشند.
انتخاب ابزار و نرم افزار برای پیاده سازی 3-2-1
پس از آنکه داده های حیاتی خود را شناسایی کردید، RPO و RTO را تعیین نمودید و رسانه های ذخیره سازی را انتخاب کردید، نوبت به یک تصمیم کلیدی می رسد: انتخاب ابزار 3-2-1. درست است که می توان همه کارها را با اسکریپت های دستی و rsync انجام داد، اما ابزارهای اختصاصی نرم افزار پشتیبان گیری فرآیند را خودکار، ایمن و قابل اعتمادتر می کنند. در این بخش، سه دسته اصلی ابزار بکاپ را بررسی می کنیم: گزینه های رایگان و متن باز، راهکارهای تجاری، و چالش های خاص انتخاب ابزار در ایران.
پیش از ورود به جزئیات، یک جدول مقایسه سریع از ابزارهای مطرح شده در این بخش، تصویر کلی را روشن می کند:
| ابزار | نوع | پلتفرم | ویژگی کلیدی | هزینه |
|---|
| Duplicati | متن باز | Windows, macOS, Linux | رمزگذاری AES-256، رابط وب، پشتیبانی از ابرهای متعدد | رایگان |
| Restic | متن باز | Windows, macOS, Linux, FreeBSD | Deduplication، snapshot، تک فایل اجرایی | رایگان |
| Rsync | متن باز | Linux, macOS, Windows (WSL) | همگام سازی سریع، سبک، اسکریپت پذیر | رایگان |
| Veeam | تجاری | Windows, Linux | پشتیبانی از VM، اپلیکیشن ها، immutable backup | رایگان تا سازمانی |
| Acronis | تجاری | Windows, macOS, Linux, Cloud | یکپارچگی بکاپ و امنیت سایبری | اشتراکی |
| MSP360 | تجاری | Windows, macOS, Linux | BYOS (Bring Your Own Storage) | رایگان تا سازمانی |
ابزارهای رایگان و متن باز (Duplicati, Restic, Rsync)
ابزارهای رایگان بکاپ و متن باز برای بسیاری از کاربران و کسب وکارهای کوچک کافی هستند و حتی در محیط های حرفه ای نیز جایگاه خود را دارند. Duplicati، Restic و Rsync سه گزینه ای هستند که بیشترین محبوبیت را در این دسته دارند.
Duplicati یک ابزار متن باز با رابط وب است که روی ویندوز، لینوکس و macOS کار می کند. این ابزار داده ها را به بلوک های کوچک تقسیم می کند، هر بلوک را با AES-256 رمزگذاری می کند و سپس به مقصد ارسال می نماید. در بکاپ های بعدی، فقط بلوک های جدید یا تغییر یافته منتقل می شوند که سرعت و مصرف پهنای باند را به شدت کاهش می دهد . Duplicati از طیف گسترده ای از مقاصد پشتیبانی می کند: FTP، SFTP، WebDAV، NAS، و سرویس های ابری مانند Google Drive، OneDrive، Amazon S3 و Backblaze B2 . یک قابلیت مهم این ابزار، versioning است که به شما اجازه می دهد نسخه های قدیمی فایل ها را بازیابی کنید .
Restic یک ابزار رایگان بکاپ است که به صورت یک فایل اجرایی واحد توزیع می شود و به همین دلیل نصب و انتقال آن بسیار ساده است . این ابزار بر پایه snapshot و deduplication طراحی شده و از S3، Backblaze B2، SFTP و REST پشتیبانی می کند . Restic برای کسانی که با اسکریپت و cron راحت ترند ایده آل است، زیرا CLI ساده و قابل پیش بینی دارد . یکی از مزایای مهم Restic نسبت به برخی رقبا، پشتیبانی از بکاپ همزمان از چند ماشین به یک مخزن مشترک است .
Rsync قدیمی ترین و سبک ترین گزینه در این میان است. این ابزار در اصل یک ابزار همگام سازی است، نه بکاپ. اما با ترکیب –link-dest می توان از آن برای ساخت snapshotهای hard-linked شبیه Time Machine استفاده کرد . Rsync روی لینوکس و macOS به طور پیش فرض وجود دارد و از طریق WSL یا cwRsync روی ویندوز نیز قابل استفاده است . مهم ترین محدودیت Rsync این است که رمزگذاری در حالت سکون ندارد و برای بکاپ های versioned واقعی باید با ابزارهای دیگری مانند rsnapshot ترکیب شود .
جدول مقایسه ابزارهای Duplicati، Restic ،Rsync
| معیار | Duplicati | Restic | Rsync |
|---|
| رمزگذاری | AES-256 داخلی | داخلی | ندارد (نیاز به SSH) |
| Deduplication | دارد | دارد | ندارد |
| رابط گرافیکی | وب UI | ندارد (CLI) | ندارد |
| پشتیبانی ابری | گسترده | گسترده | محدود |
| Snapshot | دارد | دارد | با –link-dest |
بهترین ابزار رایگان بکاپ به نیاز شما بستگی دارد: اگر رابط گرافیکی و پیکربندی ساده می خواهید، Duplicati گزینه اول است . اگر اسکریپت نویسی و کنترل کامل CLI را ترجیح می دهید، Restic انتخاب بهتری است . و اگر فقط به یک همگام سازی سبک و سریع نیاز دارید، Rsync همچنان یک ابزار پایه قابل اعتماد است.
راهکارهای تجاری (Veeam, Acronis, MSP360)
وقتی صحبت از نرم افزار تجاری بکاپ و محیط های سازمانی و enterprise می شود، نیازها فراتر از یک ابزار ساده می رود: immutable backup، مدیریت متمرکز، پشتیبانی از VM، Application-consistent backup و گزارش دهی سازمانی به اولویت تبدیل می شوند. در این سطح، Veeam، Acronis و MSP360 سه نام شناخته شده هستند.
Veeam به عنوان یک نرم افزار تجاری بکاپ برای محیط های VMware و Hyper-V طراحی شده و در سازمان هایی که زیرساخت مجازی سنگین دارند، استاندارد صنعتی محسوب می شود . Veeam از بکاپ سطح ایمیج (Image-level backup)، بکاپ Application-consistent برای SQL و Exchange، و replication پشتیبانی می کند . برای سازمان ها، مدل قیمت گذاری per-socket rental (VCSP) این مزیت را دارد که هزینه ها قابل پیش بینی است و پیچیدگی لایسنس را کاهش می دهد . نقطه ضعف Veeam، وزن راه اندازی آن است؛ برای استقرار در محیط های کوچک، ممکن است بیش از حد سنگین باشد .
Acronis رویکرد متفاوتی دارد: این ابزار بکاپ و امنیت سایبری را در یک پلتفرم ترکیب کرده است. Acronis Cyber Protect نه تنها بکاپ می گیرد، بلکه نسخه های پشتیبان را از نظر باج افزار اسکن می کند و تغییرات فایل ها را برای تشخیص ناهنجاری بررسی می نماید . این یکپارچگی برای سازمان هایی که می خواهند تعداد ابزارهای خود را کاهش دهند، جذاب است. Acronis از per-workload یا per-GB قیمت گذاری می کند .
MSP360 رویکرد BYOS (Bring Your Own Storage) را ارائه می دهد: شما نرم افزار تجاری بکاپ را از MSP360 می گیرید، اما داده ها را در S3، Wasabi، Backblaze B2 یا هر فضای ذخیره سازی که خودتان کنترل می کنید، نگهداری می کنید . این مدل برای سازمان هایی که می خواهند از vendor lock-in اجتناب کنند و هزینه های ذخیره سازی را خودشان مدیریت کنند، بسیار جذاب است . MSP360 از Windows، Linux، macOS، Hyper-V، VMware و SQL Server پشتیبانی می کند و API باز آن برای اتوماسیون مناسب است . نقطه ضعف اصلی MSP360، پیچیدگی لایسنس گذاری آن است که ممکن است در برآورد اولیه هزینه ها را دشوار کند .
جدول مقایسه سریع راهکارهای تجاری
| معیار | Veeam | Acronis | MSP360 |
|---|
| تمرکز اصلی | VM و اپلیکیشن | بکاپ + امنیت | BYOS و انعطاف پذیری |
| مدل قیمت | per-socket | per-workload/GB | per-endpoint |
| پشتیبانی VM | عالی | خوب | خوب |
| Immutable | دارد | دارد | دارد |
| مناسب برای | enterprise | SMB تا enterprise | MSP و SMB |
بهترین نرم افزار تجاری بکاپ به مقیاس و نیاز شما بستگی دارد: برای سازمان های بزرگ با زیرساخت VMware/Hyper-V، Veeam انتخاب اول است . اگر یکپارچگی بکاپ و امنیت را می خواهید، Acronis گزینه مناسب تری است . و اگر می خواهید کنترل کامل روی ذخیره سازی داشته باشید و از قفل شدن به یک vendor اجتناب کنید، MSP360 بهترین گزینه است .
چالش های انتخاب ابزار در ایران (تحریم، فیلتر، پرداخت)
انتخاب ابزار بکاپ در ایران با چالش های منحصر به فردی روبروست که در هیچ راهنمای بین المللی به آن پرداخته نمی شود. تحریم نرم افزار بکاپ و فیلتر دسترسی به سرویس های ابری، دو مانع اصلی هستند که بر انتخاب ابزار و پرداخت ارزی تأثیر مستقیم می گذارند.
در حوزه تحریم، بسیاری از شرکت های ارائه دهنده نرم افزار تجاری بکاپ مانند Veeam، Acronis و MSP360 کاربران ایرانی را تحریم کرده اند یا امکان خرید لایسنس از ایران وجود ندارد. حتی ابزارهای رایگان نیز ممکن است در آینده با محدودیت هایی روبرو شوند. گزارش ها نشان می دهد که لغو مجوزهای تحریمی می تواند بر دسترسی به سرویس های ابری مانند Google Drive، OneDrive و iCloud تأثیر بگذارد . هرچند این به معنای قطع فوری سرویس ها نیست، اما پرداخت ارزی و دسترسی به این سرویس ها را با ریسک مواجه می کند .
راهکارهای جایگزین برای کاربران ایرانی:
- ابزارهای متن باز به عنوان پایه: Duplicati، Restic و Rsync به دلیل متن باز بودن، از تحریم مصون هستند و نیازی به پرداخت ارزی ندارند . این ابزارها را می توان روی لینوکس یا ویندوز نصب کرد و به هر مقصدی که در دسترس است بکاپ گرفت.
- استفاده از فضای ذخیره سازی داخلی: به جای اتکا به سرویس های ابری خارجی که ممکن است با فیلتر یا تحریم مواجه شوند، می توان از سرویس های آپلود فایل داخلی، سرور اختصاصی یا فضای ابری داخلی به عنوان مقصد offsite استفاده کرد . این کار اگرچه ممکن است کمی گران تر باشد، اما کنترل کامل روی داده ها و دسترسی را تضمین می کند.
- پروتکل های سازگار با محدودیت: ابزارهایی مانند Restic و Duplicati از S3-compatible storage پشتیبانی می کنند که می توان از ارائه دهندگان داخلی سازگار با S3 نیز استفاده کرد . همچنین WebDAV و SFTP گزینه های دیگری هستند که کمتر تحت تأثیر فیلتر قرار می گیرند .
- ترکیب ابزارهای متن باز با اسکریپت: برای خودکارسازی بکاپ در شرایطی که پرداخت ارزی دشوار است، می توان از Rsync با cron و یک اسکریپت ساده برای snapshot استفاده کرد . این ترکیب رایگان، سبک و کاملاً قابل کنترل است.
چه ابزاری برای ایران مناسب است؟ پاسخ کوتاه: ابزارهای متن باز که به پرداخت ارزی و دسترسی به سرویس های تحریم شده وابسته نیستند. Restic و Duplicati به دلیل رمزگذاری داخلی، versioning و پشتیبانی از مقاصد متنوع (از جمله NAS و S3 داخلی) بهترین گزینه ها برای کاربران و کسب وکارهای ایرانی هستند. Rsync نیز برای کسانی که با اسکریپت راحت ترند و فقط به یک همگام سازی ساده نیاز دارند، همچنان یک ابزار پایه قابل اعتماد است. مهم ترین اصل این است که ابزار را بر اساس دسترسی واقعی و مقصدی که در اختیار دارید انتخاب کنید، نه بر اساس برند یا تبلیغات.
سوالات متداول راهنمای گام به گام استراتژی 3-2-1 در پشتیبان گیری
هیچ دیدگاهی ثبت نشده است.