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

Backup و Disaster Recovery دو بخش مکمل از استراتژی حفاظت از اطلاعات سازمان هستند. Backup به معنای تهیه و نگهداری نسخه‌های پشتیبان از اطلاعات و سیستم‌هاست؛ در حالی که Disaster Recovery مجموعه‌ای از برنامه‌ها، زیرساخت‌ها و اقدامات فنی برای بازگرداندن سیستم‌ها و سرویس‌های سازمان پس از یک اختلال جدی است.

به بیان ساده، Backup مشخص می‌کند چگونه اطلاعات از دست‌رفته را برگردانیم و Disaster Recovery مشخص می‌کند چگونه کل سیستم را دوباره عملیاتی کنیم.

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

Backup چیست و چرا برای سازمان‌ها اهمیت دارد؟

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

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

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

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

چه اطلاعاتی باید پشتیبان‌گیری شوند؟

یکی از اشتباهات رایج در سازمان‌ها این است که تمام توجه واحد IT به پشتیبان‌گیری از پایگاه داده محدود می‌شود؛ در حالی که عملکرد یک سیستم نرم‌افزاری معمولاً به مجموعه‌ای از اجزای وابسته است.

موارد زیر باید در فرآیند شناسایی دارایی‌های قابل پشتیبان‌گیری بررسی شوند:

• پایگاه‌های داده: اطلاعات مشتریان، سفارش‌ها، تراکنش‌ها، اسناد مالی و سوابق عملیاتی.

• فایل‌های سازمانی: قراردادها، اسناد، گزارش‌ها، تصاویر و فایل‌های بارگذاری‌شده توسط کاربران.

• کدهای نرم‌افزار: سورس‌کد، نسخه‌های انتشار و تنظیمات موردنیاز برای استقرار مجدد.

• تنظیمات زیرساخت: تنظیمات سرورها، شبکه، سرویس‌ها و محیط‌های اجرایی.

• اطلاعات هویتی و دسترسی: تنظیمات مرتبط با کاربران، نقش‌ها و سیاست‌های دسترسی.

• اطلاعات پیکربندی: Connection Stringها، تنظیمات سرویس‌ها و سایر اطلاعات ضروری برای راه‌اندازی مجدد سیستم.

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

Disaster Recovery چیست؟

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

این حادثه می‌تواند شامل موارد زیر باشد:

• خرابی کامل سرور یا تجهیزات ذخیره‌سازی

• آتش‌سوزی یا آسیب فیزیکی به مرکز داده

• حملات سایبری و باج‌افزارها

• خرابی یا تخریب پایگاه داده

• اختلال گسترده در شبکه یا زیرساخت ابری

• خطاهای انسانی و حذف اطلاعات حیاتی

• خرابی نرم‌افزارهای زیرساختی

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

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

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

این همان نقطه‌ای است که اهمیت Disaster Recovery مشخص می‌شود.

تفاوت Backup و Disaster Recovery چیست؟

Backup و Disaster Recovery ارتباط نزدیکی با یکدیگر دارند، اما وظایف یکسانی انجام نمی‌دهند.

نکته مهم این است که Backup یکی از اجزای اصلی Disaster Recovery محسوب می‌شود.

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

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

بنابراین این دو راهکار باید در کنار یکدیگر طراحی شوند.

RTO و RPO چیستند و چه نقشی در بازیابی اطلاعات دارند؟

در طراحی استراتژی بازیابی، دو شاخص بسیار مهم وجود دارد: RTO و RPO.

این دو شاخص مشخص می‌کنند سازمان چه میزان توقف سیستم و چه میزان از دست رفتن اطلاعات را می‌تواند تحمل کند.

RTO چیست؟ (Recovery Time Objective)

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

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

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

RPO چیست؟ (Recovery Point Objective)

RPO حداکثر میزان قابل‌قبول از دست رفتن اطلاعات بر اساس زمان آخرین نقطه بازیابی است.

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

این موضوع بر دفعات پشتیبان‌گیری و استفاده از روش‌هایی مانند ثبت پیوسته تغییرات پایگاه داده تأثیر می‌گذارد.

چگونه RTO و RPO مناسب سازمان را تعیین کنیم؟

تعیین این دو شاخص نباید صرفاً براساس توانایی فنی واحد IT انجام شود. نیازهای کسب‌وکار باید مبنای تصمیم باشند.

