قانون ۳-۲-۱ در پشتیبان‌گیری سازمانی؛ از RPO و RTO تا بکاپ مقاوم در برابر باج‌افزار

تقریباً هر سازمانی می‌گوید «بکاپ داریم». سؤال‌هایی که تفاوت را معلوم می‌کنند این‌هاست: آخرین بار کی از بکاپ بازیابی کردید؟ چند ساعت طول کشید؟ اگر باج‌افزار امشب همه سرورها را رمزگذاری کند، بکاپ هم رمزگذاری می‌شود یا نه؟ اگر ساختمان در دسترس نباشد، نسخه‌ای بیرون از آن وجود دارد؟

در حوادثی که دیده‌ایم، مشکل تقریباً هیچ‌وقت «نبودن نرم‌افزار بکاپ» نبوده. مشکل این بوده که همه نسخه‌ها در یک جا بودند، با یک رمز در دسترس بودند، یا هرگز آزمایش نشده بودند. این مقاله اصول پشتیبان‌گیری سازمانی را با قانون ۳-۲-۱ و نسخه به‌روز آن توضیح می‌دهد و نشان می‌دهد در شرکت کوچک و متوسط چطور پیاده می‌شود.

قانون ۳-۲-۱

• ۳ نسخه از داده: داده اصلی به‌علاوه دو نسخه پشتیبان.
• روی ۲ نوع رسانه یا سیستم متفاوت: مثلاً دیسک سرور و ذخیره‌ساز جداگانه، یا ذخیره‌ساز و نوار. هدف این است که یک نوع خرابی — خرابی کنترلر، ایراد Firmware، باگ نرم‌افزاری — هر دو نسخه را با هم از بین نبرد.
• ۱ نسخه خارج از محل: در ساختمان دیگر، دیتاسنتر یا فضای ابری، تا آتش‌سوزی، آب‌گرفتگی یا سرقت همه نسخه‌ها را با هم نبرد.

منطق قانون ساده است: هر نسخه در برابر گروه متفاوتی از خطرها محافظت می‌کند و احتمال اینکه همه هم‌زمان از دست بروند، بسیار کم می‌شود — به شرطی که نسخه‌ها واقعاً مستقل باشند.

نسخه به‌روز: ۳-۲-۱-۱-۰

قانون ۳-۲-۱ پیش از رایج شدن باج‌افزار شکل گرفت. باج‌افزارهای امروزی معمولاً پیش از رمزگذاری، روزها یا هفته‌ها در شبکه می‌مانند، دسترسی مدیریتی می‌گیرند و عمداً سراغ سرور بکاپ و مخزن‌ها می‌روند تا راه بازیابی را ببندند. به همین دلیل دو رقم به قانون اضافه شده:

• ۱ نسخه آفلاین یا تغییرناپذیر (Immutable): نسخه‌ای که حتی با دسترسی کامل مدیر سیستم، تا پایان دوره نگهداری قابل حذف یا تغییر نیست.
• ۰ خطا در بازیابی: بکاپ‌ها به‌طور منظم بازیابی آزمایشی می‌شوند و نتیجه‌شان تأیید می‌شود.

دو عدد که قبل از هر خریدی باید تعیین شوند: RPO و RTO

RPO (Recovery Point Objective) — حداکثر داده‌ای که از دست دادنش قابل تحمل است، بر حسب زمان. اگر بکاپ هر شب ساعت ۲۲ گرفته شود و سرور ساعت ۱۷ روز بعد از دست برود، کار ۱۹ ساعت از دست رفته است. آیا برای سیستم حسابداری قابل قبول است؟ اگر نه، بکاپ باید مکررتر یا پیوسته باشد.

RTO (Recovery Time Objective) — حداکثر زمان قابل تحمل تا بازگشت سرویس. بازیابی ۲ ترابایت داده از ذخیره‌ساز محلی چند ساعت طول می‌کشد؛ همان حجم از فضای ابری با اینترنت معمولی ممکن است چند روز طول بکشد.

این دو عدد را مدیریت تعیین می‌کند، نه واحد IT — چون هزینه هر ساعت توقف و هر ساعت داده از دست رفته را کسب‌وکار می‌پردازد. روش محاسبه این هزینه را در هزینه واقعی خوابیدن شبکه توضیح داده‌ایم. RPO و RTO برای همه سیستم‌ها یکسان نیست: سیستم مالی ممکن است RPO یک‌ساعته بخواهد و آرشیو فایل‌های قدیمی RPO یک‌هفته‌ای.

انواع بکاپ

• کامل (Full): همه داده. بازیابی ساده، اما زمان و فضای زیاد.
• افزایشی (Incremental): فقط تغییرات نسبت به آخرین بکاپ از هر نوع. سریع و کم‌حجم؛ برای بازیابی، آخرین کامل به‌علاوه همه افزایشی‌های بعدی لازم است.
• تفاضلی (Differential): تغییرات نسبت به آخرین بکاپ کامل. حجمش تا بکاپ کامل بعدی رشد می‌کند؛ برای بازیابی، آخرین کامل به‌علاوه آخرین تفاضلی کافی است.
• کامل ترکیبی (Synthetic Full): نرم‌افزار بکاپ از روی کامل قبلی و افزایشی‌ها، یک کامل جدید در مخزن می‌سازد بدون اینکه دوباره همه داده را از سرور بخواند.

