بکاپ شرکت هر چند وقت گرفته شود و چقدر نگه داشته شود؟

اگر از دست‌رفتن تغییرات یک روز کاری قابل قبول نیست، اتکا به یک بکاپ پایان روز کافی نخواهد بود. برای نرم‌افزاری که سفارش و دریافت مالی در آن مرتب ثبت می‌شود، فاصله کوتاه‌تر یا روش پشتیبان‌گیری سازگار با همان برنامه باید بررسی شود. در مقابل، پوشه‌ای با تغییرات کم ممکن است به همان تناوب نیاز نداشته باشد.

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

زمان‌بندی ثبت‌شده در ابزار هم نتیجه واقعی را نشان نمی‌دهد. اگر بکاپ شب گذشته خطا داشته، آخرین نسخه سالم ممکن است قدیمی‌تر باشد. مسئول پیگیری باید فاصله از آخرین نسخه قابل استفاده را ببیند، نه فقط اینکه وظیفه بکاپ در تقویم فعال است.

RPO یعنی هدف شرکت درباره بیشترین فاصله زمانی داده‌ای که از دست‌رفتنش قابل تحمل است. سؤال ساده این است: اگر مشکل الان رخ دهد، تا کدام بخش از کار انجام‌شده را می‌توان دوباره ثبت یا تولید کرد؟ این هدف به انتخاب روش و فاصله تهیه نسخه کمک می‌کند.

RTO هدف زمان بازگشت سرویس است: کار تا چه مدت می‌تواند متوقف بماند؟ رسیدن به این هدف به دسترسی به بکاپ، مقصد بازیابی، وابستگی برنامه و زمان بررسی کارکرد آن بستگی دارد. بکاپ پرتکرار لزوماً به معنی راه‌اندازی سریع دوباره برنامه نیست.

برای مثال فرضی، شرکتی می‌تواند حداکثر یک ساعت ثبت‌های اخیر را دوباره انجام دهد. اگر ساعت ۱۱ آخرین نسخه قابل استفاده مربوط به ساعت ۹ باشد، برنامه فعلی به این نیاز نمی‌رسد. ممکن است علت، تناوب نامناسب یا شکست اجرای بعدی باشد؛ خود عدد زمان‌بندی علت را روشن نمی‌کند.

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

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

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

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

مثلاً نگهداری یک نسخه منتخب پایان ماه، به معنی امکان برگشت به هر روز همان ماه نیست. اگر تغییر اشتباه در میانه ماه رخ داده، نسخه پایان ماه ممکن است آن تغییر را هم داشته باشد. بنابراین انتخاب نسخه‌های بلندمدت باید با نوع اشتباه‌هایی که می‌خواهید جبران کنید تناسب داشته باشد.

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

فرض کنید شرکت سه گروه اطلاعات دارد: نرم‌افزار مالی پرتغییر، اسناد پروژه که اشتباه‌هایشان دیرتر معلوم می‌شود و خروجی‌های موقتی قابل تولید دوباره. تعیین یک تناوب و یک مدت نگهداری برای هر سه، ممکن است هم پوشش ناقص بسازد و هم فضا را بی‌دلیل مصرف کند.

• برای برنامه مالی، تازگی داده و روش سازگار با پایگاه داده اولویت دارند؛ هدف بازگشت باید با مسئول برنامه تأیید شود.
• برای اسناد پروژه، نسخه پیش از حذف یا ویرایش اشتباه مهم است؛ نگهداری باید فرصت کشف آن اشتباه را پوشش دهد.
• برای خروجی موقت، ابتدا مشخص شود واقعاً قابل تولید دوباره است و تولیدش چقدر زمان می‌برد؛ سپس درباره پوشش آن تصمیم گرفته شود.

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

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

برای نمونه، مستند نگهداری کوتاه‌مدت Veeam برای نسخه ۱۳ تفاوت وظایف تازه با بعضی وظایف منتقل‌شده از نسخه‌های قبلی را توضیح می‌دهد. بنابراین عدد یک آموزش قدیمی را نمی‌توان بدون بررسی نسخه و نوع وظیفه به سیستم فعلی منتقل کرد.

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

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

زمان خلوت شبکه معمولاً فرصت مناسبی برای کار سنگین است، اما تازگی موردنیاز داده هم باید رعایت شود. اگر همه کارها به پایان روز موکول شوند، شاید هدف برنامه مالی برآورده نشود. مسئول فنی باید مدت اجرای واقعی و اثر آن بر کاربران را کنار نیاز کسب‌وکار بسنجد.

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

تعطیلی، خاموش‌بودن دستگاه یا پایان اعتبار سرویس مقصد نباید بی‌خبر باعث توقف نسخه‌برداری شوند. راه دریافت هشدار و فرد مسئول رسیدگی مشخص باشند؛ دریافت پیام بدون پیگیری، شکاف نسخه‌ها را پر نمی‌کند.

در بازبینی، فقط تعداد وظایف موفق را نبینید. تاریخ آخرین نسخه قابل استفاده برای هر گروه، رسیدن آن به مقصد دوم و وجود نسخه‌های قدیمی موردنیاز را بررسی کنید. نمونه‌ای که از نسخه جدید برمی‌گردد، سلامت همه نسخه‌های ماه‌های قبل را ثابت نمی‌کند.

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