برای تعیین آن‌ها باید به این پرسش‌ها پاسخ داد:

1. توقف هر سیستم چه تأثیری بر فعالیت سازمان دارد؟

2. چه مدت توقف برای سازمان قابل‌تحمل است؟

3. از دست رفتن اطلاعات چند دقیقه یا چند ساعت اخیر چه هزینه‌ای ایجاد می‌کند؟

4. آیا امکان ادامه موقت فرآیندها به شکل دستی وجود دارد؟

5. هزینه کاهش زمان بازیابی و کاهش میزان اطلاعات ازدست‌رفته چقدر است؟

برای مثال، ممکن است یک سامانه گزارش‌گیری داخلی بتواند چند ساعت از دسترس خارج باشد؛ اما سیستم ثبت تراکنش‌های مالی به زمان بازیابی بسیار کوتاه‌تری نیاز داشته باشد.

این تفاوت باید در طراحی برنامه بازیابی لحاظ شود. راهنمای NIST نیز بر شناسایی اهمیت سیستم‌ها و تعیین اهداف بازیابی براساس تأثیر اختلال بر فعالیت‌های سازمان تأکید می‌کند.

انواع روش‌های Backup و پشتیبان‌گیری اطلاعات

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

سه روش متداول Backup عبارت‌اند از:

۱. Full Backup

در این روش از تمام اطلاعات انتخاب‌شده یک نسخه کامل تهیه می‌شود.

مزایا:

• ساختار ساده و قابل مدیریت

• فرآیند بازیابی نسبتاً ساده

• وابستگی کمتر به نسخه‌های قبلی

معایب:

• مصرف بیشتر فضای ذخیره‌سازی

• زمان طولانی‌تر تهیه نسخه پشتیبان

• افزایش مصرف منابع در زمان اجرای عملیات

این روش برای ایجاد نسخه پایه و پشتیبان‌گیری دوره‌ای از اطلاعات اهمیت دارد.

۲. Incremental Backup

در Incremental Backup فقط اطلاعاتی ذخیره می‌شوند که از زمان آخرین نسخه پشتیبان‌گیری تغییر کرده‌اند؛ این نسخه می‌تواند Full یا Incremental قبلی باشد.

مزایا:

• کاهش حجم اطلاعات ذخیره‌شده

• سرعت بیشتر تهیه نسخه پشتیبان

• مصرف کمتر فضای ذخیره‌سازی

معایب:

• فرآیند بازیابی پیچیده‌تر

• وابستگی به نسخه پایه و زنجیره نسخه‌های افزایشی

۳. Differential Backup

در این روش تمام تغییرات ایجادشده از زمان آخرین Full Backup ذخیره می‌شوند.

مزایا:

• بازیابی ساده‌تر از Incremental

• وابستگی کمتر به زنجیره طولانی نسخه‌ها

• سرعت مناسب تهیه نسخه نسبت به Full Backup

معایب:

• افزایش حجم فایل پشتیبان در طول زمان

• مصرف بیشتر فضای ذخیره‌سازی نسبت به Incremental

مقایسه روش‌های مختلف پشتیبان‌گیری

هیچ‌کدام از این روش‌ها به‌تنهایی بهترین انتخاب برای تمام سازمان‌ها نیستند. در بسیاری از زیرساخت‌ها ترکیب Full Backup با نسخه‌های Incremental یا Differential می‌تواند راهکار مناسبی باشد.

استراتژی 3-2-1 در پشتیبان‌گیری چیست؟

یکی از اصول شناخته‌شده در طراحی استراتژی Backup، قانون 3-2-1 است.

این قانون توصیه می‌کند:

• ۳ نسخه از اطلاعات: یک نسخه اصلی و حداقل دو نسخه پشتیبان داشته باشید.

• ۲ نوع رسانه ذخیره‌سازی: نسخه‌ها را روی دو نوع رسانه یا زیرساخت متفاوت نگهداری کنید.

• ۱ نسخه خارج از محل اصلی: حداقل یک نسخه در مکانی جدا از زیرساخت اصلی سازمان قرار دهید.

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

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

به همین دلیل، استفاده از نسخه‌های Offline و Immutable نیز اهمیت دارد.

در مستندات امنیتی Microsoft و CISA نیز بر نگهداری نسخه‌های جداشده از شبکه، رمزنگاری نسخه‌های پشتیبان و آزمایش منظم فرآیند بازیابی تأکید شده است.

 Disaster Recovery

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

