بازیابی فاجعه سایت؛ طراحی Backup، RPO/RTO و Runbook

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

این راهنما برای سایت شرکتی، WordPress و فروشگاه ایرانی نوشته شده است. خروجی آن باید یک Plan قابل اجرا باشد: BIA، RPO و RTO، معماری Backup، نسخه Immutable یا Offline، Runbook بازیابی، Drill دوره‌ای، نقش‌ها و شواهد موفقیت.

خلاصه تصمیم بازیابی فاجعه

عددهای واقعی از Business Impact Analysis می‌آیند. «بکاپ روزانه برای همه» همان‌قدر غیرواقعی است که «Active-active برای همه»: اولی ممکن است داده زیادی از دست بدهد، دومی ممکن است هزینه و پیچیدگی غیرضروری بسازد.

Backup، High Availability، DR و Business Continuity چه فرقی دارند؟

• Backup: نسخه‌ای از Data/Configuration برای بازگرداندن به نقطه قبلی.
• High Availability: کاهش قطعی ناشی از خرابی Component با Redundancy و Failover.
• Disaster Recovery: بازیابی سرویس و داده پس از رخداد بزرگ یا از دست‌رفتن محیط اصلی.
• Incident Response: تشخیص، مهار، بررسی و ریشه‌یابی رخداد، به‌ویژه امنیتی.
• Business Continuity: ادامه فرایند کسب‌وکار حتی وقتی سیستم عادی کامل برنگشته است.

Replication جای Backup نیست: حذف یا رمزگذاری مخرب می‌تواند فوراً به Replica برسد. Backup نیز Availability نمی‌سازد: ممکن است سالم باشد، اما Restore آن دو روز طول بکشد. DR این اجزا را با People، Process و Dependency به هم وصل می‌کند.

چه فاجعه‌هایی را باید پوشش دهیم؟

برای هر سناریو مشخص کنید چه چیزی Detect می‌کند، چه کسی Incident را اعلام می‌کند، چه داده‌ای ممکن است آلوده باشد و چه شرطی Recovery را آغاز می‌کند.

BIA؛ قبل از خرید ابزار، اثر کسب‌وکار را بسنجید

Business Impact Analysis یا BIA پاسخ می‌دهد کدام Capability واقعاً حیاتی است و توقف آن در هر بازه چه اثری دارد. «سایت» را یک Service واحد نبینید؛ فروشگاه می‌تواند این اجزا را داشته باشد:

• نمایش محصول و جست‌وجو
• Login و حساب کاربر
• Cart و Checkout
• ساخت Payment attempt و Verify
• Order management و انبار
• ارسال Email/SMS
• پنل مدیریت و گزارش
• DNS، TLS، CDN و WAF

برای هر Capability این پرسش‌ها را پاسخ دهید

• Owner کسب‌وکار و Owner فنی کیست؟
• وابستگی Upstream و Downstream چیست؟
• در یک ساعت، چهار ساعت و یک روز توقف چه زیان مالی/اعتباری رخ می‌دهد؟
• آیا حالت دستی یا Read-only قابل قبول است؟
• چه Dataای قابل بازسازی و چه Dataای غیرقابل بازگشت است؟
• کدام تعهد قراردادی، اطلاع‌رسانی یا نگهداری داده وجود دارد؟

NIST SP 800-34 Rev.1 طرح Contingency را با BIA، Strategy، Plan، Test/Training/Exercise و نگهداری Plan پیوند می‌دهد. ابزار Backup یکی از اجزاست، نه خود برنامه.

RPO، RTO و حداکثر وقفه قابل تحمل

RPO چیست؟

Recovery Point Objective بیشترین بازه Data loss قابل‌قبول است. اگر RPO سفارش‌ها ۱۵ دقیقه باشد، باید بتوانید Database را به نقطه‌ای برگردانید که حداکثر ۱۵ دقیقه Transaction از دست برود؛ Snapshot روزانه این نیاز را برآورده نمی‌کند.

RTO چیست؟

Recovery Time Objective زمان هدف برای بازگرداندن Capability پس از اعلام Disaster است. RTO فقط مدت کپی فایل نیست؛ Detect، تصمیم، دسترسی تیم، Provision، Restore، Validation، DNS/Traffic shift و Reconciliation را شامل می‌شود.

