بکاپ شرکت را کجا نگه داریم؛ داخل دفتر یا فضای ابری؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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