تداوم کسب‌وکار
وابستگی سامانه‌ها، اثر قطعی و اولویت بازگشت هر سرویس را مشخص کنید.
تداوم کسب‌وکار سازمانی · Disaster Recovery
بازیابی از بحران تداوم سرویس‌های سازمان شما
راهکار Disaster Recovery آراد، سایت پشتیبان، تکثیر داده و برنامهٔ بازگردانی سرویس‌ها را برای زیرساخت سازمان شما کنار هم قرار می‌دهد. معماری بازیابی و اهداف RPO/RTO متناسب با حساسیت سامانه‌ها و مقیاس شرکت طراحی می‌شوند.
از اختلال تا بازگشت سرویسنمای مفهومی DR؛ وضعیت زنده نیست
کاربران و برنامه‌ها
سایت اصلیدر حال سرویس‌دهی
سایت پشتیبان آرادآمادهٔ بازیابی
Replication۱. تکثیر داده به سایت پشتیبان
سایت اصلی پاسخ می‌دهد؛ تغییرات داده برای آماده‌بودن محیط بازیابی به سایت پشتیبان منتقل می‌شوند.
RPO · بازهٔ مجاز از دست رفتن دادهRTO · زمان هدف بازگشت سرویس
Disaster Recovery؛ آمادگی برای بازگشت به سرویس
خرابی دیتاسنتر، خطای انسانی یا حادثهٔ سایبری می‌تواند فعالیت سازمان را متوقف کند. برنامهٔ DR مشخص می‌کند کدام سرویس‌ها، با چه اولویتی، روی کدام زیرساخت و در چه زمانی بازیابی شوند.
سایت پشتیبان مستقل
ظرفیت پردازش، ذخیره‌سازی و شبکهٔ مقصد را متناسب با سناریوی بحران طراحی کنید.
بازیابی قابل آزمون
موفقیت طرح با تست سلامت برنامه و داده، دسترسی کاربران و ثبت زمان بازیابی سنجیده می‌شود.
آمادگی عملیاتی، فراتر از نگه‌داری یک نسخهٔ بکاپ
تداوم عملیات سازمان
برای خرابی دیتاسنتر، خطای انسانی و رخداد سایبری، مسیر جایگزین و مسئول اجرای آن را از قبل مشخص کنید.
کاهش زمان توقف
ظرفیت آمادهٔ مقصد و ترتیب راه‌اندازی سرویس‌ها، مسیر بازیابی را قابل برنامه‌ریزی و قابل سنجش می‌کنند.
کنترل بازهٔ از دست رفتن داده
تناوب Replication و نقاط بازیابی با حساسیت داده و هدف RPO هر سامانه هماهنگ می‌شوند.
استفاده از محیط موجود
نسخه‌های VMware، ساختار شبکه و ابزارهای فعلی بررسی می‌شوند تا دامنهٔ تغییرات و پیش‌نیازهای اتصال روشن باشد.
مدیریت هزینهٔ سایت دوم
منابع مقصد، فضای نسخه‌ها و ارتباط بین سایت‌ها در یک طرح ظرفیت بررسی می‌شوند؛ مقایسهٔ هزینه با ساخت سایت دوم بر مبنای محیط واقعی انجام می‌شود.
مسئولیت روشن در بحران
سطح پشتیبانی، امکان پوشش ۲۴×۷، مسیر اعلام حادثه و اختیار فعال‌سازی بازیابی باید در قرارداد و Runbook تعیین شوند.
RPO و RTO؛ دو تصمیم متفاوت برای یک کسب‌وکار
چه بازه‌ای از داده می‌تواند از دست برود؟
فاصلهٔ آخرین نقطهٔ قابل بازیابی تا زمان حادثه، مبنای بررسی RPO است. نرخ تغییر داده، ظرفیت لینک و سیاست Replication بر آن اثر دارند.
نقطهٔ بازیابیوقوع حادثه
بازگشت سرویس چقدر می‌تواند طول بکشد؟
زمان هدف برای بازگرداندن سرویس پس از اختلال است؛ راه‌اندازی ماشین کافی نیست و سلامت برنامه، شبکه و دسترسی کاربران نیز باید آزموده شوند.
وقوع حادثهبازگشت سرویس
اجزای یک طرح بازیابی سازمانی
طراحی براساس RPO و RTO
هدف بازیابی هر سامانه با تحلیل حساسیت داده، هزینهٔ توقف و منابع موردنیاز تعیین می‌شود.
تکثیر داده بین دو سایت
Replication و سیاست نگه‌داری نسخه‌ها برای انتقال داده از سایت اصلی به مقصد پشتیبان طراحی می‌شوند.
Failover و Failback
مراحل انتقال سرویس به سایت پشتیبان و بازگشت کنترل‌شده به سایت اصلی در برنامهٔ اجرایی تعریف می‌شوند.
مانور بازیابی دوره‌ای
Test Failover در شبکهٔ ایزوله، آمادگی فنی و رویه‌های تیم را بدون اتصال آزمایشی به کاربران واقعی بررسی می‌کند.
شبکه و کنترل دسترسی
اتصال رمزنگاری‌شده، IPSec VPN، تفکیک شبکه و سطح دسترسی متناسب با محیط سازمان بررسی می‌شوند.
پایش و گزارش‌دهی
سلامت Replication، فاصله از هدف RPO، گزارش مانور و مسئولیت پیگیری رخدادها در دامنهٔ خدمات تعیین می‌شوند.
قیمت‌گذاری اختصاصی بر اساس مقیاس شرکت
سه سطح زیر، چارچوب نمونهٔ طراحی در سند DR هستند؛ پلن آمادهٔ خرید، قیمت قطعی یا تضمین SLA نیستند. امکان دستیابی به هر هدف، پس از ارزیابی محیط، آزمون و توافق قراردادی مشخص می‌شود.
Standard
سرویس‌های با تحمل توقف بیشتر
RPO۴–۶ ساعتRTO۴–۸ ساعت
- اجزای نمونه
- Replication نوبتی، Snapshot روزانه، IPSec VPN و VPC ایزوله
- مانور بازیابی
- شش‌ماهه
- نگه‌داری نسخه‌ها
- ۱۴–۳۰ روز
- پوشش پشتیبانی پیشنهادی
- 8×5
Plus
سامانه‌های عملیاتی حساس‌تر
RPO۳۰–۶۰ دقیقهRTO۶۰–۱۲۰ دقیقه
- اجزای نمونه
- Replication پیوسته، Snapshot ساعتی، LB + WAF و RBAC
- مانور بازیابی
- فصلی
- نگه‌داری نسخه‌ها
- ۳۰–۶۰ روز
- پوشش پشتیبانی پیشنهادی
- 24×7
Premium
بارهای کاری حیاتی و تراکنشی
RPO۱–۱۵ دقیقهRTO۵–۳۰ دقیقه
- اجزای نمونه
- Replication پرسرعت با VCDA، Runbook خودکار، Test Failover و لینک اختصاصی
- مانور بازیابی
- ماهانه
- نگه‌داری نسخه‌ها
- ۶۰–۱۲۰ روز
- پوشش پشتیبانی پیشنهادی
- 24×7 / SLA
انتخاب سطح صرفاً بر اساس صنعت نیست؛ حساسیت هر سرویس، وابستگی‌ها، هزینهٔ توقف و نتیجهٔ مانور تعیین‌کننده‌اند. تعهدات نهایی در پیشنهاد فنی و قرارداد ثبت می‌شوند.
این محصول در پنل فروش خودکار ندارد. پیشنهاد فنی و مالی پس از مشاوره و بررسی زیرساخت تهیه می‌شود؛ دامنهٔ اجرا، اهداف بازیابی و تعهدات پشتیبانی در قرارداد مشخص خواهند شد.
مقیاس زیرساخت
تعداد ماشین‌ها و سرویس‌های حیاتی، CPU و RAM موردنیاز سایت مقصد و وابستگی برنامه‌ها.
حجم داده و ارتباط
حجم قابل حفاظت، نرخ تغییر داده، پهنای باند، زمان همگام‌سازی اولیه و مسیر ارتباط دو سایت.
اهداف بازیابی
RPO و RTO هر سامانه، مدت نگه‌داری نسخه‌ها و معماری Active–Passive یا Active–Active.
عملیات و پشتیبانی
دفعات مانور، ساعات پوشش، سطح مداخلهٔ تیم فنی، مستندسازی و توافق سطح خدمات.
پیشنهاد متناسب با سازمان شما
برای شروع، مقیاس شرکت، تعداد سرویس‌ها و هدف بازیابی را در درخواست مشاوره توضیح دهید.
درخواست ارزیابی و برآورداز شناخت زیرساخت تا مانور بازیابی
- ۱
نیازسنجی و تحلیل اثر کسب‌وکار
فهرست سرویس‌ها، وابستگی‌ها، محل استقرار و تحمل قطعی یا از دست رفتن داده را مشخص می‌کنیم.
سند نیازمندی - ۲
طراحی معماری و توافق دامنه
سایت مقصد، شبکه، منابع، RPO/RTO و نقش هر تیم در عملیات بازیابی تعیین می‌شوند.
طرح معماری - ۳
اتصال و همگام‌سازی اولیه
اتصال امن، سیاست Replication و ظرفیت مقصد پیکربندی و سلامت انتقال داده بررسی می‌شود.
گزارش راه‌اندازی - ۴
مانور، تحویل و بازبینی
بازیابی آزمایشی، سنجش زمان‌ها و اصلاح Runbook انجام می‌شود؛ برنامهٔ مانور و پایش تحویل داده خواهد شد.
برنامهٔ بازیابی
یک الگوی بازیابی برای همهٔ سازمان‌ها کافی نیست
سایت اصلی فعال، سایت دوم آمادهٔ بازیابی
سایت اولمحیط عملیاتی
Replication
سایت دومآمادهٔ بازیابی
در زمان عادی، سرویس‌ها از سایت اصلی پاسخ می‌دهند و داده به مقصد منتقل می‌شود. در حادثه، ظرفیت مقصد و برنامهٔ Failover فعال می‌شوند.
ظرفیت رزروشده، زمان روشن‌شدن ماشین‌ها و تغییر مسیر کاربران را ارزیابی کنید.
دو سایت در چرخهٔ سرویس‌دهی
سایت اولفعال · ترافیک کاربران
Sync / Async
سایت دومفعال · ترافیک کاربران
هر دو سایت می‌توانند بخشی از ترافیک را پاسخ دهند. طراحی همگام‌سازی پایگاه داده و State برنامه به فاصله، تأخیر شبکه و رفتار نرم‌افزار وابسته است.
Sync یا Async بودن تکثیر و مدیریت تعارض داده باید صریحاً مشخص شود.
ابر آراد به‌عنوان سایت پشتیبان سازمان
زیرساخت سازمانمحیط عملیاتی
Replication
ابر آرادآمادهٔ بازیابی
در الگوی DRaaS، زیرساخت داخلی سازمان از طریق اتصال امن به منابع پشتیبان ابری متصل می‌شود؛ سازگاری مجازی‌سازی و ظرفیت مقصد پیش از اجرا بررسی می‌شوند.
برای کاهش زمان Initial Sync، حجم داده و امکان Seed اولیه را بررسی کنید.
تکثیر داده در کنار نسخهٔ سالم تاریخی
سایت اولمحیط عملیاتی
Replication
سایت دومآمادهٔ بازیابی
Replication آمادگی مقصد را افزایش می‌دهد؛ اما ممکن است تغییر یا خرابی داده را نیز منتقل کند. Snapshot و بکاپ با نگه‌داری مستقل برای بازگشت به نقطهٔ سالم طراحی می‌شوند.
ایزوله یا Immutable بودن نسخه‌ها، دسترسی‌ها و تست بازیابی را جداگانه ارزیابی کنید.
پایش طرح بازیابی و کنترل تغییرات سازمان
سلامت Replication
فاصله از نقطهٔ بازیابی هدف، وضعیت اتصال و ظرفیت ذخیره‌سازی مقصد را پایش کنید؛ مسئول دریافت و پیگیری هشدار مشخص باشد.
کنترل دسترسی و شبکه
دسترسی تیم‌ها، ارتباط سایت‌ها و شبکهٔ تست را تفکیک کنید. هر تغییر در Firewall، VPN یا آدرس‌دهی باید در طرح بازیابی نیز بازتاب پیدا کند.
بازبینی منابع و وابستگی‌ها
با اضافه‌شدن ماشین، دیسک یا سرویس جدید، ظرفیت مقصد، ترتیب راه‌اندازی و اهداف بازیابی را به‌روزرسانی کنید.
Failback کنترل‌شده
پیش از بازگشت به سایت اصلی، رفع علت حادثه، سلامت محیط، همگام‌سازی داده و زمان‌بندی جابه‌جایی کاربران را تأیید کنید.
جزئیات فنی DR در محیط‌های VMware
قابلیت‌های زیر از معماری مرجع سند شما آمده‌اند. نسخه، لایسنس، توپولوژی و سیاست سرویس باید برای محیط سازمان تأیید شوند؛ همهٔ گزینه‌ها الزاماً در هر پروژه فعال نیستند.
On-prem vCenter → CloudCloud Director ↔ Cloud DirectorvCenter ↔ vCenter
Recovery Plans
ترتیب راه‌اندازی ماشین‌ها و وابستگی برنامه‌ها را در برنامهٔ Failover و Failback تعریف کنید؛ تأیید مسئول عملیات و آزمون سلامت جزئی از فرایند است.
Policy و اهداف RPO
سیاست Replication، نگه‌داری و کلاس ذخیره‌سازی برای هر سازمان یا سرویس تعریف می‌شود. هدف یک‌دقیقه‌ای مطرح‌شده در سند، نیازمند بررسی قابلیت نسخه و آزمون ظرفیت محیط است.
Test Failover
بازیابی آزمایشی را در شبکهٔ ایزوله اجرا کنید؛ مسیر دسترسی تست، عدم اتصال به کاربران واقعی و پاک‌سازی محیط پس از مانور باید روشن باشد.
Storage Policy
کلاس ذخیره‌سازی مقصد و نیاز دیسک‌ها بررسی می‌شوند؛ امکان انتخاب سیاست در زمان بازیابی به قابلیت نسخه و پیکربندی بستگی دارد.
Seed / Initial Sync
استفاده از ماشین یا بکاپ موجود به‌عنوان Seed، در صورت سازگاری، می‌تواند حجم انتقال اولیه را کم کند؛ صحت مبنا و همگام‌سازی تغییرات باید کنترل شوند.
Tunnel Appliance و اتصال
توپولوژی ارتباط، مسیرهای شبکه، پورت‌های موردنیاز و نقش Tunnel Appliance در طراحی اتصال بین محیط‌ها بررسی می‌شوند.
دسترسی عملیاتی تننت
در محیط‌های سازگار VCD، دسترسی مشاهده و مدیریت Replication می‌تواند طبق نقش‌های توافق‌شده تعریف شود؛ این دسترسی با خرید DR از پنل عمومی متفاوت است.
پایش و گزارش انطباق
سلامت تکثیر، عقب‌افتادگی از هدف RPO، رخدادها و نتیجهٔ مانورها ثبت می‌شوند تا اقدام اصلاحی و بازبینی ظرفیت قابل پیگیری باشند.
امنیت و مسئولیت تیم‌ها
IPSec VPN، تفکیک شبکه، محدودیت دسترسی و مسیر تأیید تغییرات در طرح اجرایی مشخص می‌شوند؛ مسئول هر اقدام در Runbook ثبت می‌شود.
مانور بازیابی؛ از اجرای Runbook تا گزارش قابل اقدام
طرحی که فقط روی کاغذ باشد، زمان واقعی بازیابی را نشان نمی‌دهد. در مانور، وابستگی سرویس‌ها، سلامت داده و امکان دسترسی کاربران آزمایشی با معیار پذیرش از پیش تعیین‌شده بررسی می‌شوند.
- تعریف سناریوی حادثه، دامنهٔ تست و مسئول تأیید
- ایجاد شبکهٔ تست ایزوله و انتخاب نقطهٔ بازیابی
- راه‌اندازی طبق ترتیب DNS، پایگاه داده و برنامه
- ثبت RPO/RTO مشاهده‌شده و نتیجهٔ آزمون سرویس
- پاک‌سازی محیط تست، اصلاح Runbook و تعیین مانور بعدی
۱اعلام حادثه و تأیید مسئول
۲انتخاب نقطهٔ سالم بازیابی
۳Failover و راه‌اندازی وابستگی‌ها
۴تأیید سلامت برنامه و دسترسی
۵Failback کنترل‌شده و گزارش
بکاپ، DR و سایت دوم چه تفاوتی دارند؟
این مقایسه دربارهٔ دامنهٔ راهکارهاست، نه ادعای برتری بر رقبای نامشخص. وجود بکاپ یا دیتاسنتر دوم به‌تنهایی به معنی داشتن برنامهٔ کامل بازیابی نیست.
| معیار | بکاپ | طرح Disaster Recovery | سایت دوم بدون Runbook |
|---|---|---|---|
| هدف اصلی | نگه‌داری نسخهٔ قابل بازگردانی | بازگشت داده، برنامه و دسترسی کاربران | فراهم‌کردن محل و ظرفیت جایگزین |
| ترتیب راه‌اندازی | معمولاً نیازمند تعریف جداگانه | در برنامهٔ بازیابی ثبت و آزموده می‌شود | باید جداگانه طراحی شود |
| RPO و RTO | وابسته به تناوب بکاپ و فرایند Restore | اهداف طراحی و معیار مانور | صرف وجود ظرفیت، زمان را تضمین نمی‌کند |
| آزمون دوره‌ای | آزمون صحت نسخه و Restore | مانور سرویس، شبکه و وابستگی‌ها | نیازمند سناریو و مسئول اجرا |
| فساد داده و باج‌افزار | نیازمند نسخهٔ سالم و حفاظت مستقل | ترکیب نسخهٔ سالم، محیط پاک و برنامهٔ بازگشت | ممکن است خرابی را همراه داده تکثیر کند |
DR برای سرویس‌هایی که توقفشان هزینه دارد
سازمان‌های مالی و بانکی
ثبت تراکنش، سازگاری داده و وابستگی سامانه‌های مالی، ورودی تعیین اهداف بازیابی و سناریوی مانور هستند.
فروشگاه‌ها و تجارت الکترونیک
پایگاه سفارش‌ها، پرداخت، موجودی و وب‌سایت باید با ترتیب مشخص و آزمون صحت عملکرد بازیابی شوند.
سازمان‌های دولتی و مراکز حساس
استقلال جغرافیایی، کنترل دسترسی، الزامات نگه‌داری داده و مسئولیت عملیات در طراحی بررسی می‌شوند.
آمادگی در برابر باج‌افزار
بازیابی از نقطهٔ سالم، جداسازی نسخه‌های پشتیبان و بررسی پاک‌بودن محیط مقصد بخشی از سناریوی بازگشت هستند.
طراحی بازیابی از مسئلهٔ واقعی سازمان شروع می‌شود
نمونه‌های زیر سناریوی طراحی هستند، نه گزارش نتیجهٔ تأییدشدهٔ مشتری یا تضمین درصد کاهش قطعی.
فناوری مالی و بانکداری
- چالش
- توقف تراکنش و ناسازگاری داده میان سامانه‌ها
- مسیر طراحی
- ارزیابی Active–Active یا سایت آماده‌به‌کار، سازگاری پایگاه داده و ترتیب بازیابی
- معیار پذیرش مانور
- تطبیق تراکنش‌ها، زمان بازگشت و سلامت سرویس‌های وابسته
تجارت الکترونیک
- چالش
- قطع مسیر سفارش، پرداخت و به‌روزرسانی موجودی
- مسیر طراحی
- طراحی بازیابی هماهنگ پایگاه سفارش، وب‌سایت و اتصال سرویس پرداخت همراه با مانور دوره‌ای
- معیار پذیرش مانور
- صحت سفارش‌ها و موجودی، دسترسی کاربر و امکان تکمیل خرید آزمایشی
سازمان دولتی و زیرساخت حساس
- چالش
- وابستگی خدمات عمومی به یک محل و الزامات حفاظت داده
- مسیر طراحی
- بررسی سایت جغرافیایی مستقل، کنترل دسترسی و الزامات قابل اعمال سازمان
- معیار پذیرش مانور
- استقلال مسیرها، دسترسی تیم مجاز و تأیید الزامات توسط سازمان
باج‌افزار و فساد داده
- چالش
- تکثیر تغییر مخرب یا رمزگذاری داده به مقصد
- مسیر طراحی
- نسخهٔ ایزوله یا غیرقابل‌تغییر در صورت پیش‌بینی در طرح، تشخیص نقطهٔ سالم و بازیابی در محیط پاک
- معیار پذیرش مانور
- سلامت داده، پاک‌بودن محیط و جلوگیری از بازگشت عامل آلودگی
برای بررسی زیرساخت بازیابی، از اینجا ادامه دهید
راهنمای بکاپ ابر خصوصی
آشنایی با مسیر حفاظت و بازیابی داده در مستندات ابر خصوصی
مطالعهٔ بیشترمدیریت ابر خصوصی
مرور مدیریت زیرساختی که می‌تواند بخشی از سایت بازیابی باشد
مطالعهٔ بیشترشرایط استفاده از خدمات
بررسی شرایط عمومی در کنار دامنهٔ خدمات و قرارداد اختصاصی DR
مطالعهٔ بیشترمعماری متناسب با نیاز شما
مشاورهٔ DR و طراحی بازیابی سازمان شما
زیرساخت فعلی، حساسیت سرویس‌ها و اهداف RPO/RTO را با تیم آراد بررسی کنید و پیشنهاد فنی و مالی متناسب با مقیاس سازمانتان بگیرید.
آیا Disaster Recovery همان بکاپ‌گیری است؟
خیر. بکاپ نسخه‌ای از داده‌ها را نگه می‌دارد؛ DR علاوه بر داده، زیرساخت جایگزین، شبکه، ترتیب راه‌اندازی سرویس‌ها، مسئولیت افراد و آزمون بازیابی را در بر می‌گیرد. بکاپ بخشی از برنامهٔ بازیابی است، نه جایگزین آن.
RPO و RTO مناسب سازمان چگونه تعیین می‌شوند؟
RPO بیان می‌کند از دست رفتن چه بازه‌ای از آخرین داده‌ها قابل تحمل است و RTO حداکثر زمان قابل قبول برای بازگشت سرویس را مشخص می‌کند. این دو هدف با تحلیل اثر توقف بر کسب‌وکار، حساسیت هر سامانه و بودجه تعیین می‌شوند.
آیا باید دیتاسنتر دوم داشته باشیم؟
در مدل On-premises to Cloud، زیرساخت ابر آراد می‌تواند نقش سایت پشتیبان را داشته باشد. شبکه، ظرفیت مقصد، سازگاری محیط و نیاز به ابزار یا اتصال اختصاصی در ارزیابی اولیه بررسی می‌شود.
چطور از عملکرد طرح در زمان حادثه مطمئن شویم؟
با Test Failover در محیط ایزوله، ترتیب راه‌اندازی، اتصال شبکه، سلامت داده و دسترسی کاربران آزمایش می‌شود. گزارش مانور، نقاط ضعف و اقدامات اصلاحی را مشخص می‌کند؛ تناوب تست در طرح اجرایی توافق می‌شود.
آیا این سرویس از پنل قابل خرید است؟
خیر. Disaster Recovery به‌صورت سازمانی و از مسیر مشاوره ارائه می‌شود. پس از دریافت مشخصات شرکت و زیرساخت، دامنهٔ کار و پیشنهاد فنی و مالی اختصاصی تهیه می‌شود.
هزینهٔ سرویس چگونه محاسبه می‌شود؟
مقیاس شرکت، تعداد و وابستگی سرویس‌ها، منابع پردازشی مقصد، حجم و نرخ تغییر داده، ظرفیت ارتباط، اهداف RPO/RTO، مدت نگه‌داری نسخه‌ها و سطح پشتیبانی بر هزینه اثر دارند. قیمت ثابت عمومی برای این سرویس ارائه نمی‌شود.
راهنمای انتخاب، هزینه و راه‌اندازی Disaster Recovery
برای انتخاب راهکار DR سازمانی، تفاوت بکاپ و بازیابی از بحران، اهداف RPO/RTO، معماری سایت پشتیبان و عوامل مؤثر بر قیمت را بشناسید.