MTD/MAO چیست؟

Maximum Tolerable Downtime یا Maximum Acceptable Outage مرزی است که پس از آن اثر کسب‌وکار غیرقابل قبول می‌شود. RTO باید پایین‌تر از این مرز باشد و برای مرحله‌های Detect، Escalate و Recovery حاشیه داشته باشد.

مثال Tier برای یک فروشگاه ایرانی

این اعداد نسخه تجویزی نیستند. فروش، Staffing، SLA و هزینه کسب‌وکار شما باید آن‌ها را تعیین کند. RPO متفاوت برای Dataهای مختلف معمولاً اقتصادی‌تر از یک عدد بسیار پایین برای همه چیز است.

Inventory کامل دارایی‌های قابل بازیابی

Restore فقط public_html و SQL dump نیست. Inventory حداقل باید این موارد را پوشش دهد:

• Registrar، Domain lock، Contact و Recovery method
• DNS zone، DNSSEC در صورت استفاده، CDN/WAF config و Origin allowlist
• TLS certificate، Private key یا فرایند صدور مجدد
• Infrastructure definition، Package/version و Web server config
• Database، Binary log/WAL، User/Grant و Charset/Collation
• Application code، Plugin/Theme و Dependency lockfile
• Uploads، Object storage، Media derivatives و Permission
• Secretها، API keyها، Payment credential و Rotation procedure
• Queue، Cache، Search index و Job schedule
• Email/SMS template و Provider config
• Monitoring، Dashboard، Alert، Log و Audit trail
• Runbook، Contact list و نسخه Offline آن

برای هر مورد Source of truth، Backup method، Frequency، Retention، Encryption key، Owner، آخرین Restore test و Dependency را ثبت کنید.

Backup سازگار؛ فایل و دیتابیس باید یک لحظه منطقی را نشان دهند

در WordPress و فروشگاه پویا، Database و Uploadها هم‌زمان تغییر می‌کنند. اگر SQL مربوط به ساعت ۱۲ و Files مربوط به ساعت ۱۰ باشند، محصول ممکن است تصویر گمشده یا Plugin نسخه ناسازگار داشته باشد. Backup باید Consistency application-aware داشته باشد.

روش‌های اصلی

• Full backup: همه Data؛ Restore ساده‌تر، زمان و Storage بیشتر.
• Incremental: تغییر از آخرین Backup؛ سریع‌تر، اما Restore به زنجیره وابسته است.
• Differential: تغییر از آخرین Full؛ تعادل میان حجم و طول زنجیره.
• Snapshot: تصویر سریع Volume/VM؛ اگر Application quiesce نشود، Consistency تضمین نیست.
• PITR: Snapshot پایه به‌علاوه Transaction log برای بازگشت به زمان دقیق.
• Export منطقی: SQL/JSON/XML قابل حمل؛ برای مهاجرت خوب، ولی روی Data بزرگ ممکن است کند باشد.

Consistency فروشگاه

برای RPO پایین، Database-native backup و PITR را با Upload versioning ترکیب کنید. اگر Snapshot چند Volume دارید، Application pause، Filesystem freeze یا مکانیزم هماهنگی سرویس را بررسی کنید. در Restore، Order، Payment attempt، Inventory و Refund را با Sourceهای مستقل تطبیق دهید؛ «بالا آمدن Home» موفقیت کسب‌وکار نیست.

قاعده ۳-۲-۱ را به ۳-۲-۱-۱-۰ عملی تبدیل کنید

الگوی ۳-۲-۱ می‌گوید چند Copy روی بیش از یک نوع/Failure domain و حداقل یک نسخه Offsite داشته باشید. برای تهدید امروز، دو ویژگی دیگر مهم‌اند:

• یک نسخه Offline یا Immutable: Credential تولیدکننده Backup نتواند Retention آن را کوتاه یا نسخه را حذف کند.
• صفر خطای تأییدنشده: Integrity check و Restore test نشان دهد نسخه واقعاً قابل استفاده است.

عددها هدف نیستند؛ استقلال مهم است. سه Bucket زیر یک Cloud account و یک Admin credential ممکن است یک Failure domain باشند. نسخه خارج Production باید Control plane، Credential و ترجیحاً Provider/Region متفاوت داشته باشد.

