در زیرساخت فناوری اطلاعات سازمان ها، حفظ دسترس پذیری سرویس ها و جلوگیری از توقف کسب وکار اهمیت زیادی دارد. خرابی تجهیزات، قطعی برق یا ارتباطات، خطای انسانی، حملات سایبری و حتی حوادث فیزیکی می توانند باعث شوند دیتاسنتر یا زیرساخت اصلی سازمان برای مدتی از دسترس خارج شود. به همین دلیل، سازمان ها معمولاً در کنار سایت اصلی (Primary Site) از زیرساخت های دیگری مانند سایت پشتیبان (Backup Site) و بازیابی بحران یا سایت بحران (Disaster Recovery Site) استفاده می کنند. این سه مفهوم گاهی به اشتباه به جای یکدیگر استفاده می شوند، در حالی که هدف و نحوه عملکرد آن ها متفاوت است. سایت اصلی محل اجرای عادی سرویس هاست، سایت پشتیبان بیشتر بر حفاظت و نگهداری نسخه های قابل بازیابی از داده ها تمرکز دارد و سایت بحران برای ادامه یا بازیابی سرویس های حیاتی هنگام از دسترس خارج شدن سایت اصلی طراحی می شود.
سایت اصلی یا Primary Site چیست؟
سایت اصلی (Primary Site) محیطی است که سرویس های اصلی و عملیاتی سازمان در شرایط عادی روی آن اجرا می شوند. کاربران، شعب، سامانه ها و سرویس های مختلف سازمان معمولاً به زیرساخت این سایت متصل هستند. برای مثال، ممکن است سرورها، ماشین های مجازی، پایگاه های داده، تجهیزات شبکه و امنیت، Storageها و سایر اجزای اصلی زیرساخت یک سازمان در دیتاسنتر مرکزی آن قرار داشته باشند. به همین دلیل، اقداماتی مانند نوسازی و مجازی سازی دیتاسنتر می توانند نقش مهمی در بهبود کارایی، مدیریت منابع و پایداری زیرساخت سایت اصلی داشته باشند. تا زمانی که شرایط عادی است، بار اصلی پردازشی و سرویس دهی روی همین سایت قرار دارد. به زبان ساده، Primary Site محل اصلی فعالیت سرویس های IT سازمان است. اگر این سایت دچار اختلال جدی شود و جایگزینی برای آن وجود نداشته باشد، ممکن است بخشی از خدمات یا حتی کل سرویس های سازمان متوقف شوند.
برای مثال، ممکن است سرورها، ماشین های مجازی، پایگاه های داده، تجهیزات شبکه و امنیت، Storageها و سایر اجزای اصلی زیرساخت یک سازمان در دیتاسنتر مرکزی آن قرار داشته باشند. با افزایش حجم داده ها، تعداد سرویس ها و نیاز سازمان به دسترس پذیری بالاتر، زیرساخت سایت اصلی نیز باید متناسب با این نیازها توسعه پیدا کند. همین موضوع نشان می دهد چرا دیتاسنترهای قدیمی دیگر پاسخگوی نیاز سازمان ها نیستند و در بسیاری از مجموعه ها، نوسازی زیرساخت به یک ضرورت تبدیل شده است.
سایت پشتیبان یا Backup Site چیست؟
سایت پشتیبان (Backup Site) محیطی جدا از زیرساخت اصلی است که برای نگهداری نسخه های پشتیبان داده ها و فراهم کردن امکان بازیابی آن ها مورد استفاده قرار می گیرد. فرض کنید اطلاعات سازمان در سایت اصلی قرار دارد و هر شب از ماشین های مجازی، Databaseها یا فایل های مهم Backup گرفته می شود. اگر تمام این نسخه های پشتیبان نیز در همان دیتاسنتر اصلی نگهداری شوند، وقوع یک حادثه گسترده می تواند هم اطلاعات اصلی و هم Backupها را تحت تأثیر قرار دهد.
به همین دلیل یکی از اصول مهم طراحی Backup، نگهداری حداقل یک نسخه در یک موقعیت یا Failure Domain مستقل است. سایت پشتیبان می تواند شامل Backup Repository، فضای ذخیره سازی، Object Storage، Tape یا سایر زیرساخت های مورد نیاز برای نگهداری نسخه های پشتیبان باشد. نکته مهم این است که وجود Backup Site الزاماً به معنی امکان ادامه فوری سرویس دهی نیست. ممکن است اطلاعات سازمان در این سایت کاملاً سالم باشد، اما برای راه اندازی مجدد سرویس ها نیاز به Restore اطلاعات و آماده سازی زیرساخت وجود داشته باشد.
سایت بحران یا Disaster Recovery Site چیست؟
سایت بازیابی بحران (Disaster Recovery Site یا DR Site) زیرساختی است که برای بازیابی سرویس های حیاتی سازمان در صورت وقوع یک اختلال یا حادثه جدی در سایت اصلی طراحی می شود. هدف DR Site فقط نگهداری اطلاعات نیست؛ بلکه باید امکان بازیابی سرویس ها و ادامه فعالیت سازمان را نیز فراهم کند. برای مثال، اگر دیتاسنتر اصلی یک سازمان به دلیل خرابی گسترده زیرساخت، آتش سوزی، اختلال طولانی برق یا شبکه یا حادثه دیگری از دسترس خارج شود، سرویس های مشخص شده در برنامه Disaster Recovery می توانند در سایت بحران راه اندازی شوند. بسته به معماری، اطلاعات و ماشین های مجازی ممکن است به صورت دوره ای یا نزدیک به لحظه بین سایت اصلی و DR Site Replicate شوند. بنابراین تفاوت اساسی سایت بحران با سایت پشتیبان این است که: Backup Site عمدتاً برای حفاظت و بازیابی داده طراحی می شود، اما DR Site برای بازیابی سرویس و ادامه فعالیت کسب وکار طراحی شده است.
تفاوت سایت اصلی، سایت پشتیبان و سایت بحران در چیست؟
مهم ترین تفاوت این سه سایت را می توان در هدف آن ها مشاهده کرد.
| معیار | سایت اصلی | سایت پشتیبان | سایت بحران |
| نام انگلیسی | Primary Site | Backup Site | Disaster Recovery Site |
| هدف اصلی | ارائه سرویس های عملیاتی | حفاظت و نگهداری نسخه های پشتیبان | بازیابی و ادامه سرویس های حیاتی |
| وضعیت استفاده | استفاده روزمره | هنگام Backup و Restore | هنگام بحران، مانور یا Failover |
| نگهداری داده | اطلاعات Production | نسخه های Backup | نسخه قابل بازیابی یا Replicate شده سرویس ها |
| اجرای سرویس | بله | الزاماً خیر | بله، برای سرویس های تعریف شده |
| نیاز به زیرساخت پردازشی | بله | الزاماً خیر | معمولاً بله |
| تمرکز اصلی | عملیات روزمره | Data Protection | Service Recovery |
| زمان بازیابی | موضوع اصلی آن نیست | وابسته به Restore | بر اساس RTO طراحی می شود |
بنابراین نباید Backup Site و DR Site را مترادف در نظر گرفت.
تفاوت Backup Site و DR Site چیست؟
این یکی از مهم ترین ابهام ها در طراحی زیرساخت سازمانی است. فرض کنید دیتاسنتر اصلی یک شرکت به طور کامل از دسترس خارج شده است. در Backup Site ممکن است آخرین نسخه Backup اطلاعات موجود باشد. برای بازگرداندن سرویس، ابتدا باید زیرساخت مناسب فراهم شود، Backup بازیابی شود، ماشین ها یا Databaseها Restore شوند، تنظیمات شبکه انجام شود و در نهایت سرویس در اختیار کاربران قرار گیرد.
اما در یک DR Site مناسب، بخشی از این زیرساخت از قبل آماده است. سرورها، Storage، شبکه، ارتباطات و نسخه ای از Workloadهای حیاتی می توانند آماده باشند تا مطابق Runbook و برنامه DR فعال شوند. بنابراین سؤال اصلی این نیست که: آیا نسخه دیگری از اطلاعات داریم؟ بلکه در DR سؤال این است: اگر سایت اصلی همین الان از دسترس خارج شود، سرویس حیاتی را در چه مدت و با چه میزان از دست رفتن داده می توانیم دوباره در اختیار کاربران قرار دهیم؟ این تفاوت، مرز اصلی میان Backup و Disaster Recovery است.
آیا داشتن Backup به معنی داشتن Disaster Recovery است؟
خیر.Backup یکی از اجزای مهم استراتژی بازیابی اطلاعات است، اما به تنهایی یک راهکار کامل Disaster Recovery محسوب نمی شود. ممکن است سازمان هر روز Backup سالم داشته باشد، اما در زمان بحران برای تهیه سرور، Storage، شبکه، تنظیمات امنیتی، Restore اطلاعات و راه اندازی سرویس چند روز زمان نیاز داشته باشد. در مقابل، یک راهکار DR بر کل فرآیند بازیابی سرویس تمرکز دارد؛ از داده و زیرساخت گرفته تا ترتیب راه اندازی سرویس ها، وابستگی ها، شبکه، DNS، دسترسی کاربران و فرآیند Failover و Failback.
آیا DR Site جای Backup را می گیرد؟
خیر. این تصور نیز می تواند خطرناک باشد. Replication و DR معمولاً آخرین وضعیت داده یا سرویس را به محیط دیگری منتقل می کنند. اگر اطلاعات در سایت اصلی به دلیل خطای انسانی، حذف اشتباه، خرابی منطقی یا برخی حملات سایبری آسیب ببیند، این تغییر ممکن است به محیط DR نیز منتقل شود. Backup امکان بازگشت به نسخه های قبلی اطلاعات را فراهم می کند؛ در حالی که DR عمدتاً برای بازگرداندن سرویس پس از اختلال طراحی شده است. به همین دلیل در معماری مناسب، Backup و Disaster Recovery مکمل یکدیگر هستند، نه جایگزین یکدیگر.
RPO و RTO چه ارتباطی با سایت بحران دارند؟
طراحی DR بدون مشخص کردن دو شاخص مهم RPO و RTO کامل نیست.
- Recovery Point Objective مشخص می کند سازمان حداکثر چه مقدار از داده های اخیر را می تواند در یک حادثه از دست بدهد.برای مثال، اگر RPO یک سامانه ۱۵ دقیقه باشد، معماری بازیابی باید به شکلی طراحی شود که در شرایط مورد نظر، از دست رفتن داده از هدف تعیین شده فراتر نرود.
- RTO چیست؟ Recovery Time Objectiveمشخص می کند سرویس پس از اختلال باید حداکثر در چه بازه هدفی بازیابی شود.برای مثال، اگر RTO سامانه مالی دو ساعت تعیین شده باشد، فرآیند DR باید با هدف بازگرداندن آن سرویس در این بازه طراحی شود.
RPO بیشتر با میزان از دست رفتن قابل قبول داده و RTO با زمان قابل قبول برای بازیابی سرویس ارتباط دارد.
آیا همه سرویس ها باید در سایت بحران قرار بگیرند؟
الزاماً خیر. یکی از اشتباهات رایج این است که تصور شود DR Site باید نسخه کاملاً مشابهی از تمام زیرساخت سایت اصلی باشد. در طراحی حرفه ای ابتدا باید مشخص شود کدام فرآیندها و سرویس ها برای کسب وکار حیاتی هستند. این موضوع معمولاً در فرآیندی مانند Business Impact Analysis یا BIA بررسی می شود. ممکن است سامانه فروش یا Core Business سازمان نیازمند RTO بسیار کوتاه باشد، اما یک سامانه آرشیوی بتواند چند ساعت یا حتی بیشتر از دسترس خارج بماند. در نتیجه می توان برای سرویس های مختلف، سطح متفاوتی از حفاظت و بازیابی تعریف کرد.
Hot Site، Warm Site و Cold Site چه تفاوتی دارند؟
DR Siteها از نظر میزان آمادگی معمولاً در سطوح مختلف طراحی می شوند.
- Hot Site
Hot Site زیرساختی با سطح آمادگی بالا است که بخش قابل توجهی از منابع مورد نیاز برای اجرای سرویس ها از قبل در آن آماده است و داده ها نیز می توانند با فاصله زمانی بسیار کمی Replicate شوند. این مدل معمولاً امکان بازیابی سریع تری فراهم می کند، اما هزینه طراحی و نگهداری آن نیز بیشتر است.
- Warm Site
در Warm Site بخشی از زیرساخت آماده است، اما برای فعال سازی کامل سرویس ها ممکن است نیاز به انجام برخی عملیات، افزایش منابع یا بازیابی بخشی از اطلاعات وجود داشته باشد. این مدل معمولاً میان هزینه و زمان بازیابی تعادل ایجاد می کند.
- Cold Site
Cold Site معمولاً فضای فیزیکی، ارتباطات یا بخشی از زیرساخت پایه را فراهم می کند، اما سیستم ها و داده ها برای سرویس دهی فوری آماده نیستند. در نتیجه زمان بازیابی بیشتر است، اما هزینه نگهداری آن معمولاً پایین تر خواهد بود. انتخاب میان این مدل ها باید بر اساس RTO، RPO، اهمیت سرویس ها، ریسک های سازمان و بودجه انجام شود.
فاصله سایت اصلی و سایت بحران چقدر باید باشد؟
برای این سؤال یک عدد ثابت و مناسب برای تمام سازمان ها وجود ندارد. هدف اصلی این است که Primary Site و DR Site تا حد قابل قبول در معرض ریسک مشترک قرار نگیرند. برای مثال اگر هر دو سایت از یک مسیر ارتباطی، یک منبع برق، یک زیرساخت مشترک یا یک محدوده جغرافیایی با ریسک یکسان استفاده کنند، یک حادثه می تواند هر دو را هم زمان تحت تأثیر قرار دهد. از طرف دیگر، افزایش فاصله نیز می تواند روی هزینه ارتباطات، Latency، Replication و پیچیدگی عملیات اثر بگذارد. بنابراین فاصله مناسب باید با ارزیابی ریسک و نیازهای فنی تعیین شود، نه بر اساس یک عدد ثابت.
Failover و Failback چیست؟
هنگامی که سرویس از Primary Site به DR Site منتقل می شود، این فرآیند معمولاً Failover نامیده می شود. پس از رفع مشکل سایت اصلی، ممکن است سازمان تصمیم بگیرد سرویس ها را دوباره به محیط اصلی بازگرداند. این فرآیند Failback نام دارد. هر دو فرآیند باید از قبل طراحی، مستند و آزمایش شده باشند. داشتن تجهیزات در سایت بحران بدون Runbook مشخص برای Failover و Failback، تضمینی برای بازیابی موفق سرویس نیست.
آیا داشتن DR Site بدون مانور دوره ای کافی است؟
خیر. یکی از مهم ترین بخش های Disaster Recovery، آزمایش و مانور دوره ای DR است. ممکن است Replication بدون خطا انجام شود، اما هنگام Failover مشخص شود یک سرویس به DNS، Active Directory، Firewall Rule، Certificate، Database یا سرویس دیگری وابسته بوده که در طراحی DR در نظر گرفته نشده است. مانور DR کمک می کند سازمان قبل از وقوع بحران واقعی، این وابستگی ها و مشکلات را شناسایی کند. در چنین مانوری باید مواردی مانند زمان واقعی بازیابی، صحت اطلاعات، عملکرد سرویس ها، دسترسی کاربران، وابستگی سامانه ها و فرآیند بازگشت به سایت اصلی بررسی شود.
یک معماری مناسب چگونه از هر سه سایت استفاده می کند؟
در یک سناریوی ساده می توان معماری را به این شکل در نظر گرفت:
- سایت اصلی → اجرای سرویس های اصلی سازمان
- سایت پشتیبان → نگهداری نسخه های مستقل و قابل بازیابی اطلاعات
- سایت بحران → آماده سازی زیرساخت لازم برای بازیابی سرویس های حیاتی هنگام بحران
برای مثال، یک سازمان ممکن است ماشین های مجازی و Databaseهای اصلی خود را در Primary Site اجرا کند، نسخه های Backup را در یک موقعیت مستقل نگهداری کند و هم زمان Workloadهای حیاتی را به DR Site Replicate کند. در صورت خرابی یک فایل یا حذف اشتباه اطلاعات، Backup مورد استفاده قرار می گیرد؛ اما اگر کل سایت اصلی از دسترس خارج شود، برنامه Disaster Recovery فعال شده و سرویس های حیاتی در DR Site راه اندازی می شوند.
آیا سازمان ها به سایت اصلی، سایت پشتیبان و سایت بحران نیاز دارند؟
پاسخ به اندازه سازمان وابسته نیست؛ بیشتر به اهمیت داده ها و هزینه توقف سرویس ها بستگی دارد. برای یک سازمان کوچک که چند ساعت توقف تأثیر جدی بر فعالیت آن ندارد، ممکن است Backup خارج از سایت کافی باشد. اما در بانک ها، شرکت های بیمه، مراکز مالی، سازمان های دولتی، اپراتورها، مراکز درمانی و کسب وکارهایی که سامانه های آنلاین حیاتی دارند، توقف چندساعته یک سرویس می تواند خسارت قابل توجهی ایجاد کند.
بنابراین قبل از طراحی DR باید مشخص شود:
- کدام سرویس ها حیاتی هستند؟
- هر سرویس چه RTO و RPOای دارد؟
- توقف هر سرویس چه اثری بر کسب وکار دارد؟
- چه ریسک هایی می توانند سایت اصلی را از دسترس خارج کنند؟
- چه زیرساختی برای بازیابی هر سرویس لازم است؟
پاسخ به این سؤالات مشخص می کند سازمان به چه سطحی از Backup و Disaster Recovery نیاز دارد.
اشتباهات رایج در طراحی سایت پشتیبان و سایت بحران
یکی از مهم ترین اشتباهات، یکسان دانستن Backup با Disaster Recovery است. داشتن چند نسخه Backup به این معنی نیست که سازمان می تواند پس از از دست رفتن دیتاسنتر، سرویس های خود را در زمان مورد انتظار بازیابی کند. قرار دادن سایت اصلی و DR در یک Failure Domain مشترک، مشخص نکردن RTO و RPO، نادیده گرفتن وابستگی سرویس ها، نداشتن Runbook، Replication بدون Backup مستقل و انجام ندادن مانورهای دوره ای نیز از مشکلات متداول هستند. در نهایت، DR Site زمانی ارزش واقعی دارد که قابلیت بازیابی آن در عمل آزمایش شده باشد.
جمع بندی
سایت اصلی، سایت پشتیبان و سایت بحران سه بخش با اهداف متفاوت در معماری تداوم سرویس سازمان هستند. Primary Site محل اجرای عادی سرویس هاست، Backup Site برای حفاظت و بازیابی اطلاعات استفاده می شود و Disaster Recovery Site برای بازیابی سرویس های حیاتی در زمان از دسترس خارج شدن سایت اصلی طراحی می شود. تفاوت کلیدی Backup و DR نیز در همین موضوع است: Backup پاسخ می دهد چگونه اطلاعات را برگردانیم؟، در حالی که Disaster Recovery به سؤال بزرگ تری پاسخ می دهد: چگونه پس از یک حادثه، سرویس حیاتی سازمان را دوباره عملیاتی کنیم؟
به همین دلیل، سازمان هایی که توقف سرویس برای آن ها هزینه یا ریسک قابل توجهی ایجاد می کند، باید Backup، Disaster Recovery، RTO، RPO و مانورهای دوره ای را به عنوان اجزای یک برنامه یکپارچه برای تداوم کسب وکار در نظر بگیرند.
سوالات متداول درباره تفاوت سایت اصلی، سایت پشتیبان و سایت بحران
- تفاوت سایت پشتیبان و سایت بحران چیست؟
سایت پشتیبان عمدتاً برای نگهداری نسخه های Backup و بازیابی اطلاعات استفاده می شود؛ اما سایت بحران زیرساختی برای بازیابی و اجرای سرویس های حیاتی در صورت از دسترس خارج شدن سایت اصلی است. - آیا Backup Site همان DR Site است؟
خیر. Backup Site می تواند فقط محل نگهداری Backup باشد و الزاماً توانایی اجرای سرویس ها را ندارد. DR Site برای بازیابی سرویس ها طراحی می شود. - آیا داشتن DR Site باعث می شود دیگر به Backup نیاز نداشته باشیم؟
خیر. Replication و DR جای Backup را نمی گیرند. خرابی منطقی، حذف اطلاعات یا برخی تغییرات مخرب ممکن است به محیط DR نیز منتقل شوند؛ بنابراین نسخه های Backup مستقل همچنان ضروری هستند. - تفاوت Primary Site و DR Site چیست؟
Primary Site محل اجرای سرویس ها در شرایط عادی است. DR Site زمانی مورد استفاده قرار می گیرد که سرویس های سایت اصلی به دلیل حادثه یا اختلال جدی قابل ارائه نباشند یا هنگام مانور DR نیاز به آزمایش فرآیند بازیابی وجود داشته باشد. - مهم ترین معیار طراحی سایت بحران چیست؟
RTO و RPO از مهم ترین ورودی های طراحی هستند، اما تنها معیارها نیستند. اهمیت سرویس، وابستگی های فنی، BIA، ریسک های مشترک، ظرفیت زیرساخت و فرآیند Failover و Failback نیز باید بررسی شوند. - سایت بحران باید چه فاصله ای از سایت اصلی داشته باشد؟
عدد ثابتی برای تمام سازمان ها وجود ندارد. فاصله باید به اندازه ای باشد که احتمال تأثیر یک حادثه مشترک بر هر دو سایت کاهش یابد و در عین حال الزامات ارتباطی، Latency، Replication، هزینه و RPO سازمان نیز رعایت شود. - آیا DR Site باید دقیقاً مشابه سایت اصلی باشد؟
خیر. ظرفیت و معماری DR Site باید بر اساس سرویس هایی که قرار است در شرایط بحران بازیابی شوند و RTO/RPO آن ها طراحی شود. در بسیاری از سازمان ها فقط سرویس های حیاتی در DR با ظرفیت کامل یا مورد نیاز پوشش داده می شوند.
