امروزه بخش بزرگی از فعالیتها و فرایندهای سازمانی به دادهها وابسته است؛ بااینحال، همه سازمانها متناسب با اهمیت دادههای خود از آنها محافظت نمیکنند. برخی مجموعهها تنها پس از حذف، خرابی یا از دسترس خارجشدن اطلاعات، ضرورت ایجاد Backup و تدوین یک استراتژی بازیابی مطمئن را جدی میگیرند.
حتی داشتن Backup نیز بهتنهایی بازیابی موفق دادهها را تضمین نمیکند. اگر نسخههای پشتیبان بهدرستی پیکربندی، پایش و آزمایش نشوند، ممکن است هنگام وقوع حادثه قابلاستفاده نباشند.
در این مقاله، اشتباهات رایج در مدیریت Backup و راههای پیشگیری از Data Loss را بررسی میکنیم و با اهمیت نگهداری نسخههای On-site و Off-site آشنا میشویم.
راهنمای مطالعه
سه اشتباه رایج در مدیریت Backup عبارتاند از:
- پایشنکردن Backup Jobها و آزمایشنکردن فرایند Restore
- تنظیم نادرست Retention Plan
- برآورد نادرست ظرفیت Storage و اهداف RPO و RTO
چرا Backup برای حفاظت از دادههای سازمان ضروری است؟
طبق گزارش Infrascale در سال ۲۰۲۵، در تحلیل دیدگاههای آنلاین بیش از ۷۱ هزار فعال حوزه فناوری در آمریکا، ۶۷.۷٪ از کسبوکارها از تجربه Data Loss قابلتوجه خبر دادهاند. نتایج این بررسی نشان میدهد Malware، اختلال سیستم، تهدیدهای داخلی، Data Corruption و خطاهای انسانی از عوامل اصلی از دست رفتن دادهها هستند.
Cyberattack تنها عامل Data Loss نیست. خرابی Hardware و Software، خطای انسانی، بلایای طبیعی و پیکربندی نادرست زیرساخت نیز میتوانند دادههای حیاتی سازمان را حذف، خراب یا از دسترس خارج کنند. تصویر زیر، مهمترین عوامل Data Loss و قابلیتهای پیشنهادی Open‑E برای کاهش اثر هرکدام را نشان میدهد:
RAID و HA اثر خرابی Hardware را کاهش میدهند، Snapshot و Backup Copy امکان بازیابی پس از خطای انسانی را فراهم میکنند و نگهداری نسخههای On-site و Off-site از دادهها، سطح حفاظت در برابر حوادث محلی و بلایای طبیعی را افزایش میدهد.
بااینحال، صرفاً استفاده از این قابلیتها کافی نیست. اگر Backup و سایر لایههای Data Protection بهدرستی پیکربندی، نگهداری و آزمایش نشوند، ممکن است هنگام وقوع حادثه امکان بازیابی دادهها وجود نداشته باشد.
۳ اقدام ضروری برای اطمینان از قابلیت بازیابی Backup
ایجاد Backup یکی از اقدامات ضروری برای حفاظت از دادههای سازمان است؛ اما صرفاً داشتن نسخه پشتیبان، بازیابی موفق اطلاعات را تضمین نمیکند. Backup زمانی قابلاعتماد است که بهدرستی پیکربندی شود، بهطور مستمر تحت نظارت قرار گیرد و امکان بازیابی اطلاعات از آن در بازههای زمانی مشخص آزمایش شود. در ادامه، مهمترین نکاتی را بررسی میکنیم که برای اطمینان از عملکرد صحیح Backup باید در نظر گرفته شوند.
۱. پایش و آزمایش مستمر Backup
برای Backup Server میتوان پیکربندیهای مختلفی تعریف کرد و انتخاب تنظیمات مناسب باید براساس حجم داده، میزان تغییرات، اهمیت سرویسها و اهداف RPO و RTO انجام شود. بااینحال، حتی پیکربندی صحیح نیز تضمین نمیکند که نسخههای پشتیبان در طول زمان همواره سالم و قابلبازیابی باقی بمانند. به همین دلیل، وضعیت Backup Jobها باید بهصورت مستمر پایش و فرایند Restore نیز در بازههای زمانی مشخص آزمایش شود.
یکی از نمونههای شناختهشده Data Loss، حادثهای است که هنگام تولید انیمیشن Toy Story 2 برای Pixar رخ داد. بر اثر یک خطای انسانی، بخش بزرگی از فایلهای پروژه بهطور تصادفی حذف شد. در ادامه مشخص شد نسخههای ذخیرهشده در Backup Server نیز برای مدتی بهدرستی بررسی و بهروزرسانی نشدهاند. بازیابی پروژه در نهایت با استفاده از نسخهای انجام شد که یکی از کارکنان خارج از زیرساخت اصلی نگهداری میکرد.
این حادثه یک نکته مهم را نشان میدهد: وجود Backup بهتنهایی کافی نیست؛ سلامت نسخههای پشتیبان و امکان Restore موفق از آنها باید بهطور منظم بررسی شود.
۲. بررسی و تنظیم Retention Plan
Retention Plan مجموعهای از قوانین زمانبندیشده برای ایجاد، انتقال، نگهداری و حذف خودکار Snapshotهاست. در Open‑E JovianDSS میتوان مشخص کرد Snapshotها با چه فاصله زمانی ایجاد شوند، چه مدت باقی بمانند و در کدام مقصد نگهداری شوند. این قوانین را میتوان بهصورت جداگانه برای Production Server ،On-site Backup Server و Off-site Backup Server تنظیم کرد.
نکته مهم این است که Snapshot بهتنهایی Backup محسوب نمیشود. Snapshot وضعیت دادهها را در یک لحظه مشخص ثبت میکند و معمولاً به همان Storage و دادههای اصلی وابسته است؛ بنابراین خرابی Storage Pool، حذف عمدی Snapshot یا دسترسی غیرمجاز مدیریتی میتواند نقاط بازیابی را نیز از بین ببرد. زمانی که Snapshot به یک Backup Server مستقل، ترجیحاً در موقعیت دیگری، Replicate شود، لایه محافظتی مطمئنتری در برابر Data Loss، خرابی سیستم و Ransomware ایجاد میشود.
Read-only بودن Snapshot از تغییر مستقیم محتوای آن جلوگیری میکند و امکان Rollback یا ایجاد Clone از وضعیت قبلی دادهها را فراهم میسازد؛ اما بهتنهایی مانع حذف Snapshot توسط یک حساب مدیریتی Compromised نمیشود. برای افزایش مقاومت در برابر Ransomware باید از کنترل دسترسی، جداسازی Backup، Retention Policy مناسب و در صورت امکان، قابلیتهای Immutability استفاده شود.
فاصله ایجاد Snapshotها میتواند از چند دقیقه تا چند روز متغیر باشد؛ اما انتخاب آن نباید سلیقهای باشد. تناوب ایجاد و مدت نگهداری Snapshot باید براساس اهداف RPO و RTO، نرخ تغییر دادهها، اهمیت Workload، ظرفیت Storage و الزامات قانونی سازمان تعیین شود. پیکربندی نامناسب Retention Plan ممکن است باعث از دست رفتن نقاط بازیابی موردنیاز یا مصرف بیرویه ظرفیت Storage شود.
برای مثال، فرض کنید در سازمانی فعالیت میکنید که دادههای حیاتی آن در طول روز کاری دائماً تغییر میکنند. بااینحال، برای جلوگیری از واردشدن بار اضافی به سیستم، Backup فقط یکبار در روز انجام میشود. در چنین شرایطی، اگر نزدیک به پایان روز کاری و پیش از اجرای Backup روزانه مشکلی رخ دهد، ممکن است بخش عمده دادههای حیاتی ایجادشده در طول آن روز از دست برود. با استفاده از Retention Plan در Open‑E JovianDSS میتوانید وضعیت Volume را به دفعات موردنیاز ثبت کنید، بدون نیاز به اجرای یک Backup کامل در هر نوبت و با سربار کمتر نسبت به بسیاری از روشهای سنتی Backup.
نمونهای واقعی از پیکربندی نادرست Retention Plan
طبق گزارش Open‑E، یکی از مشتریان این شرکت پس از حذفشدن تمام Snapshotهای نگهداریشده در موقعیت Off-site، از تیم پشتیبانی Open‑E درخواست کمک کرد. بررسیها نشان داد که Retention Plan بهدرستی پیکربندی نشده و مدت نگهداری Snapshotها در موقعیت Off-site کوتاهتر از زمان موردنیاز تعیین شده است. در نتیجه، دادههای قدیمی موردنیاز مشتری بهصورت خودکار حذف شده بودند.
به همین دلیل، باید از خود بپرسید: «Backup Copyها را برای چه مدتی باید نگهداری کنم؟» پاسخ این پرسش به نوع دادهها و اسناد ذخیرهشده بستگی دارد. برای مثال، مدت نگهداری اسناد مالیاتی در یک سازمان دولتی با بروشورهای تخفیفی یک کسبوکار محلی یکسان نیست.
برای جلوگیری از چنین اتفاقاتی، تنظیمات Retention Plan باید پیش از راهاندازی نهایی و پس از هر تغییر در نیازهای سازمان بازبینی شود. در صورت نیاز، میتوان هنگام نصب و پیکربندی راهکار از پشتیبانی فنی کمک گرفت.
۳. اهمیت ظرفیت Storage و تعیین RPO و RTO
پیش از راهاندازی Backup باید نیازهای سازمان بهدقت ارزیابی شوند. لازم است مشخص شود Backup در چه فاصلههایی ایجاد شود، چه مدت نگهداری شود و چه میزان از ظرفیت Backup Server را اشغال کند. همچنین باید مشخص شود سازمان در صورت وقوع یک حادثه، از دست رفتن چه مقدار داده را میتواند بپذیرد و بازیابی اطلاعات حداکثر چقدر میتواند طول بکشد، پیش از آنکه فرایندهای کاری سازمان دچار اختلال شوند. این مقادیر با استفاده از معیارهای زیر محاسبه میشوند:
- RPO یا Recovery Point Objective: حداکثر بازه زمانی قابلقبول برای Data Loss؛ این معیار مشخص میکند پس از بازیابی، از دست رفتن دادههای مربوط به چه مدت برای سازمان قابلپذیرش است.
- RTO یا Recovery Time Objective: حداکثر زمان قابلقبول برای بازیابی سرویس و بازگشت آن به وضعیت عملیاتی پس از وقوع اختلال.
با تعیین این دو معیار، میتوانید پیش از راهاندازی راهکار ذخیرهسازی و Backup Server، گزینهای را انتخاب کنید که بیشترین تطابق را با اهداف سازمان داشته باشد. بازیابی داده از یک Off-site Backup Server ممکن است بسته به حجم دادهها، پهنای باند شبکه و فاصله محل نگهداری، زمان بیشتری نیاز داشته باشد. به همین دلیل، برای Workloadهایی با RTO کوتاه میتوان در کنار نسخه Off-site، یک On-site Backup نیز در نظر گرفت.
اما اگر Workload سازمان کمتر از مقدار واقعی برآورد شود، چه اتفاقی رخ میدهد؟ طبق گزارش Open‑E، برخی از مشتریان این شرکت زمانی با پیامد این اشتباه مواجه شدند که فضای کافی برای نگهداری Snapshotهای منتقلشده به Backup Server در اختیار نداشتند. این مشکل ممکن است به دلایل زیر رخ دهد:
- برآورد نادرست Workload سازمان: اختصاص فضای کمتر از ظرفیت موردنیاز
- پیکربندی نامناسب Retention Plan: ایجاد بیشازحد Snapshot، گاهی حتی بدون تغییر دادهها، و در نتیجه مصرف فضای Storage
کاهش شدید فضای آزاد یا پرشدن ظرفیت Backup Server باید بلافاصله بررسی شود؛ زیرا اگر سیستم فضای کافی برای ایجاد Snapshot یا اجرای Backup Job بعدی نداشته باشد، Restore Point جدید ثبت نمیشود و آخرین تغییرات دادهها تحت پوشش Backup قرار نمیگیرند.
با استفاده از Open‑E JovianDSS میتوان سطح حفاظت از دادهها و Backupها را افزایش داد. قابلیت On-site & Off-site Data Protection امکان ایجاد چندین Backup Server در موقعیتهای Local و Remote را فراهم میکند. علاوه بر این، زیرساخت High Availability Clustering با کاهش Downtime و حذف نقاط شکست منفرد در اجزای تحت پوشش Cluster، به تداوم دسترسی به دادهها و جلوگیری از اختلال در Workloadهای سازمان کمک میکند.
جهت دریافت مشاوره خرید استوریج با قیمت مناسب و متناسب با نیاز سازمانتان، میتوانید با کارشناسان شرکت رایانش ابری پردیس تماس بگیرید.
رایانش ابری پردیس با بیش از ۱۵ سال سابقه در ارائه خدمات و راهکارهای ذخیرهسازی اطلاعات و مشاوره خرید استوریج آماده همکاری با شماست.
چرا Backup بهتنهایی برای حفاظت از دادهها کافی نیست؟
ضعف در طراحی یا پیکربندی Backup میتواند هنگام وقوع Data Loss پیامدهای جدی برای سازمانها داشته باشد. برای نمونه، مجموع مبالغ پرداختشده در حملات Ransomware در سال ۲۰۲۳ از ۱.۱ میلیارد دلار فراتر رفت. این رقم نشان میدهد چنین حملاتی تا چه اندازه میتوانند برای سازمانها خطرناک و پرهزینه باشند.
بااینحال، Ransomware تنها تهدید موجود نیست. Silent Data Corruption، بروز خطا هنگام Cluster Rebuild، خرابی Driveها، بلایای طبیعی، خطاهای انسانی، System Downtime و سرقت تجهیزات نیز میتوانند امنیت و دسترسپذیری دادهها را تهدید کنند.
یک استراتژی قابلاعتماد Data Protection نباید فقط به ایجاد Backup محدود شود. پایش مستمر Backup Jobها، آزمایش دورهای Restore، تنظیم Retention Plan براساس RPO و RTO و نگهداری نسخههای On-site و Off-site، احتمال بازیابی موفق دادهها را هنگام وقوع اختلال افزایش میدهد. در نهایت، Backup زمانی ارزشمند است که سلامت آن تأیید شده باشد و بتوان دادهها را در زمان موردنیاز از آن بازیابی کرد.