راهنمای رسمی StopRansomware در CISA نگهداری Backupهای Offline و Encrypted و آزمون منظم Availability/Integrity را توصیه می‌کند؛ همچنین Golden image و نسخه Offline از Incident/Communication plan را مطرح می‌کند.

Immutable، Offline و Air-gapped یک چیز نیستند

• Immutable: Object تا پایان Retention قابل تغییر/حذف نیست؛ Misconfiguration یا کلید مدیریتی همچنان ریسک دارد.
• Offline: در حالت عادی از شبکه Production قابل دسترس نیست؛ عملیات Restore ممکن است کندتر باشد.
• Air-gapped: جداسازی قوی‌تر فیزیکی/منطقی؛ هزینه و فرایند انتقال بیشتری دارد.
• Soft delete/versioning: حذف را قابل بازگشت می‌کند، اما با Immutability برابر نیست.

برای Backup account، MFA مقاوم، نقش جدا، Delete protection، Alert تغییر Retention و Recovery code Offline در نظر بگیرید. Admin روزمره Production نباید بتواند همه نسخه‌ها را حذف کند.

Encryption و مدیریت کلید

Backup معمولاً حساس‌تر از Production است چون حجم بزرگی از Customer، Order، Email و Secret را یک‌جا دارد. Encryption at rest و in transit لازم است، اما اگر Encryption key همراه Backup و زیر همان Account باشد، استقلال محدود می‌شود.

• Key owner و Rotation policy را مشخص کنید.
• Restore با Key جدید و قدیمی را تست کنید.
• دسترسی Decrypt را جدا و Audit کنید.
• Secretهای غیرضروری را از Backup حذف کنید یا پس از Restore بچرخانید.
• Recovery key را در دسترس تیم مجاز و خارج از همان Failure domain نگه دارید.

Retention؛ نسخه بیشتر همیشه بهتر نیست

Retention باید Detection window، RPO، تغییرات کسب‌وکار، هزینه Storage، الزامات قراردادی و حذف داده را متوازن کند. اگر آلودگی سه ماه پنهان بماند و فقط هفت نسخه روزانه دارید، همه Restore pointها آلوده‌اند. از طرف دیگر نگهداری بی‌پایان Backup، Exposure و هزینه را بالا می‌برد.

یک Policy می‌تواند Daily/Weekly/Monthly tier داشته باشد، ولی عددها را با BIA تعیین کنید. Legal hold، حق حذف، مالیات و سیاست داده سازمان را نیز در Backup lifecycle لحاظ کنید. حذف منطقی از Production فوراً همه Backupهای Immutable را پاک نمی‌کند؛ فرایند Expiry و عدم بازگردانی ناخواسته داده حذف‌شده لازم است.

معماری‌های Disaster Recovery و هزینه آن‌ها

Active-active بدون Data conflict، Global traffic management، Observability و Drill می‌تواند از Backup/Restore ساده شکننده‌تر باشد. معماری را با RTO/RPO و توان تیم هماهنگ کنید.

ویژگی‌های ویژه Backup وردپرس

راهنمای رسمی Backup در WordPress بر پشتیبان‌گیری Database و Files هر دو تأکید می‌کند. برای Restore کامل معمولاً نیاز دارید:

• Database با Prefix، Charset و User/Grant درست
• wp-content/uploads
• Theme و Pluginهای سفارشی یا Version دقیق آن‌ها
• wp-config.php یا Template امن آن با Secretهای تازه
• Must-use pluginها و Drop-inها
• Web server config، Cron و PHP extension/version
• Ruleهای CDN/WAF/Cache و استثناهای WooCommerce

از Cache و فایل موقت فقط وقتی Backup بگیرید که بازسازی آن‌ها دشوارتر از Restore است. Core WordPress و Plugin عمومی را می‌توان از Source رسمی و Version ثبت‌شده Rebuild کرد؛ این روش در Incident بدافزار از بازگرداندن فایل ناشناخته امن‌تر است.

افزونه Backup چه محدودیتی دارد؟

Plugin داخل همان Application و Credential domain اجرا می‌شود. اگر WordPress، Account یا Server از دسترس خارج شود، Plugin ممکن است نتواند Restore کند. Export خارج سایت، Credential جدا و مسیر بازیابی بدون wp-admin ضروری است. حجم زیاد و Timeout PHP نیز باید در Drill واقعی سنجیده شود.