چهار رویکرد متداول عبارت‌اند از:

۱. Backup and Restore

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

این روش معمولاً هزینه و پیچیدگی کمتری نسبت به معماری‌های آماده‌به‌کار دارد؛ اما زمان بازیابی آن می‌تواند بیشتر باشد.

مناسب برای:

• سیستم‌های با اهمیت عملیاتی پایین‌تر

• سازمان‌هایی با بودجه محدود

• سرویس‌هایی که چند ساعت توقف را تحمل می‌کنند

۲. Pilot Light

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

هنگام وقوع بحران، سایر منابع موردنیاز ایجاد یا فعال می‌شوند تا سیستم دوباره قابل استفاده شود.

این روش نسبت به Backup and Restore امکان بازیابی سریع‌تری فراهم می‌کند، اما به طراحی و مدیریت دقیق وابستگی‌های زیرساختی نیاز دارد.

۳. Warm Standby

در معماری Warm Standby، یک نسخه کوچک‌تر اما عملیاتی از سیستم در زیرساخت جایگزین فعال است.

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

این روش معمولاً برای سرویس‌هایی مناسب است که زمان توقف محدودی دارند.

۴. Multi-Site Active-Active

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

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

این روش می‌تواند دسترس‌پذیری بالایی ایجاد کند؛ اما پیاده‌سازی آن پیچیده‌تر و پرهزینه‌تر است و مدیریت هماهنگی داده‌ها، تعارض تراکنش‌ها و سازگاری اطلاعات اهمیت زیادی دارد.

مقایسه استراتژی‌های Disaster Recovery

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

AWS نیز این رویکردها را در چارچوب Well-Architected معرفی می‌کند و تأکید دارد که انتخاب استراتژی باید براساس اهداف RTO و RPO انجام شود.

نقش Cloud Backup در حفاظت از اطلاعات سازمان

Cloud Backup به معنای نگهداری نسخه‌های پشتیبان در زیرساخت ذخیره‌سازی ابری است.

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

یکی از مزایای مهم Cloud Backup، امکان نگهداری نسخه پشتیبان در مکانی مستقل از زیرساخت اصلی سازمان است.

این موضوع در شرایطی مانند خرابی فیزیکی مرکز داده یا آسیب دیدن تجهیزات داخلی اهمیت دارد.

مزایای Cloud Backup

• کاهش وابستگی به تجهیزات ذخیره‌سازی داخلی

• امکان نگهداری نسخه‌های پشتیبان در مکان‌های جغرافیایی متفاوت

• قابلیت افزایش ظرفیت ذخیره‌سازی

• امکان خودکارسازی فرآیند پشتیبان‌گیری

• مدیریت بهتر نسخه‌های پشتیبان در زیرساخت‌های توزیع‌شده

چالش‌های Cloud Backup

با وجود مزایا، استفاده از فضای ابری بدون بررسی محدودیت‌ها تصمیم مناسبی نیست.

موارد زیر باید پیش از انتخاب بررسی شوند:

• هزینه انتقال و بازیابی حجم بالای اطلاعات

• سرعت و پایداری ارتباط اینترنتی

• سیاست‌های نگهداری و حذف اطلاعات

• سطح امنیت و رمزنگاری

• محل جغرافیایی نگهداری داده‌ها

• امکان انتقال اطلاعات به سرویس‌دهنده دیگر

• هزینه بازیابی اطلاعات در شرایط اضطراری

همچنین باید توجه داشت که استفاده از Cloud Backup لزوماً به معنای داشتن Disaster Recovery کامل نیست. سازمان همچنان به برنامه مشخصی برای راه‌اندازی مجدد نرم‌افزارها و زیرساخت‌های وابسته نیاز دارد.

برای آشنایی بیشتر با این موضوع می‌توان مقاله «Cloud Computing و مزایای رایانش ابری برای سازمان‌ها» را به‌عنوان محتوای مکمل مطالعه کرد.

چگونه از پایگاه داده‌های سازمانی Backup بگیریم؟

پایگاه داده یکی از مهم‌ترین بخش‌های زیرساخت نرم‌افزارهای سازمانی است.

