قانون بکاپ 3-2-1 برای شرکتها؛ ساده، عملی و قابل اجرا
قانون بکاپ 3-2-1 را با نمونه شرکتی، تعیین RPO و RTO، نسخه خارج از محل و تست بازیابی اجرا کنید؛ همراه با هشدارهای مهم و چکلیست کنترل بکاپ.
خلاصه تخصصی مقاله
قانون بکاپ 3-2-1 را با نمونه شرکتی، تعیین RPO و RTO، نسخه خارج از محل و تست بازیابی اجرا کنید؛ همراه با هشدارهای مهم و چکلیست کنترل بکاپ.
موضوعات اصلی: پشتیبانی شبکه، بکاپ، نسخه، بازیابی، کنید، قانون
وقتی حسابداری باز نمیشود یا پوشه قراردادها حذف شده، تعداد فایلهای بکاپ بهتنهایی کمکی نمیکند. باید بدانید کدام نسخه سالم است، کجا نگهداری میشود و چه مدت طول میکشد تا کار شرکت ادامه پیدا کند. قانون بکاپ 3-2-1 نقطه شروع طراحی این مسیر است.
هشدار پیش از اجرابکاپهای فعلی را برای خالی کردن فضا حذف نکنید و بازیابی آزمایشی را روی اطلاعات اصلی انجام ندهید. تغییر RAID، مدل بازیابی دیتابیس، دسترسی مخزن یا قفل نگهداری ممکن است روی داده و سرویس اثر بگذارد. قبل از تغییر با متخصص مشورت کنید.
قانون بکاپ 3-2-1 چیست؟
پاسخ کوتاهقانون بکاپ 3-2-1 یعنی حداقل 3 نسخه از داده داشته باشید: 1 نسخه اصلی و 2 نسخه پشتیبان؛ نسخهها روی 2 نوع رسانه یا فناوری ذخیرهسازی قرار بگیرند و حداقل 1 نسخه خارج از محل اصلی نگهداری شود. بازیابی این نسخهها نیز باید آزمایش شود.
| عدد | معنای عملی | اشتباه رایج |
|---|---|---|
| 3 | داده اصلی بهاضافه 2 نسخه پشتیبان | شمردن 3 پوشه روی همان دیسک بهعنوان نسخههای مستقل |
| 2 | تنوع رسانه، مانند دیسک و نوار؛ یا در طراحیهای امروزی، ذخیرهسازی محلی و مخزن ابری مستقل | فرض اینکه 2 پارتیشن، 2 رسانه متفاوت هستند |
| 1 | حداقل 1 نسخه در مکانی جدا از سایت اصلی | نگهداری همه نسخهها در همان رک یا ساختمان |
در راهنمای مشترک منتشرشده در CISA نیز همین ساختار برای پشتیبانگیری توضیح داده شده است. هدف، کاهش احتمال از دست رفتن همزمان داده اصلی و نسخههای پشتیبان است؛ تعداد نسخهها بهتنهایی امنیت یا بازیابی موفق را تضمین نمیکند.
قبل از خرید تجهیزات، این اولویتها را مشخص کنید
برای اجرای قانون بکاپ 3-2-1، ابتدا وضعیت فعلی را روشن کنید. اگر هیچکس نمیداند آخرین نسخه قابل بازیابی کجاست، خرید یک ذخیرهساز جدید مشکل اصلی را حل نمیکند.
- سرویس حیاتی را پیدا کنیدحسابداری، سفارشگیری، فایلسرور یا تلفن شرکت؛ مشخص کنید توقف کدامیک زودتر کار مجموعه را مختل میکند.
- آخرین نقطه بازیابی را بررسی کنیدزمان داده موجود در بکاپ را ببینید و یک نمونه را در محیط جدا بازیابی کنید.
- خطر مشترک را کاهش دهیداگر همه نسخهها روی همان سرور یا در همان ساختمان هستند، ایجاد نسخه مستقل خارج از محل در اولویت است.
- مسئول و هشدار تعیین کنیدشکست بکاپ، انجام نشدن کار زمانبندیشده و قدیمی شدن نسخه خارج از محل باید به فرد مشخصی گزارش شود.
اگر نشانهای از باجافزار یا نفوذ وجود دارد، مخزن سالم و رسانه آفلاین را به سیستم مشکوک متصل نکنید. انتخاب نسخه سالم و بازگرداندن سرویس باید با مسئول رسیدگی به رخداد هماهنگ شود.
چرا RAID، Snapshot و همگامسازی جای بکاپ را نمیگیرند؟
در قانون بکاپ 3-2-1، هر نسخه باید برای بازیابی ارزش مستقل داشته باشد. این تفاوت را هنگام بررسی زیرساخت در نظر بگیرید
- RAIDبعضی سطوح RAID تحمل خرابی دیسک ایجاد میکنند، اما حذف فایل یا رمزگذاری مخرب میتواند روی کل آرایه اثر بگذارد. RAID 0 حتی تحمل خرابی دیسک هم ندارد. جزئیات را درمقایسه انواع RAID سروربخوانید.
- Snapshot ماشین مجازیXNETشات معمول VMware به دیسک پایه وابسته است و کپی مستقل محسوب نمیشود. مستندات Broadcom نیز استفاده از آن بهجای بکاپ را توصیه نمیکند. بکاپ مستقل میتواند در فرایند تهیه خود از Snapshot استفاده کند.
- همگامسازی فایلممکن است حذف یا خرابی فایل به مقصد هم منتقل شود. برای اتکا به مقصد، نگهداری نسخههای تاریخی، دسترسی مستقل و امکان بازیابی را بررسی کنید.
اجرای قانون بکاپ 3-2-1 در شرکت، قدم به قدم
1. میزان قابل قبول از دست رفتن داده و توقف را بنویسید
قبل از انتخاب نرمافزار، 2 سوال از مسئول هر واحد بپرسید: «از دست رفتن اطلاعات چند ساعت اخیر قابل تحمل است؟» و «چند ساعت میتوانیم بدون این سرویس کار کنیم؟»
- RPOحداکثر بازه زمانی دادهای که از دست رفتنش قابل قبول است. RPO برابر 15 دقیقه یعنی طرح باید امکان برگشت به نقطهای حداکثر 15 دقیقه پیش از حادثه را فراهم کند.
- RTOحداکثر زمان هدف برای بازگرداندن سرویس قابل استفاده پس از اختلال. کپی شدن فایلها یا روشن شدن ماشین مجازی، بهتنهایی پایان بازیابی نیست.
این مفاهیم در راهنمای برنامه بازیابی بحران IBM توضیح داده شدهاند. قانون بکاپ 3-2-1 خودش مقدار RPO و RTO را تعیین نمیکند؛ این اعداد باید از نیاز کسبوکار بیایند.
2. محل هر نسخه و خطر مشترک آن را مشخص کنید
یک چیدمان قابل بررسی برای شرکت کوچک یا متوسط، داده اصلی روی سرور، بکاپ محلی روی مخزن مستقل و نسخه دیگر روی فضای ذخیرهسازی شیءگرا در سایت جداست. مخزن محلی میتواند NAS یا سرور بکاپ باشد؛ فضای شیءگرا نیز باید با نرمافزار بکاپ سازگار باشد. در راهنمای Veeam نیز ذخیرهسازی محلی و ابری بهعنوان یکی از ترکیبها مطرح شده است.
در این اجرای قانون بکاپ 3-2-1، فقط نام دستگاهها مهم نیست. مخزن بکاپ روی ماشین مجازی همان میزبان و همان Datastore، با خرابی میزبان یا ذخیرهساز اصلی در معرض خطر مشترک قرار میگیرد. 2 هارد با برند متفاوت نیز بهخودیخود 2 نوع رسانه محسوب نمیشوند.
نسخه خارج از محل باید در برابر حادثه محل اصلی مستقل باشد. اتاق دیگر همان ساختمان برای آتشسوزی یا سرقت گسترده جداسازی کافی ایجاد نمیکند. همچنین بکاپ خارج از محل که با همان حساب مدیریتی قابل حذف است، هنوز در برابر سرقت آن حساب آسیبپذیر است.
3. زمانبندی هر مقصد را جداگانه تعیین کنید
داشتن بکاپ محلی هر 15 دقیقه و انتقال شبانه به مقصد دوم، به معنی RPO برابر 15 دقیقه برای همه حوادث نیست. اگر سایت اصلی از دست برود، نقطه بازیابی شما به تازهترین داده موجود در مقصد دوم محدود میشود.
برای قانون بکاپ 3-2-1، زمان داده داخل آخرین نسخه قابل بازیابی هر مقصد را ثبت کنید. فاصله اجرای کار، مدت تهیه بکاپ، صف انتقال و شکستهای احتمالی همگی روی تازگی نسخه اثر میگذارند. هشدار را برای عبور سن نسخه از RPO تعیینشده تنظیم کنید.
مدت نگهداری یا Retention را نیز مشخص کنید. نگهداری 30 روز نسخه تاریخی میتواند یک فرض اولیه برای طراحی باشد، اما برای همه شرکتها کافی نیست. زمان کشف اشتباه، نیاز مالی و قراردادی و ظرفیت مخزن تعیینکنندهاند. فایلهای بکاپ افزایشی ممکن است به نسخه کامل و حلقههای قبلی وابسته باشند؛ حذف را از مسیر نرمافزار و با رعایت زنجیره انجام دهید.
4. برای دیتابیس و ماشین مجازی، بکاپ سازگار تهیه کنید
قانون بکاپ 3-2-1 درباره تعداد و محل نسخههاست؛ سالم بودن محتوای آنها مسئله جداگانهای است. کپی دستی فایل دیتابیس در حال کار را بدون روش مورد تایید سازنده، بکاپ معتبر فرض نکنید. برای دیتابیس از ابزار بومی یا راهکار سازگار با برنامه استفاده کنید.
برای نمونه، در SQL Server بازیابی تا یک زمان مشخص به مدل بازیابی و زنجیره بکاپ مناسب وابسته است. مدل Simple از Transaction Log Backup پشتیبانی نمیکند. در مدل Full، داشتن بکاپ کامل مناسب و زنجیره پیوسته بکاپ لاگ برای بازیابی مورد نظر اهمیت دارد.
قبل از تغییر با متخصص مشورت کنید.تغییر Recovery Model بدون برنامه بکاپ لاگ و پایش فضای دیسک میتواند مشکل تازهای ایجاد کند. برای ماشین مجازی نیز پشتیبانی نسخه نرمافزار بکاپ از هایپروایزر و پردازش سازگار با برنامه را بررسی کنید.
5. دسترسی، رمزگذاری و اطلاعات لازم برای بازیابی را جدا کنید
در طراحی قانون بکاپ 3-2-1، حساب مدیریتی مخزن را از حسابهای روزمره جدا کنید و دسترسی سرویس بکاپ را به نیاز واقعی محدود نگه دارید. برای ورود مدیریتی، احراز هویت چندعاملی را در صورت پشتیبانی فعال کنید. کاربران عادی نباید امکان حذف نسخههای پشتیبان را داشته باشند.
نسخههای حساس را در انتقال و نگهداری رمزگذاری کنید. کلید بازیابی، تنظیمات نرمافزار بکاپ و اطلاعات لازم برای دسترسی اضطراری باید در محل امن و قابل دسترس برای افراد مجاز نگهداری شوند؛ ذخیره تنها نسخه کلید روی همان سرور، بازیابی را به سلامت آن وابسته میکند.راهنمای مقابله با باجافزار CISAبر نسخههای آفلاین، رمزگذاری و آزمون بازیابی تاکید دارد.
قانون بکاپ 3-2-1 در برابر باجافزار چه کمبودی دارد؟
اگر مهاجم بتواند همه نسخهها را حذف کند، پراکندگی آنها کافی نیست. در الگوی تکمیلی 3-2-1-1-0 که درراهنمای Veeamتوضیح داده شده، 1 نسخه آفلاین، جدا از دسترسی مستقیم یا تغییرناپذیر اضافه میشود و 0 به نبود خطای شناساییشده پس از بررسی و آزمون بازیابی اشاره دارد.
برای تقویت قانون بکاپ 3-2-1، این نسخه میتواند یکی از همان نسخههای خارج از محل باشد؛ داشتن نسخه چهارم الزام این الگو نیست. آفلاین و تغییرناپذیر نیز یکی نیستند: نسخه آفلاین اتصال فعال ندارد؛ نسخه تغییرناپذیر میتواند آنلاین باشد، اما حذف یا تغییر نسخه محافظتشده در مدت تعیینشده محدود میشود.
این محافظت به پیادهسازی وابسته است. برای نمونه، Object Lock در Amazon S3 روی نسخه مشخص شیء اعمال میشود و حالتهای نگهداری آن محدودیتهای متفاوتی دارند. قبل از انتخاب حالت قفل و مدت نگهداری با متخصص مشورت کنید؛ ممکن است حذف زودتر از موعد ممکن نباشد و هزینه ذخیرهسازی ادامه پیدا کند. عدد 0 نیز تضمین نبود همه خطاها یا آلودگیهای کشفنشده نیست.
سناریوی فرضی: بکاپ شرکت پخش با 30 کاربر
برای دیدن کاربرد قانون بکاپ 3-2-1، یک شرکت فرضی با نرمافزار حسابداری، فایلسرور و VoIP را در نظر بگیرید. اعداد زیر فرض آموزشی هستند و گزارش پروژه واقعی XNET محسوب نمیشوند.
| سرویس | هدف پیشنهادی در این سناریو | آزمون پذیرش بازیابی |
|---|---|---|
| حسابداری | RPO برابر 15 دقیقه؛ RTO برابر 4 ساعت | ورود کاربر، مشاهده آخرین اسناد و باز شدن پیوستها |
| فایلسرور | RPO برابر 4 ساعت؛ RTO برابر 8 ساعت | باز شدن فایل و حفظ مجوز دسترسی پوشه |
| تنظیمات VoIP | بکاپ پس از تغییر تاییدشده و نسخه زمانبندیشده روزانه | بازیابی تنظیمات و تماس آزمایشی در محیط کنترلشده |
فرض کنید در آزمون، دیتابیس حسابداری برمیگردد اما پیوست فاکتورها باز نمیشود؛ چون در پوشهای خارج از دیتابیس ذخیره شده و در برنامه بکاپ نبوده است. اقدام اصلاحی، افزودن آن پوشه و طراحی بازیابی هماهنگ دیتابیس و فایلهاست. اگر نگهداری ضبط مکالمات هم لازم باشد، بکاپ تنظیمات VoIP آن را پوشش نمیدهد.
نکته دیگر این سناریو، سرعت بازیابی است. دریافت کامل 1 ترابایت داده با لینک 100 مگابیتبرثانیه، حتی در محاسبه نظری و بدون سربار حدود 22.2 ساعت طول میکشد. پس RTO برابر 4 ساعت را نمیتوان صرفا با وعده دانلود بکاپ کامل پذیرفت؛ محل اجرای سرویس جایگزین و روش بازیابی باید پیشاپیش آزمایش شوند.
ارزش قانون بکاپ 3-2-1 در این مثال وقتی مشخص میشود که نسخهها، وابستگی برنامه و زمان بازگشت سرویس با هم بررسی شوند.
چگونه مطمئن شویم بکاپ قابل استفاده است؟
گزارش موفقیت تهیه بکاپ، پایان ارزیابی قانون بکاپ 3-2-1 نیست. یک آزمون محدود اما مشخص تعریف کنید
- از یک تاریخ مشخص، نمونه فایل، دیتابیس یا ماشین مجازی انتخاب کنید.
- آن را در محیط جدا و بدون بازنویسی اطلاعات اصلی بازیابی کنید. سرویس آزمایشی نباید پیام، تراکنش یا تماس ناخواسته به محیط واقعی بفرستد.
- با مسئول سرویس، ورود کاربر، باز شدن داده، مجوزها و وابستگیهای برنامه را بررسی کنید.
- زمان قابل استفاده شدن سرویس و فاصله آخرین داده بازیابیشده تا زمان فرضی حادثه را ثبت کنید.
- آزمون نسخه خارج از محل را هم انجام دهید و هر ایراد را با مسئول و مهلت اصلاح ثبت کنید.
برای شروع میتوان آزمون نمونه را ماهانه و آزمون کامل سرویس حیاتی را فصلی برنامهریزی کرد؛ این تناوب نمونه است و با حساسیت سرویس تغییر میکند. پس از تغییر مهم در برنامه یا زیرساخت نیز آزمون مرتبط را تکرار کنید. این کار میتواند کنار بررسیهایچکلیست نگهداری سرور HPقرار بگیرد.
چکلیست کنترل قانون بکاپ 3-2-1
- برای هر داده حیاتی، نسخه اصلی و حداقل 2 نسخه پشتیبان مشخص است.
- تنوع رسانه یا فناوری و خطر خرابی مشترک بررسی شده است.
- حداقل 1 نسخه مستقل خارج از محل اصلی وجود دارد.
- حداقل 1 نسخه آفلاین یا تغییرناپذیر، با تنظیمات بررسیشده وجود دارد.
- RPO و RTO برای سرویسها و سناریوهای خرابی مشخص شدهاند.
- تازگی نسخه محلی و خارج از محل، ظرفیت و شکست کارها پایش میشود.
- مدت نگهداری و وابستگی زنجیره بکاپ مشخص است.
- کلیدها، تنظیمات و دسترسی اضطراری در زمان خرابی سرور اصلی قابل دستیابی هستند.
- بازیابی آزمایشی انجام شده و نتیجه به تایید مسئول سرویس رسیده است.
اگر برای بررسی زیرساخت لازم برای این برنامه به کمک نیاز دارید، فهرست سرویسها، حجم داده، RPO و RTO مورد انتظار را آماده کنید و درخواست خود را از طریقخدمات زیرساخت و مشاوره XNETمطرح کنید.
پرسشهای متداول
آیا قانون بکاپ 3-2-1 یعنی باید 3 بکاپ بگیریم؟
خیر. حداقل 3 نسخه شامل داده اصلی و 2 نسخه پشتیبان است. چند فایل بکاپ روی همان دیسک، استقلال لازم در برابر خرابی آن دیسک را ایجاد نمیکند.
آیا برای قانون بکاپ 3-2-1 خرید 3 سرور لازم است؟
خیر. تعداد نسخهها با تعداد سرورها برابر نیست. ترکیب مخزن محلی، نوار یا فضای ابری مستقل، با توجه به حجم داده و نیاز بازیابی انتخاب میشود.
آیا قانون بکاپ 3-2-1 با NAS بهتنهایی اجرا میشود؟
خیر. NAS میتواند یکی از مقصدهای بکاپ باشد، اما وجود آن کنار سرور بهتنهایی شرط نسخه خارج از محل، تنوع رسانه و محافظت از حذف مخرب را تامین نمیکند.
آیا بکاپ ابری همیشه امن است؟
خیر. دسترسی حساب، نسخهبندی، قفل نگهداری، رمزگذاری و امکان بازیابی باید بررسی شوند. زمان دانلود، هزینه خروج داده و دسترسپذیری سرویس نیز در انتخاب مقصد اهمیت دارند.
هر چند وقت یکبار باید بکاپ بگیریم؟
قانون بکاپ 3-2-1 فاصله ثابت تعیین نمیکند. زمانبندی باید با میزان تغییر داده و RPO هماهنگ باشد؛ بکاپ شبانه برای سرویسی که از دست رفتن بیش از 15 دقیقه داده را نمیپذیرد، کافی نیست.
آیا با داشتن این الگو، بازیابی اطلاعات تضمین میشود؟
خیر. کامل بودن داده، سالم بودن نسخه، دسترسی به کلیدها، سازگاری محیط مقصد و نتیجه آزمون بازیابی تعیینکنندهاند. این الگو احتمال از دست رفتن همزمان نسخهها را کاهش میدهد.
برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.