WooCommerce و سازگاری تراکنش

فروشگاه هنگام Disaster فقط Content از دست نمی‌دهد؛ Order و Payment state ممکن است بین سایت و درگاه متفاوت باشد. Runbook باید این حالت‌ها را پوشش دهد:

• پرداخت موفق در PSP اما Order در Backup هنوز Pending است.
• Webhook پس از Restore دوباره ارسال می‌شود.
• Inventory بعد از بازگشت به نقطه قدیمی بیش‌ازحد می‌شود.
• Coupon یا Refund دوبار اعمال می‌شود.
• Email تأیید برای Order قدیمی دوباره ارسال می‌شود.

Restore را با Idempotency، State machine و Reconciliation کامل کنید. فهرست Transactionهای بازه Data loss را از Provider پرداخت بگیرید و وضعیت را با Evidence اصلاح کنید. جزئیات در راهنمای معماری امن درگاه پرداخت آمده است.

دامنه، DNS و TLS در DR

ممکن است Application سالم باشد اما دامنه به آن نرسد. این اقلام را خارج از ذهن یک مدیر نگه دارید:

• Registrar و DNS account با MFA و Recovery code
• Export Zone و Inventory رکوردها
• TTL فعلی و زمان واقعی Propagation
• DNSSEC key/DS و Runbook تغییر Provider
• CDN/WAF config و Origin IPهای مجاز
• Certificate issuance و Renewal روی محیط جایگزین
• مالکیت Search Console و سرویس‌های وابسته

گواهی Origin جایگزین و DNS را پیش از Disaster آزمایش کنید. راهنمای نصب و تمدید گواهی TLS این بخش را تکمیل می‌کند.

بازیابی از بدافزار؛ Restore کور نکنید

در Incident امنیتی، تازه‌ترین Backup ممکن است Backdoor یا Account مهاجم را نیز داشته باشد. ابتدا Evidence و Timeline را حفظ کنید، Scope و Persistence را بسنجید و Recovery point قبل از Compromise را با Risk انتخاب کنید.

1. Containment بدون نابودکردن شواهد
2. ساخت محیط تمیز از Source معتبر
3. Restore حداقل Data لازم، نه Binary ناشناخته
4. Scan و Validation چندلایه
5. Rotation همه Credentialهای در معرض خطر
6. Patch Root cause پیش از بازگشت Traffic
7. Monitor رفتار و Indicatorها پس از Recovery

برای تصمیم Cleanup یا Rebuild و بازیابی SEO از راهنمای پاک‌سازی بدافزار سایت استفاده کنید. HA یا Replica آلوده را به محیط سالم Failover ندهید.

Runbook بازیابی فاجعه؛ ترتیب وابستگی‌ها

مرحله ۱: Detect و Declare

• Incident چیست و Severity چند است؟
• چه کسی Disaster را اعلام می‌کند؟
• RTO از چه لحظه‌ای اندازه‌گیری می‌شود؟
• آیا امنیتی است و Evidence باید حفظ شود؟

مرحله ۲: Contain و Communicate

• Writeها، Deploy یا Access مهاجم را متوقف کنید.
• کانال ارتباطی مستقل از سیستم آسیب‌دیده باز کنید.
• Incident commander، Technical lead و Business owner را مشخص کنید.
• Status داخلی و در صورت نیاز پیام کاربر را با زمان Update بعدی منتشر کنید.

مرحله ۳: انتخاب Recovery point و Target

• آخرین نقطه سالم با Evidence چیست؟
• چه Data gapای ایجاد می‌شود؟
• Restore in-place، Clean rebuild یا Failover؟
• ظرفیت Target برای Traffic واقعی کافی است؟

مرحله ۴: ساخت Dependencyها

1. Identity و Access اضطراری
2. Network، Firewall و Private connectivity
3. Storage و Key management
4. Database و Transaction log
5. Application، Config و Secret تازه
6. Queue/Search/Job و External integration
7. DNS، TLS، CDN و WAF
8. Monitoring، Log و Alert

مرحله ۵: Restore و Validate

Checksum و Chain را بررسی، Data را Restore و Migrationهای لازم را کنترل کنید. Smoke test فنی کافی نیست؛ Business validation شامل Login، Search، Order، Payment test، Callback، Inventory، Email و Admin workflow است.