در بسیاری از سیستم‌ها، اطلاعات مالی، عملیاتی، مشتریان، کاربران و تراکنش‌ها در پایگاه داده نگهداری می‌شوند. به همین دلیل، استراتژی پشتیبان‌گیری از پایگاه داده باید متناسب با نوع Database و میزان تغییر اطلاعات طراحی شود.

برای مثال، در SQL Server روش‌های متداول زیر وجود دارند:

• Full Database Backup: تهیه نسخه کامل از پایگاه داده.

• Differential Backup: ذخیره تغییرات نسبت به آخرین Full Backup.

• Transaction Log Backup: ذخیره تغییرات ثبت‌شده در Transaction Log برای امکان بازیابی تا نقطه زمانی مشخص، در صورت پیکربندی مناسب مدل Recovery و زنجیره Log.

برای یک سیستم مالی پرتراکنش، ترکیب Full Backup، Differential Backup و Transaction Log Backup می‌تواند امکان کنترل دقیق‌تری بر نقاط بازیابی فراهم کند.

البته زمان‌بندی این عملیات باید بر اساس RPO موردنیاز، حجم تراکنش‌ها و ظرفیت زیرساخت تعیین شود.

نکات مهم در پشتیبان‌گیری از Database

1. نسخه‌های پشتیبان را روی همان دیسک یا سرور اصلی نگهداری نکنید.

2. برای فایل‌های پشتیبان رمزنگاری و کنترل دسترسی مناسب در نظر بگیرید.

3. از وضعیت اجرای موفق عملیات Backup گزارش تهیه کنید.

4. نسخه‌های پشتیبان را به‌صورت دوره‌ای آزمایش کنید.

5. علاوه بر Database، فایل‌های مرتبط با نرم‌افزار را نیز در برنامه بازیابی قرار دهید.

6. زنجیره Transaction Log را در صورت استفاده از این روش به‌درستی مدیریت کنید.

7. وابستگی‌های نرم‌افزار به سرویس‌ها، فایل‌ها و تنظیمات دیگر را مستند کنید.

نکته مهم: موفقیت عملیات Backup به معنای تضمین موفقیت Restore نیست. تنها زمانی می‌توان به یک نسخه پشتیبان اعتماد کرد که فرآیند بازیابی آن نیز آزمایش شده باشد.

نقش Immutable Backup در مقابله با باج‌افزارها

یکی از تهدیدهای جدی برای اطلاعات سازمانی، حملات باج‌افزاری است.

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

Immutable Backup راهکاری است که در آن نسخه پشتیبان برای یک بازه زمانی مشخص در برابر تغییر یا حذف محافظت می‌شود.

این قابلیت می‌تواند از طریق فناوری‌های ذخیره‌سازی تغییرناپذیر یا سیاست‌های قفل‌گذاری نسخه‌های پشتیبان پیاده‌سازی شود.

مزایای آن عبارت‌اند از:

• کاهش احتمال حذف عمدی نسخه‌های پشتیبان

• محدود کردن تأثیر دسترسی غیرمجاز

• افزایش امکان بازیابی اطلاعات پس از حمله

• محافظت بهتر از نسخه‌های تاریخی اطلاعات

البته Immutable Backup به‌تنهایی تمام ریسک‌های امنیتی را برطرف نمی‌کند. کنترل دسترسی، احراز هویت چندمرحله‌ای، جداسازی شبکه و آزمایش فرآیند بازیابی همچنان ضروری هستند.

چگونه یک برنامه Disaster Recovery برای سازمان طراحی کنیم؟

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

مراحل زیر می‌توانند چارچوب مناسبی برای طراحی این برنامه باشند.

مرحله اول: شناسایی دارایی‌های اطلاعاتی و سیستم‌های حیاتی

در ابتدا باید تمام سیستم‌ها و اطلاعات سازمان شناسایی شوند.

برای مثال:

• نرم‌افزار مالی و حسابداری

• سیستم مدیریت مشتریان

• نرم‌افزارهای عملیاتی

• سرورهای پایگاه داده

• سامانه‌های منابع انسانی

• سرویس‌های احراز هویت

• فایل‌های اشتراکی سازمان

در این مرحله باید مشخص شود هر سیستم چه اطلاعاتی نگهداری می‌کند و به چه سرویس‌هایی وابسته است.

مرحله دوم: انجام تحلیل تأثیر کسب‌وکار (BIA)

Business Impact Analysis یا تحلیل تأثیر کسب‌وکار مشخص می‌کند توقف هر سیستم چه پیامدهایی برای سازمان دارد.

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