نرم‌افزارهای بکاپ امروزی معمولاً افزایشی دائمی با کامل ترکیبی دوره‌ای را پیشنهاد می‌کنند. در محیط مجازی‌سازی، ردیابی بلوک‌های تغییرکرده توسط هایپروایزر، بکاپ افزایشی را بسیار سریع می‌کند.

سازگاری با برنامه

بکاپ پایگاه داده‌ای که در حال نوشتن است، اگر بدون هماهنگی گرفته شود، ممکن است نسخه‌ای ناسازگار بدهد که بازیابی‌اش پایگاه داده خراب تحویل می‌دهد. در ویندوز، سرویس VSS پیش از گرفتن Snapshot به برنامه‌هایی مثل SQL Server خبر می‌دهد تا داده را در حالت سازگار قرار دهند. تنظیم بکاپ «Application-aware» برای سرورهای پایگاه داده الزامی است.

سیاست نگهداری: GFS

چه تعداد نسخه و تا چه مدت؟ الگوی رایج پدربزرگ-پدر-پسر (GFS) است:

• روزانه: ۱۴ نسخه اخیر
• هفتگی: ۴ تا ۸ نسخه
• ماهانه: ۱۲ نسخه
• سالانه: بر اساس الزامات قانونی و مالیاتی سازمان

چرا نسخه‌های قدیمی مهم‌اند؟ چون خرابی داده یا نفوذ همیشه فوراً کشف نمی‌شود. اگر فایلی سه هفته پیش خراب شده و فقط ۷ نسخه روزانه دارید، همه نسخه‌ها خراب‌اند. و باج‌افزاری که هفته‌ها پیش از رمزگذاری در شبکه بوده، ممکن است در بکاپ‌های اخیر هم حضور داشته باشد.

بکاپ مقاوم در برابر باج‌افزار

اصول محافظت از خود بکاپ:

1. سرور بکاپ عضو دامنه نباشد یا حساب‌های مدیریتی‌اش از دامنه جدا باشد. مهاجمی که مدیر دامنه شده، نباید خودکار مدیر بکاپ هم باشد.
2. مخزن تغییرناپذیر: مخزن مبتنی بر لینوکس سخت‌سازی‌شده با پرچم تغییرناپذیری، یا ذخیره‌ساز شیء با قابلیت Object Lock در حالت انطباق (Compliance)، یا ذخیره‌سازی که Snapshotهای غیرقابل حذف دارد.
3. نسخه آفلاین: نوار یا دیسک قابل جداسازی که بعد از بکاپ از سیستم جدا و در محل امن نگهداری می‌شود. نوار هنوز ارزان‌ترین رسانه برای حجم زیاد است؛ یک کارتریج LTO-9 ظرفیت ۱۸ ترابایت داده بدون فشرده‌سازی دارد.
4. رمزگذاری بکاپ — به‌خصوص نسخه خارج از محل — و نگهداری کلید رمزگذاری جدا از خود بکاپ. کلیدی که فقط روی سرور بکاپ است، با آن سرور از دست می‌رود.
5. احراز هویت چندعاملی برای کنسول بکاپ و فضای ابری.
6. هشدار برای رفتار غیرعادی: حذف انبوه نسخه‌ها، تغییر سیاست نگهداری، افزایش ناگهانی حجم تغییرات — نشانه رایج رمزگذاری در حال انجام.

پیاده‌سازی نمونه برای شرکت کوچک و متوسط

فرض: یک میزبان مجازی‌سازی با پنج ماشین مجازی، حدود ۲ ترابایت داده، و تغییرات روزانه حدود ۳٪ یعنی ۶۰ گیگابایت.

• نسخه ۱ — داده اصلی روی سرور، با RAID برای دسترس‌پذیری (که بکاپ نیست؛ توضیحش در راهنمای RAID).
• نسخه ۲ — بکاپ محلی روی ذخیره‌ساز شبکه جداگانه با Snapshotهای غیرقابل حذف؛ برای بازیابی سریع و RTO کوتاه. بکاپ شبانه افزایشی و کامل ترکیبی هفتگی.
• نسخه ۳ — خارج از محل: کپی بکاپ به دیتاسنتر یا فضای ابری با تغییرناپذیری، یا دیسک قابل جداسازی که هفتگی به محل دیگر منتقل می‌شود.

محاسبه پهنای باند برای نسخه خارج از محل

خط ۱۰۰ مگابیت بر ثانیه، حداکثر ۱۲٫۵ مگابایت در ثانیه منتقل می‌کند؛ یعنی حدود ۴۵ گیگابایت در ساعت. با در نظر گرفتن سربار و اینکه همه پهنای باند در اختیار بکاپ نیست، فرض کنید ۷۰٪ آن، یعنی حدود ۳۰ گیگابایت در ساعت. در پنجره شبانه هشت‌ساعته حدود ۲۵۰ گیگابایت قابل انتقال است — برای ۶۰ گیگابایت تغییرات روزانه (که با فشرده‌سازی و حذف تکرار کمتر هم می‌شود) کافی است.