مرحله ۶: Cutover و Observe

Traffic را مرحله‌ای بازگردانید، Error rate، Latency، Queue، Order و Payment mismatch را زیر نظر بگیرید. برای پایش از Observability با Metric، Log و Trace و راهنمای Uptime monitoring استفاده کنید.

مرحله ۷: Reconcile و Postmortem

Data gap را با Sourceهای مستقل آشتی دهید، کاربر آسیب‌دیده را مشخص، Temporary control را حذف و Root cause را اصلاح کنید. RTO/RPO واقعی، تصمیم‌های دیر، دسترسی‌های ناکارآمد و Gap مستندات را ثبت کنید.

انواع تست بازیابی

شواهد موفقیت Drill

• RPO واقعی و تعداد Record ازدست‌رفته
• RTO از Declare تا Business ready
• زمان هر Stage و Critical path
• درصد Backupهای قابل Restore
• تعداد Step دستی و Access failure
• Payment/Order reconciliation mismatch
• زمان انتشار اولین Status update
• Issue owner و Deadline اصلاح

تکرار Drill را با ریسک و تغییرات تنظیم کنید: پس از تغییر بزرگ Hosting/Database/CDN، Rotation تیم یا شکست Backup، منتظر تقویم شش‌ماهه نمانید.

RACI و نقش‌های ضروری

برای تیم کوچک ممکن است یک فرد چند نقش داشته باشد، اما Approval و دسترسی Break-glass نباید تنها در اختیار کسی باشد که شاید در دسترس نباشد. MFA و Recovery را با راهنمای MFA و حساب Break-glass طراحی کنید.

ارزیابی Backup هاست و Vendor

به عبارت «Backup روزانه داریم» بسنده نکنید. پاسخ مکتوب این پرسش‌ها را بگیرید:

• Scope دقیق: Files، Database، Email، DNS یا فقط Volume؟
• Frequency و Retention واقعی چیست؟
• نسخه در همان Account/Region/Datacenter است؟
• Immutable یا Offline است؟ چه کسی می‌تواند حذف کند؟
• Encryption key دست چه کسی است؟
• Restore self-service است یا Ticket؟ SLA آن چیست؟
• Export به Provider دیگر ممکن است؟ هزینه Egress چقدر است؟
• آخرین Restore test و نرخ موفقیت چیست؟
• در Termination یا عدم پرداخت چه زمانی Backup حذف می‌شود؟
• چگونه Backup را بدون Production account دریافت می‌کنید؟

برای کسب‌وکار ایرانی، دسترسی پایدار، روش پرداخت، پهنای باند Restore، پاسخ‌گویی Provider و امکان Export را در PoC واقعی بسنجید. سرویسی که Upload سریع دارد اما هنگام بحران از شبکه تیم قابل‌دسترسی نیست، RTO را تأمین نمی‌کند.

اشتباهات رایج

• اتکا کامل به Snapshot همان هاست
• برابر دانستن Sync/Replica با Backup
• Backup فایل بدون Database یا برعکس
• نداشتن Consistency میان DB و Upload
• نگهداری همه نسخه‌ها زیر یک Admin account
• Encryption بدون Recovery key آزموده
• Retention کوتاه‌تر از زمان کشف آلودگی
• Restore در Production برای اولین آزمون
• بازیابی Backup آلوده بدون Root-cause fix
• تست Home و فراموش‌کردن Checkout/Callback
• نادیده‌گرفتن DNS، TLS، Secret و Provider contact
• RTO/RPO غیرواقعی بدون اندازه‌گیری Drill
• Runbook فقط در Wiki از دسترس خارج‌شده
• به‌روزرسانی سیستم بدون هماهنگ‌کردن Backup و Rollback؛ فرایند درست در راهنمای تغییر امن WordPress آمده است.

قالب حداقلی Disaster Recovery Plan

Plan owner و نسخه:
Scope و سرویس‌های حیاتی:
سناریوهای تحت پوشش:
BIA و MTD/MAO:
RPO/RTO هر Capability:
Dependency map:
Backup source/frequency/retention:
Immutable/Offline location:
Encryption key owner:
دسترسی Break-glass:
Trigger و اختیار Declare:
Recovery target و ظرفیت:
Runbook مرحله‌ای:
Validation فنی و کسب‌وکار:
DNS/TLS/Traffic cutover:
Reconciliation:
ارتباطات و Contactها:
Rollback/Failback:
آخرین Drill و شواهد:
Gapها، Owner و Deadline:

