قانون پشتیبان گیری ۳-۲-۱ یک اصل ساده برای کاهش خطر ازدست‌رفتن اطلاعات است: سه نسخه از داده داشته باشید، آن‌ها را روی دو نوع رسانه نگه دارید و حداقل یک نسخه را خارج از محل اصلی ذخیره کنید. منظور از سه نسخه، داده عملیاتی به‌اضافه دو نسخه پشتیبان است؛ نه سه بکاپ علاوه بر اطلاعات اصلی.
اما شمارش نسخه‌ها به‌تنهایی کافی نیست. اگر همه کپی‌ها با یک حساب مدیریتی حذف شوند، بازیابی آن‌ها آزمایش نشده باشد یا آخرین نسخه سالم بیش از حد قدیمی باشد، کسب‌وکار همچنان آسیب‌پذیر است. این راهنما نشان می‌دهد چگونه قانون ۳-۲-۱ را به برنامه‌ای عملی برای بکاپ، حفاظت و بازیابی اطلاعات تبدیل کنید.
پایش نسخه‌های پشتیبان و آزمون بازیابی، مکمل نگهداری نسخه‌های مستقل است.
قانون پشتیبان گیری ۳-۲-۱ چه معنایی دارد؟
این الگو برای جلوگیری از وابستگی کامل به یک محل یا یک ابزار ذخیره‌سازی به کار می‌رود. راهنمای CISA نیز سه نسخه، دو نوع رسانه و یک نسخه خارج از محل را مبنای این قاعده معرفی می‌کند.
| عدد | معنا | نمونه اجرایی |
|---|---|---|
| ۳ | داده اصلی و دو بکاپ قابل بازیابی | فایل عملیاتی، بکاپ محلی و بکاپ خارج از محل |
| ۲ | دو نوع رسانه ذخیره‌سازی | دیسک و نوار؛ یا دیسک محلی و ذخیره‌سازی ابری مستقل با طراحی مناسب |
| ۱ | حداقل یک نسخه خارج از محل اصلی | سایت دوم یا سرویس ابری در محل فیزیکی جداگانه |
سه نسخه؛ با امکان بازگشت به زمان مناسب
نسخه پشتیبان باید به شما اجازه دهد داده را به وضعیت سالم قبلی برگردانید. کپی امروز ممکن است حذف اشتباه دیروز را هم در خود داشته باشد؛ بنابراین تعداد نسخه‌ها را از تعداد نقاط بازیابی جدا کنید. یک مخزن بکاپ می‌تواند چندین نسخه روزانه و هفتگی نگه دارد، اما همه آن‌ها همچنان به سلامت همان مخزن وابسته‌اند.
دو رسانه؛ همراه با جداسازی وابستگی‌ها
دو پوشه یا دو پارتیشن روی یک دیسک، دو رسانه مستقل نیستند. حتی دو دستگاه ذخیره‌سازی ممکن است برق، شبکه، کنترلر یا حساب مدیریتی مشترک داشته باشند. در اجرای قانون پشتیبان گیری ۳-۲-۱ باید علاوه بر نوع رسانه، بررسی کنید کدام خرابی یا دسترسی غیرمجاز می‌تواند چند نسخه را هم‌زمان از بین ببرد.
یک نسخه خارج از محل؛ نه صرفاً خارج از سرور
NAS کنار سرور برای بازیابی سریع مفید است، اما در برابر آتش‌سوزی یا سرقت کل محل کافی نیست. نسخه خارج از محل باید از رخدادهای مؤثر بر سایت اصلی فاصله داشته باشد. یک رک دیگر در همان ساختمان معمولاً این هدف را به‌طور کامل تأمین نمی‌کند. انتخاب فاصله و محل دوم باید بر اساس ریسک و نیاز بازیابی انجام شود.
چرا یک بکاپ برای کسب‌وکار کافی نیست؟
اطلاعات ممکن است بر اثر خرابی سخت‌افزار، حذف انسانی، خطای نرم‌افزار، باج‌افزار یا اختلال محل نگهداری از دست بروند. هر روش حفاظت فقط بخشی از این خطرها را پوشش می‌دهد. برای نمونه، دیسک اضافی در همان سرور ممکن است از خرابی دیسک اصلی مستقل باشد، اما از سرقت سرور یا دسترسی مدیر آلوده مستقل نیست.
ارزش قانون پشتیبان گیری ۳-۲-۱ در تقسیم این ریسک‌هاست. این قانون تضمین امنیت مطلق یا جایگزین برنامه تداوم کسب‌وکار نیست؛ نقطه شروعی برای ساخت چند مسیر بازیابی است. نتیجه واقعی زمانی مشخص می‌شود که تیم بتواند سرویس ضروری را در زمان موردنیاز بازگرداند.
تفاوت بکاپ با RAID، Snapshot و همگام‌سازی
پیش از خرید فضای پشتیبان، نقش ابزارهای موجود را روشن کنید. داشتن چند قابلیت ذخیره‌سازی الزاماً به معنی اجرای قانون پشتیبان گیری ۳-۲-۱ نیست.
- RAID: بسته به سطح انتخابی، تحمل بعضی خرابی‌های دیسک را افزایش می‌دهد؛ حذف فایل یا رمزگذاری آن توسط باج‌افزار را به نسخه سالم قبلی تبدیل نمی‌کند.
- Replication: داده را به مقصد دیگر منتقل می‌کند و می‌تواند برای دسترس‌پذیری مفید باشد، اما ممکن است حذف و خرابی منطقی را نیز منتقل کند.
- همگام‌سازی فایل: معمولاً وضعیت پوشه‌ها را هماهنگ می‌کند. بدون تاریخچه مناسب و محافظت از حذف، جایگزین بکاپ مستقل نیست.
- Snapshot: برای بازگشت سریع کاربرد دارد؛ بااین‌حال، اگر به همان ذخیره‌ساز و حساب وابسته باشد، به‌تنهایی نسخه مستقل خارج از محل محسوب نمی‌شود.
- Backup: با سیاست نگهداری و نقاط بازیابی مشخص، امکان بازگرداندن وضعیت قبلی را فراهم می‌کند؛ صحت این امکان باید آزمایش شود.
تعیین RPO و RTO در قانون پشتیبان گیری ۳-۲-۱
قانون پشتیبان گیری ۳-۲-۱ درباره چیدمان نسخه‌هاست، نه اینکه هر چند ساعت بکاپ بگیرید. برای تعیین برنامه زمانی، ابتدا دو هدف را با مالک کسب‌وکار توافق کنید.
RPO حداکثر بازه قابل‌قبول ازدست‌رفتن داده است. اگر RPO سامانه سفارش یک ساعت باشد، بکاپ روزانه به‌تنهایی کافی نیست. RTO زمان هدف برای بازگرداندن سرویس پس از اختلال است و علاوه بر انتقال داده، آماده‌سازی زیرساخت، بازیابی وابستگی‌ها و آزمون عملکرد را هم در بر می‌گیرد.
بکاپ ساعتی نیز خودبه‌خود RPO یک‌ساعته را تضمین نمی‌کند؛ شکست عملیات یا تأخیر انتقال به محل دوم می‌تواند نقطه بازیابی قابل استفاده را عقب ببرد. برای هر سناریوی خرابی، سن آخرین نسخه سالم و زمان بازیابی واقعی را اندازه بگیرید.
اجرای قانون پشتیبان گیری ۳-۲-۱ در ۷ مرحله
۱. فهرست داده‌ها و وابستگی‌ها را تهیه کنید
دیتابیس، فایل‌های کاربران، تنظیمات برنامه، ماشین‌های مجازی، تنظیمات شبکه و مستندات راه‌اندازی را شناسایی کنید. مشخص کنید چه کسی مالک هر مجموعه است و نبود آن چه اثری دارد. کلیدهای رمزگشایی و اطلاعات لازم برای بازیابی هم باید با کنترل دسترسی مناسب قابل دسترس باشند؛ ذخیره بکاپ رمزگذاری‌شده بدون امکان بازیابی کلید، کافی نیست.
۲. روش سازگار با برنامه را انتخاب کنید
کپی ساده فایل‌های یک دیتابیس فعال ممکن است نسخه سازگار ایجاد نکند. از روش پشتیبان‌گیری مورد تأیید موتور دیتابیس یا ابزار هماهنگ با برنامه استفاده کنید. برای بازیابی نقطه‌ای، زنجیره بکاپ پایه و لاگ‌های لازم باید کامل باشد. دستور و ترتیب بازیابی را متناسب با نسخه واقعی نرم‌افزار ثبت کنید.
۳. مقصد محلی و خارج از محل را جدا طراحی کنید
نسخه محلی معمولاً مسیر سریع‌تری برای بازگرداندن فایل یا سرویس فراهم می‌کند. مقصد دوم باید در برابر ازدست‌رفتن محل اول مفید باشد. اگر ابر را انتخاب می‌کنید، محل داده، امکان خروج اطلاعات، دسترسی هنگام بحران و هزینه دریافت را بررسی کنید. نام متفاوت دو سرویس، به‌تنهایی نشانه استقلال آن‌ها نیست.
۴. دسترسی بکاپ را محدود کنید
برای مدیریت بکاپ حساب اختصاصی، حداقل سطح دسترسی و احراز هویت چندعاملی در نظر بگیرید. در صورت امکان، حساب عملیاتی برنامه نباید اختیار حذف نسخه‌های پشتیبان را داشته باشد. رخدادهای حذف، تغییر سیاست نگهداری و ورود مدیریتی باید ثبت و بررسی شوند.
۵. برنامه زمان‌بندی و نگهداری بنویسید
تناوب بکاپ را بر اساس RPO و مدت نگهداری را بر اساس زمان کشف خطا، نیاز عملیاتی و الزامات سازمان تعیین کنید. ترکیبی از نسخه‌های کوتاه‌مدت و بلندمدت ممکن است لازم باشد. نگهداری طولانی‌تر، هزینه و حساسیت حفاظت از اطلاعات را نیز افزایش می‌دهد؛ همه داده‌ها الزاماً به سیاست یکسان نیاز ندارند.
۶. هشدارها را به مسئول مشخص وصل کنید
شکست Job، پرشدن مخزن، افزایش غیرعادی حجم، تأخیر نسخه خارج از محل و قدیمی‌شدن آخرین نقطه بازیابی باید هشدار داشته باشند. برای هر هشدار، مسئول و زمان پیگیری مشخص کنید. گزارش موفقیت ابزار را با وضعیت مقصد و کامل‌بودن زنجیره بازیابی تطبیق دهید.
۷. بازیابی را در محیط جداگانه تمرین کنید
یک فایل، یک دیتابیس و سپس یک سرویس کامل را به‌صورت دوره‌ای برگردانید. زمان شروع تا آماده‌به‌کارشدن، وابستگی‌های گمشده و خطاهای دسترسی را ثبت کنید. نتیجه آزمون باید به اصلاح برنامه منجر شود؛ صرف داشتن صورت‌جلسه تست، هدف نهایی نیست.
مثال عملی قانون پشتیبان گیری ۳-۲-۱ برای یک شرکت
فرض کنید شرکتی یک ترابایت فایل اداری و یک دیتابیس فروش دارد. اعداد این مثال آموزشی‌اند و توصیه ثابت برای همه سازمان‌ها نیستند. شرکت برای فایل‌ها RPO یک روز و برای دیتابیس RPO یک ساعت تعیین کرده و بازگشت سرویس فروش را در چهار ساعت هدف‌گذاری کرده است.
- نسخه اصلی روی سرور عملیاتی قرار دارد.
- بکاپ فایل‌ها هر شب و بکاپ سازگار دیتابیس طبق برنامه متناسب با RPO، روی مخزن محلی جدا ذخیره می‌شود.
- نسخه دوم بکاپ به مخزن خارج از محل با حساب مدیریتی جدا منتقل می‌شود؛ تأخیر انتقال در محاسبه RPO سایت دوم لحاظ می‌شود.
- حداقل یکی از نسخه‌ها با نگهداری تغییرناپذیر یا جداسازی آفلاین محافظت می‌شود.
- فایل‌ها و دیتابیس به‌صورت نمونه‌ای بازیابی می‌شوند و بازیابی کامل سرویس نیز در برنامه آزمون قرار می‌گیرد.
در این طرح، اجرای قانون پشتیبان گیری ۳-۲-۱ زمانی قابل اتکاست که شرکت واقعاً بتواند بدون دسترسی به سرور اصلی، حساب اصلی و محل اصلی بازیابی کند. اگر تمام رمزها و مستندات فقط روی همان سرور باشند، یک وابستگی پنهان باقی مانده است.
اگر نسخه دوم را در سایت دیگری نگه می‌دارید، کیفیت برق، شبکه و تعهدات عملیاتی محل نیز اهمیت دارد. برای ارزیابی این بخش، راهنمای خدمات کولوکیشن، SLA و Uptime دیتاسنتر را بخوانید؛ میزبانی در دیتاسنتر به‌تنهایی به معنی ارائه بکاپ نیست.
مدل ۳-۲-۱-۱-۰ چه چیزی اضافه می‌کند؟
در مدل توسعه‌یافته‌ای که Veeam توضیح می‌دهد، یک «۱» برای نسخه آفلاین، جدا از شبکه یا تغییرناپذیر و یک «۰» برای نبود خطا در بررسی بازیابی اضافه می‌شود. این مدل بر حفاظت از خود بکاپ و آزمون بازگردانی تأکید دارد؛ صفر خطا به معنی تضمین همیشگی نبود خرابی نیست.
آفلاین یعنی نسخه در زمان موردنظر از دسترس شبکه خارج است. تغییرناپذیر یا Immutable یعنی تغییر یا حذف نسخه در دوره نگهداری طبق قابلیت و تنظیمات سامانه محدود می‌شود. این دو مفهوم یکسان نیستند و هرکدام به پیکربندی و کنترل عملیاتی صحیح نیاز دارند.
CISA نیز بر نسخه‌های آفلاین و رمزگذاری‌شده و آزمایش منظم بازیابی تأکید می‌کند. بنابراین برای مقابله با باج‌افزار، قانون پشتیبان گیری ۳-۲-۱ را با جداسازی دسترسی و حفاظت از نسخه‌ها تکمیل کنید. بکاپ جایگزین پیشگیری، پایش و پاسخ به رخداد نیست.
ظرفیت، پهنای باند و هزینه بکاپ را چگونه برآورد کنیم؟
حجم داده اصلی فقط نقطه شروع است. نرخ تغییر روزانه، تعداد نقاط بازیابی، روش Full یا Incremental، نسخه‌های بلندمدت و فضای موقت عملیات بر ظرفیت اثر دارند. کاهش حجم با فشرده‌سازی یا Deduplication را بدون اندازه‌گیری داده واقعی قطعی فرض نکنید.
مثال ساده ظرفیت: یک بکاپ کامل یک‌ترابایتی به‌اضافه ۱۴ مجموعه تغییرات روزانه ۲۰ گیگابایتی، بدون کاهش حجم و سربار، حدود ۱٫۲۸ ترابایت در یک مخزن نیاز دارد. نسخه‌های کامل اضافی، فضای کار و حاشیه رشد باید جدا محاسبه شوند؛ مقصد دوم نیز ظرفیت مستقل می‌خواهد.
مثال زمان انتقال: دریافت یک ترابایت ده‌دهی با نرخ مؤثر ثابت ۱۰۰ مگابیت‌برثانیه، حدود ۲۲٫۲ ساعت طول می‌کشد. این فقط انتقال داده است؛ آماده‌سازی، رمزگشایی، بازیابی و آزمون سرویس زمان بیشتری می‌گیرند. بنابراین چنین مسیری به‌تنهایی با RTO چهار ساعت سازگار نیست.
در مقایسه هزینه‌ها، فضای ذخیره‌سازی، ترافیک خروجی، درخواست‌ها، بازیابی از آرشیو سرد، مجوز نرم‌افزار، نیروی انسانی و آزمون دوره‌ای را کنار هم ببینید. پایین‌ترین قیمت هر ترابایت لزوماً کم‌هزینه‌ترین راه برای بازیابی کسب‌وکار نیست.
اشتباهات رایج در اجرای قانون پشتیبان گیری ۳-۲-۱
- شمردن پوشه‌ها یا Snapshotهای یک مخزن به‌عنوان مقصدهای مستقل؛
- استفاده از یک حساب با اختیار حذف تمام نسخه‌ها؛
- اشتباه‌گرفتن نسخه خارج از محل با نسخه آفلاین؛
- اتکا به همگام‌سازی بدون تاریخچه و سیاست نگهداری؛
- نادیده‌گرفتن دیتابیس، تنظیمات یا کلیدهای لازم برای بازیابی؛
- تعیین RTO بدون اندازه‌گیری سرعت بازگردانی؛
- اعتماد به پیام موفقیت بکاپ بدون اجرای Restore؛
- نبود مسئول مشخص برای هشدارها و تصمیم بازیابی.
چک‌لیست ارزیابی قانون پشتیبان گیری ۳-۲-۱
برای ارزیابی قانون پشتیبان گیری ۳-۲-۱ در سازمان، پاسخ این پرسش‌ها را همراه با شواهد ثبت کنید:
- داده اصلی و دو بکاپ دقیقاً کجا قرار دارند؟
- کدام خرابی فیزیکی یا حساب مدیریتی میان آن‌ها مشترک است؟
- آخرین نسخه سالم خارج از محل چقدر قدیمی است؟
- آیا یک نسخه در برابر حذف یا تغییر مخرب محافظت می‌شود؟
- آیا بدون زیرساخت اصلی به کلیدها و مستندات دسترسی داریم؟
- آخرین بازیابی کامل چه زمانی انجام شد و چقدر طول کشید؟
- آیا مالک کسب‌وکار صحت داده و کارکرد سرویس بازیابی‌شده را تأیید کرده است؟
سؤالات متداول
آیا قانون پشتیبان گیری ۳-۲-۱ برای کسب‌وکار کوچک هم لازم است؟
برای اطلاعات حیاتی کسب‌وکار کوچک نیز کاربرد دارد. ابزارها می‌توانند ساده‌تر باشند، اما داشتن نسخه مستقل، نگهداری خارج از محل و آزمون بازیابی همچنان اهمیت دارد. پیچیدگی راهکار باید با ارزش داده و توان بهره‌برداری تیم متناسب باشد.
آیا بکاپ ابری به‌تنهایی کافی است؟
خیر؛ باید بررسی کنید داده اصلی کجاست، چند نسخه قابل بازیابی دارید و چه حسابی می‌تواند آن‌ها را حذف کند. ذخیره در ابر فقط بخشی از طراحی است. دسترسی، مدت نگهداری، محل فیزیکی و امکان خروج داده نیز باید روشن باشند.
هر چند وقت یک‌بار بکاپ بگیریم؟
بر اساس RPO هر سرویس تصمیم بگیرید. فایل کم‌تغییر با دیتابیس تراکنشی برنامه یکسانی ندارد. مدت اجرای عملیات، شکست‌های احتمالی و تأخیر انتقال را هم در برنامه لحاظ کنید.
آیا داشتن RAID نیاز به بکاپ را حذف می‌کند؟
خیر. RAID برای تحمل برخی خرابی‌های سخت‌افزاری است؛ حذف اشتباه، حمله یا خرابی منطقی داده همچنان به نسخه قابل بازگشت نیاز دارد.
آیا قانون ۳-۲-۱ جلوی حمله باج‌افزار را می‌گیرد؟
این قانون مانع وقوع حمله نیست. نسخه سالم و محافظت‌شده می‌تواند امکان بازیابی را بهتر کند، اما برای بازگرداندن سرویس باید علت نفوذ نیز بررسی و محیط بازیابی ایمن شود.
جمع‌بندی؛ معیار موفقیت، بازیابی اطلاعات است
قانون پشتیبان گیری ۳-۲-۱ چارچوبی روشن برای توزیع نسخه‌های اطلاعات فراهم می‌کند: داده اصلی و دو بکاپ، دو نوع رسانه و یک نسخه خارج از محل. برای تبدیل آن به حفاظت عملی، RPO و RTO، جداسازی دسترسی، نگهداری نسخه‌ها و مسئولیت تیم را نیز مشخص کنید.
از یک سرویس حیاتی شروع کنید، مسیرهای خرابی مشترک را پیدا کنید و یک بازیابی واقعی انجام دهید. برنامه‌ای که بازگردانی آن اندازه‌گیری و اصلاح شده باشد، از مجموعه‌ای از بکاپ‌های آزمایش‌نشده ارزشمندتر است.