بکاپ ۳-۲-۱ چیست؟ برنامهٔ عملی برای شرکت‌های کوچک

اگر لپ‌تاپ، فایل‌سرور و هارد بکاپ همگی در یک اتاق باشند، یک اتفاق ممکن است هر سه را از دسترس خارج کند. هدف برنامهٔ بکاپ شرکت این است که برای هر رخداد، مسیر بازگشت مشخصی داشته باشید. این راهنما کمک می‌کند یک برنامهٔ قابل بررسی بنویسید؛ انتخاب ظرفیت و زمان‌بندی باید با داده و امکانات خودتان انجام شود.

۱. اول مشخص کنید چه چیزی باید برگردد

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

دو معیار به تصمیم کمک می‌کند: RPO، حداکثر بازهٔ ازدست‌رفتن تغییرات که کسب‌وکار می‌پذیرد؛ و RTO، زمان هدف برای برگرداندن سرویس. اجرای روزانه برای داده‌ای با نیاز به بازیابی تغییرات ساعتی کافی نیست. از طرف دیگر، کوتاه‌کردن این هدف‌ها ممکن است هزینه و پیچیدگی ایجاد کند. راهنمای تعریف هدف و آزمون بکاپ از NCSC نیوزیلند

۲. اجزای ۳-۲-۱ را با سناریوی خرابی تطبیق دهید

«خارج از محل» با «آفلاین» یکی نیست. یک مقصد ابری یا شعبهٔ دیگر ممکن است همچنان با حساب آلوده قابل حذف باشد. در طرح نهایی، علاوه بر محل فیزیکی، دسترسی و رفتار حذف هر نسخه را جدا روی کاغذ مشخص کنید. محل دورتر فقط بخشی از خطر مشترک را کم می‌کند.

۳. برای حذف عمدی و باج‌افزار هم برنامه داشته باشید

راهنمای NCSC بریتانیا توصیه می‌کند نسخهٔ جدا از شبکه یا حفاظت مناسب سرویس ابری، چند محل نگهداری و آزمون بازگردانی داشته باشید؛ دیسک متصل دائمی می‌تواند در دسترس بدافزار قرار بگیرد. نسخه‌ها را پیش از بازیابی از نظر آلودگی بررسی کنید و فقط به دستگاه شناخته‌شدهٔ سالم وصل کنید. راهنمای حفاظت بکاپ در برابر باج‌افزار

در ارزیابی مقصد، دو سؤال جدا بپرسید: آیا حساب روزمره می‌تواند نسخه‌ها را حذف کند؟ آیا مدیر همان سرویس هم می‌تواند نگهداری را کوتاه کند؟ واژهٔ «غیرقابل‌تغییر» را بدون بررسی مدت قفل، اختیار مدیر، رفتار پایان نگهداری و روش بازگردانی نپذیرید. آفلاین‌بودن نیز اگر اتصال و جابه‌جایی دیسک‌ها فراموش شود، مشکل زمان‌بندی را حل نمی‌کند.

برای سرویس ابری بررسی کنید چه داده‌هایی واقعاً صادر و حفاظت می‌شوند. تاریخچهٔ نسخه‌ها و سطل بازیافت می‌توانند مفید باشند، اما به‌تنهایی جای نسخهٔ مستقل اطلاعات حیاتی را نمی‌گیرند. راهنمای NCSC دربارهٔ بکاپ مستقل دادهٔ ابری

۴. نمونهٔ فرضی یک برنامه برای شرکت کوچک

برای هر نسخه یک ردیف شامل دادهٔ تحت پوشش، زمان اجرا، مدت نگهداری، مسئول پیگیری خطا، محل نسخه و روش دسترسی اضطراری بنویسید. عددی را که هنوز آزمایش نشده، «هدف» بنامید. مدت نگهداری را بر اساس نیاز بازگشت به گذشته تعیین کنید؛ بکاپ تازه جای تمام نسخه‌های قدیمی موردنیاز را نمی‌گیرد.

بکاپ پایگاه داده را با کپی معمول پوشهٔ برنامه معادل نگیرید. روش پشتیبان‌گیری باید با همان نرم‌افزار و سازوکار پایگاه داده سازگار باشد. در طرح، نام فردی را ثبت کنید که بعد از بازگردانی، ورود به برنامه و درستی اطلاعات نمونه را تأیید می‌کند.

۵. آزمون بازیابی را قابل اندازه‌گیری کنید

1. یک فایل آزمایشیِ غیرمحرمانه بسازید و زمان، محتوای مورد انتظار و نسخهٔ بکاپ آن را ثبت کنید.
2. آن را در پوشهٔ جدا و با دسترسی کنترل‌شده بازگردانید؛ برای آزمون، فایل اصلی شرکت را حذف نکنید.
3. درستی محتوا، مجوز لازم و مدت بازگردانی را بررسی کنید.
4. برای برنامه‌ها، آزمون را در محیط جدا و با تأیید مالک داده انجام دهید؛ بازکردن یک فایل، اثبات بازیابی کل سرویس نیست.
5. نتیجه، خطا و اقدام اصلاحی را ثبت و پس از تغییر مهم در داده یا ابزار دوباره ارزیابی کنید.

گزارش «Job موفق» شاهد اجرای کار است؛ شاهد آماده‌بودن کسب‌وکار نیست. اگر مسئول قبلی در دسترس نباشد، آیا فرد جایگزین مسیر نسخه، روش احراز هویت و راهنمای بازگردانی را می‌داند؟ این سؤال را در تمرین جواب دهید، نه وسط بحران.

۶. خطاهایی که برنامه را ناقص می‌گذارند

• نگهداری همهٔ نسخه‌ها در یک رک، اتاق یا حساب مدیریتی.
• پیگیری‌نکردن خطای ظرفیت یا متوقف‌شدن اجرای خودکار.
• پوشش فایل‌ها بدون تنظیمات و وابستگی لازم برای راه‌اندازی برنامه.
• نبود مسئول جایگزین، راهنمای دسترسی اضطراری یا سیاست نگهداری.
• تلقی بکاپ به‌عنوان حفاظت کامل از سرقت اطلاعات؛ بازیابی، موضوع افشای داده را حل نمی‌کند.

اگر برنامهٔ فعلی شما هنوز مشخص نیست، خدمات بکاپ و بازیابی و طراحی استراتژی پشتیبان‌گیری ویوان برای بررسی پوشش، نگهداری و آزمون بازگردانی مرتبط‌اند.