در این مرحله باید موارد زیر مشخص شوند:

• هزینه توقف سیستم

• اهمیت اطلاعات

• وابستگی سایر فرآیندها به سیستم

• زمان قابل‌تحمل برای اختلال

• اولویت بازیابی

مرحله سوم: تعیین RTO و RPO

پس از شناسایی سیستم‌های حیاتی، باید برای هرکدام اهداف بازیابی تعیین شوند.

نمونه زیر صرفاً فرضی است:

این اعداد باید براساس نیاز واقعی کسب‌وکار، حجم اطلاعات و توان فنی سازمان تعیین شوند.

مرحله چهارم: انتخاب روش پشتیبان‌گیری

براساس RPO و اهمیت اطلاعات، روش مناسب انتخاب می‌شود.

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

مرحله پنجم: طراحی زیرساخت بازیابی

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

این زیرساخت ممکن است شامل موارد زیر باشد:

• سرور جایگزین

• فضای ذخیره‌سازی مستقل

• زیرساخت ابری

• پایگاه داده ثانویه

• تنظیمات شبکه و دسترسی

• نسخه‌های آماده استقرار نرم‌افزار

مرحله ششم: مستندسازی فرآیند بازیابی

تمام مراحل باید مستند شوند.

برای مثال، مشخص باشد:

• چه کسی مسئول اعلام وضعیت بحران است؟

• چه کسی فرآیند بازیابی را آغاز می‌کند؟

• اطلاعات از کدام نسخه پشتیبان بازیابی می‌شوند؟

• اولویت راه‌اندازی سرویس‌ها چیست؟

• چگونه صحت اطلاعات بررسی می‌شود؟

• چه زمانی کاربران می‌توانند مجدداً از سیستم استفاده کنند؟

این مستندات باید به شکلی تهیه شوند که در شرایط اضطراری نیز قابل استفاده باشند.

مرحله هفتم: آزمایش و به‌روزرسانی برنامه

برنامه Disaster Recovery بدون آزمایش عملی، صرفاً یک سند مستنداتی است.

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

در این آزمایش‌ها باید بررسی شود:

• آیا نسخه پشتیبان قابل بازیابی است؟

• آیا اطلاعات بازیابی‌شده سالم هستند؟

• آیا سیستم در زمان هدف‌گذاری‌شده فعال می‌شود؟

• آیا ارتباط میان سرویس‌ها برقرار است؟

• آیا کاربران می‌توانند عملیات اصلی خود را انجام دهند؟

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

یک سناریوی نمونه: خرابی زیرساخت نرم‌افزار مالی یک شرکت

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

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

در اثر خرابی سخت‌افزاری، سرور اصلی از دسترس خارج می‌شود.

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

اما اگر برنامه Backup و Disaster Recovery مناسبی طراحی شده باشد، فرآیند بازیابی می‌تواند به شکل زیر انجام شود:

1. تیم IT خرابی زیرساخت اصلی را شناسایی و وضعیت بحران را اعلام می‌کند.

2. دسترسی به نسخه‌های پشتیبان مستقل بررسی می‌شود.

3. سرور جایگزین یا زیرساخت بازیابی آماده می‌شود.

4. پایگاه داده از آخرین نسخه سالم بازیابی می‌شود.

5. در صورت وجود Transaction Logهای معتبر، اطلاعات تا نقطه بازیابی موردنظر بازگردانده می‌شوند.

6. نرم‌افزار و سرویس‌های وابسته راه‌اندازی می‌شوند.

7. صحت اطلاعات مالی و امکان ثبت تراکنش جدید بررسی می‌شود.

8. پس از تأیید تیم فنی و مسئولان کسب‌وکار، دسترسی کاربران برقرار می‌شود.

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

اشتباهات رایج در Backup و Disaster Recovery

حتی سازمان‌هایی که از ابزارهای پشتیبان‌گیری استفاده می‌کنند ممکن است در زمان بحران با مشکلات جدی مواجه شوند.

مهم‌ترین اشتباهات عبارت‌اند از:

۱. نگهداری تمام نسخه‌های پشتیبان در یک مکان

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

۲. آزمایش نکردن فرآیند Restore

ممکن است عملیات Backup با موفقیت انجام شود، اما فایل پشتیبان خراب باشد یا اطلاعات لازم برای بازیابی کامل سیستم در دسترس نباشد.