برنامه ۳۰ روزه ساخت DR سایت

هفته اول: BIA و Inventory

• Capability، Data و Dependency را فهرست کنید.
• RPO/RTO و Owner را با کسب‌وکار توافق کنید.
• Backup موجود و Failure domain را مستند کنید.

هفته دوم: بستن Gap نسخه‌ها

• Database/Files/Object/DNS/Config را هماهنگ کنید.
• نسخه Offsite و Immutable/Offline بسازید.
• Encryption، Key و Access جدا را تنظیم کنید.

هفته سوم: Runbook و Restore کامل

• محیط Isolated را Provision و Full restore کنید.
• WordPress، Checkout، Callback و Integration را تست کنید.
• RPO/RTO واقعی و Critical path را اندازه بگیرید.

هفته چهارم: Exercise و Governance

• Tabletop با تیم و Providerها اجرا کنید.
• Alert Expiry/Backup/Restore و Dashboard بسازید.
• Plan Offline، RACI، تقویم Drill و Issue backlog را نهایی کنید.

پرسش‌های متداول بازیابی فاجعه سایت

۱. هر چند وقت یک‌بار از سایت بکاپ بگیریم؟

Frequency از RPO و نرخ تغییر Data می‌آید. وبلاگ کم‌تغییر ممکن است با Backup روزانه مناسب باشد؛ Order فروشگاه به Snapshot ساعتی یا PITR نیاز داشته باشد. Database، Upload و Config را جدا Tier کنید و نتیجه را با Restore test اثبات کنید.

۲. آیا Backup روزانه شرکت هاست کافی است؟

فقط اگر Scope، Retention، Failure domain، دسترسی، زمان Restore و تست آن با RPO/RTO شما سازگار باشد؛ در عمل نباید تنها نسخه باشد. حداقل یک Copy مستقل خارج Control plane هاست و مسیر Restore بدون Ticket وابسته به Production داشته باشید.

۳. تفاوت RPO و RTO به زبان ساده چیست؟

RPO می‌گوید تا چه مقدار Data loss قابل قبول است؛ RTO می‌گوید بازگشت Capability چقدر زمان دارد. Backup frequency بیشتر RPO را بهتر می‌کند، اما RTO به Provision، دسترسی، Runbook، ظرفیت و تمرین تیم هم وابسته است.

۴. آیا Backup آلوده را می‌توان Restore کرد؟

ممکن است بخشی از Data قابل نجات باشد، اما Restore کور خطرناک است. Timeline و Indicator را بررسی، محیط تمیز بسازید، Binary را از Source معتبر Rebuild، Data لازم را Scan و همه Credentialهای در معرض خطر را Rotate کنید.

۵. چگونه مطمئن شویم Backup واقعاً سالم است؟

Checksum و Catalog فقط شروع‌اند. یک Restore کامل در محیط Isolated انجام دهید، Dependencyها و Secretها را وصل کنید، مسیرهای کسب‌وکار مانند Login، Order و Payment را تست و RPO/RTO واقعی را ثبت کنید. Backup تأییدنشده قابل اتکا نیست.

جمع‌بندی

بازیابی فاجعه سایت یعنی رساندن Capability حیاتی به وضعیت قابل‌اعتماد در زمان و Data loss توافق‌شده. BIA و RPO/RTO را تعریف کنید؛ Database، Files، DNS، TLS و Secret را Inventory کنید؛ نسخه مستقل و Immutable/Offline داشته باشید؛ Recovery امنیتی را با Rebuild تمیز انجام دهید؛ و Runbook را با Drill و Business validation اثبات کنید.

اگر Backup دارید اما RPO/RTO، Owner، نسخه مستقل یا آخرین Restore test معلوم نیست، هنوز DR کامل ندارید. برای طراحی معماری، اجرای Drill و ساخت Runbook می‌توانید از مشاوره زیرساخت و امنیت مایندیو کمک بگیرید.

بازبینی فنی منابع: ۶ اوت ۲۰۲۶. RPO/RTO و Retention باید با BIA، قراردادها، معماری و ریسک واقعی هر سازمان تعیین شوند.