اما نسخه اولیه ۲ ترابایتی با همین خط نزدیک به ۷۰ ساعت طول می‌کشد. روش رایج: نسخه اولیه روی دیسک به محل مقصد منتقل می‌شود (Seeding) و فقط تغییرات از شبکه ارسال می‌شود. همین محاسبه را برای بازیابی هم انجام دهید: اگر روزی لازم باشد همه ۲ ترابایت از فضای ابری برگردد، RTO شما چند روز است، نه چند ساعت. به همین دلیل نسخه محلی سریع حذف‌شدنی نیست.

برآورد فضای مخزن

با سیاست ۱۴ روزانه، ۴ هفتگی و ۱۲ ماهانه، و فشرده‌سازی و حذف تکرار که بسته به نوع داده معمولاً حجم را به‌طور محسوس کم می‌کند، مخزن محلی معمولاً به دو تا سه برابر حجم داده اصلی نیاز دارد. برآورد دقیق به نرخ واقعی تغییرات و نوع داده بستگی دارد — فایل‌های فشرده، ویدیو و تصاویر تقریباً هیچ فشرده‌سازی بیشتری نمی‌پذیرند.

آزمون بازیابی: رقم «۰» در ۳-۲-۱-۱-۰

بکاپی که آزمایش نشده، فرضیه است. آزمون بازیابی باید در سه سطح انجام شود:

1. خودکار: بسیاری از نرم‌افزارهای بکاپ می‌توانند ماشین مجازی را در یک شبکه ایزوله از روی بکاپ اجرا کنند، بالا آمدن سیستم‌عامل و سرویس‌ها را بررسی کنند و گزارش بدهند.
2. دوره‌ای دستی: هر فصل، بازیابی کامل حداقل یک ماشین مجازی و یک پایگاه داده، باز کردن نرم‌افزار و بررسی داده توسط کاربر کلیدی. زمان را اندازه بگیرید و با RTO مقایسه کنید.
3. سالانه: سناریوی فاجعه کامل — سرور اصلی و ذخیره‌ساز محلی هر دو در دسترس نیستند. بازیابی از نسخه خارج از محل.

این آزمون‌ها بخشی از سرویس دوره‌ای سرور است و نتیجه‌شان باید مکتوب شود.

اشتباه‌های رایج در پشتیبان‌گیری سازمانی

1. بکاپ روی دیسک دیگری از همان سرور. با خرابی کنترلر، سرقت یا باج‌افزار، هر دو با هم می‌روند.
2. ذخیره‌ساز بکاپ همیشه متصل با اشتراک شبکه باز. اولین هدف باج‌افزار.
3. هشدار شکست بکاپ که به ایمیلی می‌رود که کسی نمی‌خواند.
4. بکاپ فقط از فایل‌ها، نه از سیستم و پیکربندی. بازیابی فایل‌ها بدون سرور و نرم‌افزار، روزها کار اضافه دارد.
5. فراموش کردن داده بیرون از سرور: ایمیل ابری، پیکربندی تجهیزات شبکه، لپ‌تاپ مدیران.
6. رمز رمزگذاری بکاپ که فقط یک نفر می‌داند.

پرسش‌های متداول

Snapshot ماشین مجازی بکاپ است؟

نه. Snapshot به دیسک اصلی وابسته است و با خرابی ذخیره‌ساز از بین می‌رود. Snapshot برای بازگشت سریع پیش از یک تغییر مفید است، نه جایگزین بکاپ.

همگام‌سازی ابری (مثل پوشه همگام) بکاپ است؟

نه. همگام‌سازی، حذف و رمزگذاری را هم همگام می‌کند. فقط اگر سرویس، نسخه‌های قبلی را با دوره نگهداری مستقل نگه دارد، بخشی از نقش بکاپ را بازی می‌کند.

برای شرکت کوچک، ابر کافی است یا ذخیره‌ساز محلی هم لازم است؟

بستگی به RTO دارد. بازیابی کامل از ابر با اینترنت معمولی کند است. ترکیب بکاپ محلی برای بازیابی سریع و نسخه ابری یا خارج از محل برای فاجعه، رایج‌ترین و متعادل‌ترین طراحی است.

قدم بعدی

اگر نمی‌دانید RPO و RTO واقعی سیستم‌هایتان چقدر است یا آخرین آزمون بازیابی کی بوده، از همین‌جا شروع کنید. در بازدید فنی، وضعیت فعلی بکاپ را با قانون ۳-۲-۱-۱-۰ مقایسه می‌کنیم، یک بازیابی آزمایشی انجام می‌دهیم و طرح اصلاح با اولویت تحویل می‌دهیم.

مشاهده خدمات سرویس دوره‌ای و پشتیبان‌گیری سرور · تلفن: 021-74903