قانون بکاپ 3-2-1 چیست؟ طراحی بکاپ امن برای سرور و اطلاعات شرکت

داشتن RAID، هارد Enterprise یا حتی یک NAS گران‌قیمت به معنی داشتن بکاپ امن نیست. حذف اشتباه فایل، خرابی کنترلر، باج‌افزار، آتش‌سوزی یا سرقت می‌تواند چند نسخه‌ای را که همگی در یک سیستم یا یک ساختمان هستند همزمان از بین ببرد. یکی از ساده‌ترین چارچوب‌ها برای کاهش این ریسک، قانون بکاپ 3-2-1 است؛ روشی که به‌جای وابستگی به یک ابزار، روی تنوع و جداسازی نسخه‌ها تمرکز می‌کند.

قانون 3-2-1 دقیقاً یعنی چه؟

اصل کلاسیک می‌گوید از داده مهم سه نسخه داشته باشید؛ این نسخه‌ها روی دو نوع رسانه یا سامانه متفاوت قرار بگیرند و حداقل یک نسخه خارج از محل اصلی نگهداری شود. منظور از سه نسخه معمولاً داده اصلی به‌علاوه دو Backup است. هدف این است که یک خرابی یا حادثه واحد نتواند همه کپی‌ها را نابود کند.

نمونه عملی برای یک شرکت کوچک

فرض کنید فایل‌های حسابداری و اشتراکی روی سرور اصلی قرار دارند. نسخه دوم می‌تواند شبانه روی NAS داخلی نوشته شود. نسخه سوم می‌تواند به Storage شعبه دیگر، فضای ابری سازمانی یا رسانه‌ای که به‌صورت کنترل‌شده خارج از محل نگهداری می‌شود منتقل شود. اگر نسخه خارج از محل همیشه با دسترسی Write مستقیم به همان Domain در دسترس باشد، در برابر باج‌افزار هنوز ریسک دارید؛ بنابراین جداسازی Credential و Immutable/Offline بودن نسخه مهم است.

چرا RAID بکاپ نیست؟

RAID می‌تواند در برابر خرابی یک یا چند دیسک ـ بسته به Level ـ سرویس را در دسترس نگه دارد، اما اگر فایل توسط کاربر پاک شود یا مهاجم آن را رمزگذاری کند، تغییر روی آرایه اعمال می‌شود. RAID برای Availability است، نه نگهداری تاریخچه مستقل داده. اگر درباره انتخاب RAID برای سرور HPE تصمیم می‌گیرید، راهنمای انتخاب RAID و Smart Array را هم ببینید.

نسخه دوم را کجا نگه داریم؟

NAS داخلی مقصد رایجی برای Backup است، چون ظرفیت بالا و مدیریت مرکزی ارائه می‌دهد. برای آرشیو حجیم می‌توان از دیسک‌های Enterprise استفاده کرد؛ مثلاً Seagate Exos X18 18TB برای کاربردهای سازمانی و ذخیره‌سازی ظرفیت بالا طراحی شده است. با این حال مدل دیسک باید با NAS/Storage و Firmware آن سازگار باشد.

نسخه Offsite چه مشکلی را حل می‌کند؟

اگر سرور و NAS کنار هم باشند، حادثه فیزیکی می‌تواند هر دو را از بین ببرد. Offsite این Failure Domain را جدا می‌کند. مقصد می‌تواند دیتاسنتر، شعبه دوم یا Cloud باشد. برای دیتای حساس، Encryption در زمان انتقال و نگهداری، کنترل دسترسی و سیاست Retention باید از ابتدا تعریف شوند.

برای مقابله با باج‌افزار چه چیزی اضافه کنیم؟

Immutable یا Offline Backup

حداقل یک نسخه باید طوری نگهداری شود که Credential روزمره سرورها نتواند آن را حذف یا بازنویسی کند. Object Lock، Immutable Repository یا رسانه Offline نمونه‌های متداول هستند.

حساب کاربری جدا

Backup Server و Repository نباید بی‌دلیل با همان Administrator عمومی Domain مدیریت شوند. Least Privilege و MFA در جایی که پشتیبانی می‌شود، سطح حمله را کاهش می‌دهد.

Patch و Segmentation

NAS و Backup Appliance هم سیستم کامپیوتری هستند و باید Firmware آن‌ها به‌روز، سرویس‌های غیرضروری بسته و دسترسی مدیریتی محدود باشد. انتشار مستقیم پنل مدیریت Storage روی اینترنت انتخاب مناسبی نیست.

RPO و RTO را قبل از خرید مشخص کنید

RPO مشخص می‌کند حداکثر چه مقدار داده می‌توانید از دست بدهید؛ مثلاً 15 دقیقه یا یک روز. RTO می‌گوید سرویس باید حداکثر در چه زمانی برگردد. شرکتی با RPO یک‌روزه به طراحی متفاوتی نسبت به دیتابیس با RPO چنددقیقه‌ای نیاز دارد. این دو عدد روی ظرفیت، پهنای باند، تعداد Jobها و هزینه اثر می‌گذارند.

تست Restore مهم‌تر از پیام Success است

Backup موفقی که Restore نشود ارزش عملی ندارد. به‌صورت دوره‌ای فایل، دیتابیس و در صورت امکان یک VM کامل را در محیط ایزوله بازیابی کنید. زمان Restore را اندازه بگیرید و نتیجه را مستند کنید. این کار خرابی Media، Credential فراموش‌شده و Backup ناقص را قبل از بحران آشکار می‌کند.

ظرفیت موردنیاز را چگونه تخمین بزنیم؟

فقط حجم فعلی داده را ضربدر تعداد نسخه‌ها نکنید. نرخ رشد، Retention، Full/Incremental بودن، Compression، تعداد Restore Point و فضای لازم برای Rebuild را هم در نظر بگیرید. برای انتخاب معماری ذخیره‌سازی می‌توانید راهنمای تفاوت NAS و SAN را مطالعه کنید.

جمع‌بندی

3-2-1 یک محصول نیست؛ یک الگوی کاهش ریسک است. سه نسخه، دو بستر متفاوت و یک نسخه Offsite نقطه شروع خوبی هستند و برای تهدیدهای امروز بهتر است Immutable/Offline Backup، MFA، Segmentation و تست Restore هم به آن اضافه شوند. برای بررسی هاردهای سازمانی و ظرفیت‌های مختلف، دسته هارد خرسند سیستم در دسترس است.

سوالات متداول

آیا Snapshot همان Backup است؟

Snapshot برای بازگشت سریع مفید است، اما اگر روی همان Storage باشد Failure Domain مستقلی ایجاد نمی‌کند و به‌تنهایی جای Backup را نمی‌گیرد.

هر چند وقت یک‌بار Restore تست کنیم؟

بسته به اهمیت سرویس، برنامه دوره‌ای تعریف کنید؛ سرویس‌های حیاتی باید بسیار منظم‌تر از آرشیو کم‌اهمیت تست شوند.

آیا Cloud به‌تنهایی کافی است؟

Cloud می‌تواند نسخه Offsite خوبی باشد، اما Retention، دسترسی، Encryption و امکان بازیابی باید آزمایش شود و بهتر است تنها نسخه شما نباشد.