۳. نداشتن اولویت بازیابی سیستم‌ها

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

باید ابتدا سرویس‌هایی بازیابی شوند که بیشترین اهمیت را برای ادامه فعالیت کسب‌وکار دارند.

۴. وابستگی بیش از حد به یک نیروی متخصص

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

مستندسازی و آموزش نیروهای جایگزین ضروری است.

۵. نادیده گرفتن تنظیمات و وابستگی‌های نرم‌افزار

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

۶. بی‌توجهی به امنیت نسخه‌های پشتیبان

نسخه‌های Backup نیز باید در برابر دسترسی غیرمجاز، تغییر و حذف محافظت شوند.

۷. نداشتن برنامه ارتباطی هنگام بحران

در زمان اختلال، واحد IT باید بتواند وضعیت سرویس‌ها، زمان تقریبی بازیابی و اقدامات لازم را به مدیران و کاربران اطلاع دهد.

نبود برنامه ارتباطی می‌تواند باعث سردرگمی و تصمیم‌گیری‌های ناهماهنگ شود.

چگونه هزینه Backup و Disaster Recovery را مدیریت کنیم؟

طراحی یک راهکار بازیابی اطلاعات به معنای انتخاب گران‌ترین زیرساخت نیست.

سازمان باید میان هزینه حفاظت از اطلاعات و هزینه احتمالی توقف کسب‌وکار تعادل ایجاد کند.

هزینه‌های اصلی این راهکار معمولاً شامل موارد زیر هستند:

برای مدیریت هزینه، بهتر است سازمان ابتدا سیستم‌های حیاتی خود را شناسایی کند.

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

بنابراین تخصیص یکسان منابع به تمام سیستم‌ها نه اقتصادی است و نه لزوماً منطقی.

معیار اصلی باید میزان اهمیت هر سیستم برای کسب‌وکار و هزینه ناشی از توقف آن باشد.

جمع‌بندی: چرا Backup بدون Disaster Recovery کافی نیست؟

Backup و Disaster Recovery دو بخش جدایی‌ناپذیر از مدیریت ریسک فناوری اطلاعات هستند.

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

یک استراتژی مناسب باید شامل این موارد باشد:

• شناسایی اطلاعات و سیستم‌های حیاتی

• تعیین RTO و RPO

• انتخاب روش مناسب پشتیبان‌گیری

• نگهداری نسخه‌های پشتیبان مستقل و امن

• طراحی زیرساخت بازیابی

• مستندسازی مسئولیت‌ها و مراحل اجرا

• آزمایش دوره‌ای بازیابی اطلاعات و سرویس‌ها

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

FAQ | سوالات متداول

۱. آیا داشتن Backup برای محافظت از اطلاعات سازمان کافی است؟

خیر. Backup امکان بازیابی اطلاعات را فراهم می‌کند، اما برای بازگرداندن کامل سیستم به زیرساخت، نرم‌افزارها، تنظیمات و برنامه بازیابی بحران نیاز است. به همین دلیل Backup باید بخشی از یک برنامه جامع Disaster Recovery باشد.

۲. هر چند وقت یک‌بار باید از اطلاعات سازمان Backup گرفت؟

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

۳. تفاوت Backup و Replication چیست؟

Backup نسخه‌ای از اطلاعات را برای بازیابی در آینده نگهداری می‌کند. Replication اطلاعات را میان دو یا چند سیستم همگام یا تکثیر می‌کند تا دسترسی به داده‌ها در محیط جایگزین امکان‌پذیر باشد.

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

۴. آیا Cloud Backup امنیت بیشتری نسبت به Backup محلی دارد؟

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

۵. Immutable Backup چه تفاوتی با Backup معمولی دارد؟

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

۶. چگونه می‌توان مطمئن شد نسخه پشتیبان قابل بازیابی است؟

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

۷. آیا نرم‌افزارهای سازمانی باید برنامه Disaster Recovery اختصاصی داشته باشند؟

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

CTA | بررسی زیرساخت نرم‌افزاری سازمان

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

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

در گارنت می‌توانید برای بررسی نیازهای نرم‌افزاری و معماری سیستم‌های سازمانی خود گفت‌وگو کنید و مسیر مناسب‌تری برای توسعه و نگهداری راهکارهای نرم‌افزاری انتخاب کنید.

وب‌سایت گارنت