# High Availability، Backup و Disaster Recovery؛ آیا زیرساخت سازمان شما واقعاً برای بحران آماده است؟

راهنمای عملی HA، Backup و DR با معماری VMware و SQL Server، هفت سناریوی سازمانی، RPO/RTO، بازیابی باج‌افزار و Runbook قطعی دیتاسنتر.

## ۱. سه حادثه با سه مسیر بازیابی متفاوت

ساعت سه بامداد یکی از ESXiها پاسخ نمی‌دهد. در این سازمان فرضی، HA ماشین ERP را جای دیگری Restart می‌کند، اما Session باز حسابداری از دست رفته است. هفته بعد، اپراتور چند ردیف فاکتور را حذف می‌کند و هر دو Replica در SQL همان حذف را ثبت می‌کنند. حالا برق کل ساختمان قطع می‌شود؛ سرورها افزونه‌اند، ولی شعبه‌ها به احراز هویت، DNS و ERP دسترسی ندارند. این سه حادثه مسیر بازیابی یکسانی ندارند و خرید کلاستر تازه جواب هر سه نیست.

از دید یک Infrastructure & DevOps Engineer، سؤال مفید دقیق است: کدام تراکنش کسب‌وکار، با کدام داده، از کدام مسیر شبکه و پس از چه مدتی دوباره انجام می‌شود؟ پاسخ را از Failure Domain و وابستگی سرویس می‌سازیم. تمام سازمان‌ها، زمان‌ها و Thresholdهای این مقاله مثال طراحی‌اند؛ گزارش استقرار شخصی یا وعده بازیابی نیستند.

دامنه نسخه: VMware vSphere/ESXi 8.0، PowerCLI 13.x، SQL Server 2022 (16.x) روی Windows با WSFC، Ubuntu 24.04 و systemd، مثال API در Kubernetes 1.36، Swarm Mode در Docker Engine و Syntax تریگر Zabbix 7.0. این‌ها مبنای مشخص مقاله‌اند، نه ادعای جدیدترین‌بودن تمام شاخه‌ها. پیش از اجرا، License، چرخه پشتیبانی، Patch و سازگاری سخت‌افزار را بررسی کنید. قابلیت Backup در SQL 2025 را به 2022 تعمیم ندهید.

## ۲. هر لایه حفاظت دقیقاً چه چیزی می‌دهد؟

| مفهوم | معنا و مرز عملیاتی |
| --- | --- |
| High Availability | کاهش وقفه با افزونگی و Failover؛ VM بازیابی‌شده هنوز زمان Boot و Recovery برنامه دارد. |
| Fault Tolerance | تداوم اجرا در خرابی جزء تحت پوشش؛ vSphere FT نمونه اجرایی Secondary نگه می‌دارد، در محدوده قابلیت پشتیبانی‌شده. خطای منطقی همچنان خطاست. |
| Backup | نسخه تاریخی نگهداری‌شده و مستقلاً قابل بازیابی؛ برگرداندن فاکتور پیش از حذف. ارزش آن به کلید قابل دسترس و زنجیره Restore سالم وابسته است. |
| Replication | انتقال تغییر به کپی دیگر برای Availability یا DR؛ حذف هم ممکن است منتقل شود. Lag سیاست نگهداری نیست. |
| Disaster Recovery | بازیابی سرویس IT پس از از دست رفتن سایت یا پلتفرم اصلی با محیط جایگزین و ترتیب تمرین‌شده. |
| Business Continuity | ادامه فعالیت کسب‌وکار شامل افراد، محل، تأمین‌کننده و کار دستی مجاز تا زمان بازیابی IT. |
| Failover | انتقال مالکیت سرویس به مقصد سالم؛ Writer واحد و مسیر اتصال مجدد کلاینت را مشخص کنید. |
| Failback | بازگشت کنترل‌شده پس از تعمیر، همگام‌سازی معکوس و اعتبارسنجی؛ Primary قدیمی ممکن است داده کهنه داشته باشد. |
| Redundancy | اجزای اضافه، مثلاً دو PSU با برق مستقل؛ دو دستگاه با یک ورودی برق، خرابی مشترک دارند. |
| Data Protection | ترکیب کنترل دسترسی، صحت، رمزنگاری، نگهداری و قابلیت بازیابی در چرخه عمر داده. |
| Disaster Recovery Plan | تصمیم‌گیر مشخص، وابستگی، گام بازیابی، دسترسی به Credential، شواهد، معیار پذیرش و Failback برای IT. |
| Business Continuity Plan | اولویت‌های تحت مالکیت کسب‌وکار، روش جایگزین، نیروی انسانی، ارتباطات و بیشترین اختلال قابل تحمل؛ DR از آن پشتیبانی می‌کند. |

| فناوری | هدف اصلی | پوشش | عدم پوشش |
| --- | --- | --- | --- |
| VMware HA | Restart ماشین | خرابی میزبان با دیسک قابل دسترس و ظرفیت آزاد | خرابی Array مشترک، حذف، باج‌افزار، از دست رفتن Session |
| vSphere FT | تداوم اجرا | خرابی پشتیبانی‌شده میزبان اصلی | نوشتن اشتباه، خرابی وابستگی مشترک، نگهداری Backup |
| SQL Always On AG | تداوم نقش دیتابیس | خرابی Replica طبق سیاست Quorum و Sync | DELETE اشتباه، تمام انواع Corruption، بازیابی تاریخی |
| Storage replication | کپی بلوک جاری در مقصد | بعضی خرابی‌های Array یا سایت با توجه به استقلال | تکثیر حذف منطقی یا نوشتن رمز‌شده |
| Kubernetes / Swarm | بازسازی Workload | خرابی Worker با بقای کنترل، ظرفیت و وابستگی | Volume محلی ازدست‌رفته، خطای برنامه، قطعی کل سایت |
| Independent backup | بازیابی تاریخی | حذف یا خرابی پس از نقطه سالم موجود | تداوم فوری سرویس یا تضمین بازیابی پاک |
| Multi-site DR | بازیابی سرویس کسب‌وکار | بحران اعلام‌شده در دامنه آزموده | وابستگی آزموده‌نشده یا سایت بازیابی آلوده |

حذف جدول SQL یک تغییر Commit‌شده است که AG معمولاً آن را Replay می‌کند. VMDK حذف‌شده از Storage مشترک با انتقال VM به میزبان دیگر ساخته نمی‌شود. Rollout اشتباه Kubernetes هم می‌تواند با کارایی بالا روی همه Workerها اعمال شود. مکانیزم Availability وضعیت درخواستی را بازتولید می‌کند؛ حفاظت تاریخی باید وضعیت پیش از اشتباه را نگه دارد.

## ۳. RPO و RTO؛ تبدیل تحمل کسب‌وکار به معیار پذیرش

![RPO از حادثه تا آخرین نقطه قابل بازیابی به عقب و RTO تا بازیابی تأییدشده سرویس به جلو نگاه می‌کند](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/rpo-rto.svg)

RPO بیشترین عقب‌ماندگی قابل قبول داده بازیابی‌شده نسبت به لحظه اختلال است. اگر تنها Backup قابل استفاده ساعت 01:00 باشد و سرور 04:00 قطع شود، تغییرات پنجره سه‌ساعته ممکن است از دست بروند. نوشتن RPO پانزده دقیقه این نتیجه را عوض نمی‌کند؛ طراحی به هدف نرسیده است. Log Backup سالم بعدی، Replica قابل دسترس یا Tail-log Backup ایمن می‌تواند زیان واقعی را کمتر کند؛ پیش از اعلام عدد، شواهد را بررسی کنید. سه ساعت پنجره مواجهه است، نه اثبات وجود سه ساعت تراکنش.

RTO زمان هدف از شروع اختلال تا رسیدن سرویس کسب‌وکار به معیار بازیابی توافق‌شده است. تشخیص، اعلام بحران، زیرساخت، Restore داده، اجرای برنامه و Validation همگی از این بودجه مصرف می‌کنند. چهار ساعت قطعی ERP ممکن است ارسال انبار و تأیید حقوق را متوقف کند، حتی اگر Restore دیتابیس فقط چهل دقیقه طول کشیده باشد. زمان واقعی را جدا ثبت کنید. در این مقاله RTA یعنی Recovery Time Actual و RPA یعنی Recovery Point Actual، یعنی سن اندازه‌گیری‌شده داده قابل بازیابی؛ این نام‌گذاری همگانی نیست و تعریف آن باید در DR Plan نوشته شود.

| سرویس | RPO / RTO فرضی | طراحی قابل دفاع و تأیید کسب‌وکار |
| --- | --- | --- |
| A: File Server | 4 h / 8 h | Backup چهارساعته و کپی Offsite؛ مالک بازسازی اسناد عادی را می‌پذیرد، اما Share حقوقی ممکن است هدف سخت‌گیرانه‌تری بخواهد. |
| B: Enterprise ERP | 15 min / 2 h | Log Backup و بازیابی مستقل برنامه و Configuration؛ مسیر هویت تا ثبت سفارش را با بار مورد انتظار در دو ساعت بسنجید. |
| C: Critical financial database | 1 min / 30 min | HA محلی Sync، دوام راه دور و حفاظت Log و ظرفیت Warm را بسنجید؛ تسویه بیرونی تطبیق شود. این هدف هزینه بیشتر و شواهد اندازه‌گیری می‌خواهد. |

این اعداد پس از تحلیل اثر کسب‌وکار، با لحاظ زمان اوج و بیشترین اختلال قابل تحمل، به تأیید Business Owner نیاز دارند. کپی راه دور Async را DR بدون ازدست‌رفتن داده معرفی نکنید. WAN را براساس نرخ پایدار تولید Log و Burst جبران عقب‌ماندگی اندازه‌گذاری کنید؛ سن صف را بسنجید، نه فقط سرعت لینک.

## ۴. VMware؛ میزبان می‌تواند خراب شود، دیسک باید قابل استفاده بماند

![سه میزبان ESXi، vCenter و Shared Storage؛ Failover میزبان VM را Restart می‌کند ولی خرابی Storage مشترک همه میزبان‌ها را متوقف می‌کند](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/vmware-ha.svg)

ESXi ماشین‌ها را اجرا می‌کند؛ vCenter تنظیم کلاستر و مدیریت مرکزی را می‌دهد. پس از پیکربندی، Agentهای HA می‌توانند بدون vCenter روشن به خرابی میزبان پاسخ دهند، هرچند نبود مدیریت عملیات را دشوار می‌کند. HA مکانیزم Restart است. vMotion در کار برنامه‌ریزی‌شده و با Source زنده، VM روشن را جابه‌جا می‌کند؛ Storage vMotion دیسک را منتقل می‌کند. DRS جانمایی را متعادل می‌کند و رفتار آن به License و Automation وابسته است. این ابزارها جای Recovery پس از مرگ Source را نمی‌گیرند.

### خرابی Host؛ کلاستر سه‌میزبانی واقعاً چه می‌کند؟

فرض کنید برق H1 قطع شود. HA شواهد Heartbeat میزبان، شبکه و Datastore و پاسخ‌های تنظیم‌شده را ارزیابی می‌کند و وقتی تشخیص خرابی و جانمایی اجازه دهد، VMهای حفاظت‌شده واجد شرایط را روی H2/H3 Restart می‌کند. زمان ثابتی برای Restart وجود ندارد؛ تشخیص، Lock، دسترسی Datastore، Admission Policy، Boot و Crash Recovery دیتابیس مؤثرند. Session حافظه و درخواست ناتمام از Restart سرد جان سالم نمی‌برند. برنامه به Retry و Idempotency نیاز دارد؛ پرداخت قطع‌شده را خودکار ناموفق فرض نکنید.

با HA Admission Control ظرفیت خرابی رزرو کنید و N+1 را زیر اوج CPU، RAM، IOPS و محدودیت License بسنجید. VM Restart Priority ترتیب تلاش را مشخص می‌کند؛ آماده بودن AD یا SQL پیش از ERP را اثبات نمی‌کند. Health Gate برنامه لازم است. Host Isolation Response به طراحی آگاهانه شبکه مدیریت و Isolation Address نیاز دارد. VM Monitoring از Heartbeat ابزار VMware Tools و بررسی‌های فعالیت مرتبط استفاده می‌کند؛ Tools سالم اثبات موفقیت تراکنش ERP نیست. FT وقفه اجرای خرابی تحت پوشش را برای VM پشتیبانی‌شده کمتر می‌کند، اما داده و وابستگی‌های فراوان مشترک می‌مانند؛ محدودیت vCPU، Device، شبکه و License را برای Build دقیق بررسی کنید.

### خرابی Storage؛ میزبان دیگر هم Array قطع‌شده را نمی‌خواند

اگر تمام میزبان‌ها از یک Array قطع‌شده استفاده کنند، Restart روی Host دیگر VMDK قابل دسترس ایجاد نمی‌کند. Compute HA به Storage Resilience نیاز دارد: مسیر مستقل، Controller افزونه، Multipathing آزموده و در صورت توجیه، Storage مستقل قابل بازیابی در سایت دیگر. VM Component Protection بین APD و PDL فرق می‌گذارد و پاسخ تنظیم‌شده را اجرا می‌کند، ولی هنوز میزبان با دسترسی به دیسک معتبر لازم است. سوئیچ دوم، دو مسیر دارای Controller، برق یا مسیر فیبر مشترک را مستقل نمی‌کند. به راهنمای VMCP سازنده عمل کنید و وسط Incident تنظیم پیشرفته Timeout را تغییر ندهید.

[منبع: Availability، HA و FT در vSphere 8](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability-8-0.html)

[منبع: مرز تنظیم VMCP، APD و PDL](https://knowledge.broadcom.com/external/article/406100/best-practice-for-vsphere-high-availabil.html)

### رشد Snapshot؛ پیش از Consolidation بررسی کنید

Snapshot ماشین زنجیره تغییر دیسک نگه می‌دارد و معمولاً به همان Base Disk و Datastore وابسته است؛ Backup مستقل نیست. رشد Delta می‌تواند Datastore را پر کند، VM را Stun کند و نوشتن مهمان‌های دیگر را هم متوقف کند. ابتدا فضای آزاد واقعی، نرخ رشد، سن Snapshot، Job بکاپ فعال، سلامت زنجیره دیسک، ظرفیت Array و Latency را بررسی کنید. Alarm نیاز به Consolidation و وضعیت پلتفرم Backup را ببینید. SizeGB در Snapshot نشانه است، نه پیش‌بینی کامل فضای موقت Consolidation.

پیش از Consolidation تأییدشده، Backup مستقل قابل استفاده، فضای کاری کافی مطابق راهنمای سازنده، پنجره نگهداری و اثر I/O را تأیید کنید. زنجیره شکسته یا مالکیت نامعلوم را به پشتیبانی ارجاع دهید. برای آزاد کردن فضا Delta را دستی حذف نکنید، Lock را برندارید و Consolidation یا Backup هم‌زمان راه نیندازید. اگر عملیات متوقف به نظر رسید، شواهد Task و Log را حفظ و از پشتیبانی استفاده کنید؛ دست‌کاری دستی VMDK فرمان Undo عمومی ایمن ندارد. زمان پیش‌بینی‌شده تا پرشدن را پایش کنید تا تصمیم پیش از خطای نوشتن گرفته شود.

## ۵. SQL Server Always On؛ Replica ماشین زمان نیست

![Primary SQL لاگ را به Secondary محلی Sync و Replica اختیاری Async در DR می‌فرستد؛ Backup تاریخی مسیر جدا دارد](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/sql-always-on.svg)

AG دونودی Windows در این مثال Primary Replica برای نوشتن، Secondary Replica برای Replay رکورد Transaction Log، عضویت و Quorum در WSFC و Availability Group Listener برای اتصال مجدد دارد. هر Replica Storage دیتابیس خودش را دارد. نودها را روی میزبان مستقل قرار دهید و Witness را طوری جانمایی کنید که با از دست رفتن سایت، بازمانده مورد نظر بدون Quorum نماند. Listener نقطه اتصال است، نه بافر تراکنش؛ Driver پشتیبانی‌شده، مدیریت Retry و در طراحی Multi-subnet رفتار آزموده DNS و Connection String لازم‌اند.

Synchronous Commit پیش از تأیید Commit تحت پوشش، منتظر Harden شدن Log در Secondary همگام می‌ماند؛ لازم نیست Redo همان لحظه آن را اعمال کرده باشد. Asynchronous Commit منتظر دوام راه دور نمی‌ماند و پنجره زیان دارد. Log Send Queue لاگ ارسال‌نشده و Redo Queue لاگ Harden‌شده منتظر Redo است. عقب‌ماندگی Redo می‌تواند زمان Recovery یا تازگی Readable Secondary را حتی با انتقال سالم بدتر کند. نرخ، سن صف، قطع ارتباط و Synchronization State را کنار هم ببینید.

### حادثه اول؛ SQL اصلی قطع می‌شود

Automatic Failover به جفت پشتیبانی‌شده با حالت Automatic و Synchronous Commit، مقصد سالم Synchronized، Quorum در WSFC و خرابی واجد شرایط سیاست Failover نیاز دارد. از دست رفتن فایل یا خطای یک دیتابیس الزاماً Trigger هر AG نیست؛ Database-level Health Detection تنظیم جداگانه است. Manual Failover برنامه‌ریزی‌شده بدون زیان هم مقصد Sync و Synchronized می‌خواهد. Forced Failover به مقصد Async یا ناهمگام می‌تواند تراکنش تأییدشده را از بین ببرد و به اختیار صریح Incident، Fencing و تطبیق بعدی نیاز دارد. دستور آن در این مقاله اجرا نمی‌شود.

[منبع: حالت‌ها و پیش‌نیازهای Failover در SQL AG](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/failover-and-failover-modes-always-on-availability-groups?view=sql-server-ver16)

### حادثه دوم؛ فاکتورها حذف می‌شوند

DELETE یا DROP معتبر تغییر منطقی است و Log آن را به Replica می‌برد. از مسیر مدیریت Incident، مسیر معیوب برنامه را متوقف، Log را حفظ، زمان Commit را شناسایی و نقطه قبلی را در دیتابیس جدا با نام متفاوت Restore کنید. پیش از اصلاح داده مجاز، کلیدها و جمع‌های کسب‌وکار را مقایسه کنید. Failover فقط سرور پاسخ‌دهنده به همان حذف را عوض می‌کند. بدون طراحی Application-aware فرض نکنید چند دیتابیس یا وابستگی بیرونی در یک نقطه تراکنشی سازگار قرار دارند.

### حادثه سوم؛ Corruption به تشخیص نیاز دارد، نه ارتقای خودکار

قطعی زیرساخت، خرابی منطقی و خطای فیزیکی Page بررسی متفاوت می‌خواهند. بعضی خطاهای Page پشتیبانی‌شده از Automatic Page Repair و Page سالم طرف مقابل استفاده می‌کنند؛ این تضمین عمومی Repair نیست. خطای Storage ممکن است فقط یک Replica را خراب کند؛ Bug برنامه می‌تواند داده اشتباه ولی از نظر فیزیکی معتبر روی هر دو بسازد. Error Log، شواهد Page و Checksum و زنجیره Backup را نگه دارید. تا حد امکان DBCC CHECKDB را روی کپی Restoreشده کنترل‌شده اجرا و پیش از بررسی Production اثر منابع را ارزیابی کنید؛ DBA و سازنده باید مسیر Restore سالم یا Repair پشتیبانی‌شده را انتخاب کنند. سراغ REPAIR_ALLOW_DATA_LOSS نپرید.

[منبع: دامنه Automatic Page Repair](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/automatic-page-repair-availability-groups-database-mirroring?view=sql-server-ver16)

برای SQL 2022، Full معمولی را مبنای Differential، Differential را تغییر از آن مبنا و زنجیره بدون گسست Transaction Log Backup در مدل FULL را برای Point-in-Time Recovery به کار ببرید. Backup Preferences قصد جانمایی را بیان می‌کند؛ Job باید آن را مثلاً با sys.fn_hadr_backup_is_preferred_replica اجرا کند. در این مبنا Full روی Secondary از نوع Copy-only است و Differential آنجا پشتیبانی نمی‌شود. برنامه Full معمولی و Differential را در مسیر Primary پشتیبانی‌شده نگه دارید. Basic AG در Standard از نظر تعداد دیتابیس، Replica و قابلیت‌ها بسیار محدودتر از Enterprise AG است؛ پیش از تقلید طراحی Edition را بررسی کنید.

[منبع: پشتیبانی Backup در Secondary به تفکیک نسخه](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/active-secondaries-backup-on-secondary-replicas-always-on-availability-groups?view=sql-server-ver16)

## ۶. آزمایشگاه جدا برای Backup و Point-in-Time Restore در SQL

پلتفرم: SQL Server 2022 Developer روی Windows و SSMS یا sqlcmd دارای پشتیبانی GO. این Lab دیتابیس تازه و فایل Backup می‌سازد؛ فقط روی Instance جدا با مجوز تغییر اجرا شود. پوشه‌های خالی C:\DRLab\backup و C:\DRLab\data را ایجاد، دسترسی لازم Service Account SQL را تأمین و ظرفیت را بررسی کنید؛ Instance آزمایشی تازه لازم است. Credential در کد نیست. مقصد را Production نگذارید. Guard دیتابیس Lab یا Restore موجود را رد می‌کند؛ WITH REPLACE، حذف فایل یا Overwrite Production نداریم.

```sql
:ON ERROR EXIT
USE master;
GO
IF DB_ID(N'ResilienceLab') IS NOT NULL
 OR DB_ID(N'ResilienceLab_Restore') IS NOT NULL
    THROW 51000, 'Use a fresh isolated lab instance.', 1;
GO
CREATE DATABASE ResilienceLab
 ON PRIMARY (NAME=N'ResilienceLab', FILENAME=N'C:\DRLab\data\ResilienceLab.mdf')
 LOG ON (NAME=N'ResilienceLab_log', FILENAME=N'C:\DRLab\data\ResilienceLab_log.ldf');
GO
ALTER DATABASE ResilienceLab SET RECOVERY FULL;
GO
USE ResilienceLab;
CREATE TABLE dbo.Invoice (Id int PRIMARY KEY, Amount decimal(12,2) NOT NULL);
INSERT dbo.Invoice VALUES (1,100.00);
GO
BACKUP DATABASE ResilienceLab TO DISK=N'C:\DRLab\backup\lab-full.bak'
 WITH CHECKSUM;
GO
INSERT dbo.Invoice VALUES (2,200.00);
BACKUP DATABASE ResilienceLab TO DISK=N'C:\DRLab\backup\lab-diff.bak'
 WITH DIFFERENTIAL, CHECKSUM;
GO
INSERT dbo.Invoice VALUES (3,300.00);
GO
-- Copy this server-local timestamp into STOPAT below.
SELECT CONVERT(varchar(23), GETDATE(), 121) AS RecoveryTarget;
WAITFOR DELAY '00:00:03';
UPDATE dbo.Invoice SET Amount=999.00 WHERE Id=3;
BACKUP LOG ResilienceLab TO DISK=N'C:\DRLab\backup\lab-log.trn' WITH CHECKSUM;
GO
RESTORE VERIFYONLY FROM DISK=N'C:\DRLab\backup\lab-full.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK=N'C:\DRLab\backup\lab-diff.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK=N'C:\DRLab\backup\lab-log.trn' WITH CHECKSUM;
RESTORE FILELISTONLY FROM DISK=N'C:\DRLab\backup\lab-full.bak';
GO
```

قرارداد اجرا: فایل آماده‌سازی با sqlcmd 18 و احراز هویت Integrated و گزینه -b اجرا شود؛ مثلاً sqlcmd -S localhost -E -b -i sql-lab-prepare.sql با Certificate معتبر سرور. هر دو فایل به Directiveهای SQLCMD نیاز دارند؛ در Query Mode معمولی SSMS اجرا نشوند. :ON ERROR EXIT و -b خطای SQL را در مرز GO به توقف اجرا تبدیل می‌کنند. RecoveryTarget را ثبت، مقدار NULL فایل دوم را اصلاح و بازبینی و همان فایل را یک‌بار با همین Runner اجرا کنید. Timestamp اصلی را نگه دارید؛ اجرای دوباره آماده‌سازی مسیر Restore نیست.

```sql
:ON ERROR EXIT
USE master;
GO
-- Set to RecoveryTarget returned by the preparation file.
DECLARE @RecoveryTarget datetime = NULL;
IF @RecoveryTarget IS NULL
    THROW 51001, 'Set the captured RecoveryTarget first.', 1;
IF DB_ID(N'ResilienceLab_Restore') IS NOT NULL
    THROW 51002, 'Restore database already exists; stop the exercise.', 1;
RESTORE DATABASE ResilienceLab_Restore FROM DISK=N'C:\DRLab\backup\lab-full.bak'
 WITH MOVE N'ResilienceLab' TO N'C:\DRLab\data\ResilienceLab_Restore.mdf',
 MOVE N'ResilienceLab_log' TO N'C:\DRLab\data\ResilienceLab_Restore_log.ldf',
 NORECOVERY, CHECKSUM;
RESTORE DATABASE ResilienceLab_Restore FROM DISK=N'C:\DRLab\backup\lab-diff.bak'
 WITH NORECOVERY, CHECKSUM;
RESTORE LOG ResilienceLab_Restore FROM DISK=N'C:\DRLab\backup\lab-log.trn'
 WITH STOPAT=@RecoveryTarget, RECOVERY, CHECKSUM;
GO
DBCC CHECKDB (N'ResilienceLab_Restore') WITH NO_INFOMSGS;
SELECT Id,Amount FROM ResilienceLab_Restore.dbo.Invoice ORDER BY Id;
```

انتظار: پیام تکمیل Backup و Restore، موفقیت VERIFYONLY، نبود خطای Integrity در CHECKDB و سه ردیف با مجموع 600.00؛ ردیف سوم 300.00 است، نه 999.00. نام‌های FILELISTONLY باید با نام منطقی MOVE یکسان باشند. خطا به معنی توقف تمرین است، نه مجوز Overwrite دیتابیس دیگر. اگر Target درست ثبت نشده، Source و Backup را حفظ و تمرین را روی Instance جدا و تازه بازسازی کنید. Rollback یعنی قطع اتصال محیط آزمایش؛ پاک‌سازی Lab تغییر جدا با بازبینی است. این دستورها هنگام تهیه مقاله بررسی شده‌اند، اما روی SQL زنده اجرا نشده‌اند.

VERIFYONLY خوانایی و کامل‌بودن Backup را بررسی می‌کند، نه صحت منطقی کامل محتوا. CHECKSUM هم محدودیت دارد. Restore موفق همراه CHECKDB و تطبیق برنامه شواهد قوی‌تری می‌دهد. سیاست Production به رمزنگاری Backup، Export مستقل محافظت‌شده Certificate و Private Key، آزمون بازیابی کلید، Retention متناسب با کشف دیرهنگام و ظرفیت تمام فایل‌های وابسته Full/Differential/Log نیاز دارد. Tail-log Backup در صورت دسترسی Log می‌تواند کمک کند، ولی امکان اجرای ایمن آن تصمیم DBA است.

[منبع: Point-in-Time Recovery و محدودیت Recovery Model](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-sql-server-database-to-a-point-in-time-full-recovery-model?view=sql-server-ver16)

## ۷. معماری Backup مستقل؛ الگوی 3-2-1-1-0

![ماشین‌های VMware، SQL و File Server به مخزن ایزوله با نسخه‌های Offsite Immutable و Offline مستقل متصل‌اند](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/enterprise-backup.svg)

| قاعده | مثال طراحی مشخص |
| --- | --- |
| 3 | Production به‌اضافه Backup محلی و کپی Offsite؛ سه نسخه داده، نه سه Snapshot یک Volume. |
| 2 | دو سامانه Storage یا رسانه مستقل؛ مثلاً Array تولید و دیسک Backup با کپی Tape یا Object؛ خطر Control Plane و Firmware مشترک هم بررسی شود. |
| 1 offsite | نسخه بیرون Failure Domain برق، سیل، آتش و مدیریت سایت اصلی. |
| 1 offline or immutable | چرخش فیزیکی Offline یا Retention تغییرناپذیر تحت مدیریت جدا؛ مخزن آنلاین Immutable برابر Air Gap نیست. |
| 0 | نبود خطای حل‌نشده در شواهد بازیابی آزموده: Restore زمان‌بندی‌شده، Integrity و تست برنامه؛ نه وعده صفر خطا در آینده. |

برای VMware، SQL و فایل، Backup Control Server را در Zone مدیریت محدود، Storage مخزن را جدا و مسیر انتقال داده را محدود کنید. Catalogue و Configuration بکاپ هم به اندازه Payload حفاظت می‌خواهند. پردازش SQL-aware باید VSS یا Backup بومی دیتابیس و مالکیت Log را هماهنگ کند؛ دو Job ناهماهنگ، عیب‌یابی و Retention را خطرناک می‌کنند. Backup Server با Credential ادمین دامنه Production و همان Datastore قابل نوشتن، حتی با Dashboard سبز مسیر آلودگی مشترک دارد.

Application-consistent Backup با Flush یا Quiescence برنامه هماهنگ است؛ Crash-consistent شبیه Recovery پس از قطع برق است و ممکن است Log Replay یا اصلاح برنامه بخواهد. هیچ‌کدام سازگاری تراکنش چندسرویسی را خودکار اثبات نمی‌کنند. Storage Snapshot برای Rollback کوتاه یا مرحله Capture پشتیبانی‌شده Backup مفید است. Replication کپی جاری دیگری می‌دهد؛ Backup تاریخچه مستقلاً قابل بازیابی نگه می‌دارد. تمام Volumeها، Logها و وابستگی بیرونی لازم را در نقطه انتخاب‌شده آزمایش کنید.

نمونه Retention: سی نقطه روزانه، دوازده هفتگی و دوازده ماهانه؛ نسخه سالانه فقط با نیاز کسب‌وکار یا حقوقی. GFS یا Grandfather-Father-Son الگوی نگهداری چندرده‌ای است، نه معافیت از محاسبه ظرفیت. زنجیره Full، نرخ تغییر، مدت قفل Immutability، نسخه Object و فضای کاری Restore را محاسبه کنید. انتقال و ذخیره را رمزنگاری، کلید را جدا، MFA و حداقل دسترسی را اعمال، مدیریت مخزن را محدود و حذف را Audit کنید؛ دسترسی Break-glass بدون هویت Production آزموده شود. Offline یعنی خارج از دسترس مسیر حمله زنده؛ Air-gapped مرز جداسازی واقعی با رویه کنترل‌شده اتصال مجدد رسانه است.

## ۸. هفت سازمان با هفت طراحی قابل دفاع

### سناریوی ۱ — پنج سرور

برای AD، فایل، SQL و Application روی یک یا دو Hypervisor، از Backup مستقل ماشین و برنامه، کپی روزانه Offsite، یک نسخه Offline یا Immutable محافظت‌شده و مقصد Restore با ظرفیت سرویس ضروری شروع کنید. با یک Host، قطعی مبتنی بر Restore را صریح بپذیرید؛ دو Host بدون Storage مستقل و ظرفیت کافی خودکار HA نیستند. در صورت امکان DC دوم در Failure Domain مستقل داشته باشید. RPO چهار ساعت و RTO هشت ساعت فرضی برای فایل عادی ممکن است مناسب باشد؛ Log SQL فاصله توافقی جدا می‌خواهد. هزینه License کمتر با بازیابی دستی و وابستگی به حضور نیرو معاوضه می‌شود.

### سناریوی ۲ — بیست VM

برای VMware، Windows/Linux و ERP روی Shared Storage، اگر نیاز Uptime بودجه دارد، HA سه‌میزبانی N+1 طراحی کنید؛ مسیر دوگانه باید به سامانه Storage تاب‌آور برسد. Backup ماشین Application-aware در Repository متفاوت، حفاظت Log SQL، کپی Offsite Immutable و Restore جداگانه کامل سرویس به‌صورت ماهانه قرار دهید. مسیر File-level، Whole-VM و Database را جدا تعریف کنید. RTO دوساعته ERP شامل AD/DNS و اتصال کلاینت است. Array مشترک واحد حتی با سه میزبان مرز شکست باقی می‌ماند.

### سناریوی ۳ — پنجاه VM

Compute HA را از Database HA جدا کنید: Replicaهای SQL AG روی Host متفاوت، Quorum و Witness مستقل، پایش Send/Redo Queue و Backup SQL بیرون Storage هر دو Replica. موج بازیابی از Dependency Map بیاید، نه نام VM: ابتدا هویت و شبکه، سپس داده، ERP/API و گزارش. مدیریت Backup ایزوله و IOPS Restore در زمان Job رزرو شود. مسئول On-call و جانشین بودجه بگیرند؛ پلتفرم پیچیده با یک ادمین دور از دسترس، نقطه شکست عملیاتی دارد.

### سناریوی ۴ — صد VM

در چند Cluster و Datastore، سرویس کسب‌وکار را با Owner، رده بازیابی و وابستگی تراکنش بین‌سرویسی ثبت کنید. Backup براساس نرخ تغییر و Latency منبع توزیع شود؛ Job لاگ اولویت بگیرد و Synthetic Full هم‌زمان IOPS مخزن را تمام نکند. رشد Datastore، Snapshot و Throughput بازیابی هم‌زمان مدل شود. DR می‌تواند فقط زیرمجموعه Critical مستند را با منابع رزرو و حالت کاهش ظرفیت Load-test‌شده سرویس دهد. آزمون فصلی برنامه، Certificate و Middleware جاافتاده را آشکار می‌کند که Restore تک‌VM نمی‌بیند.

### سناریوی ۵ — دو Data Center

اگر یک Stack قابل نوشتن و Stack بازیابی Warm هدف را برآورده می‌کند، Active-Passive انتخاب منطقی است: مالکیت ساده‌تر، اما ظرفیت بیکار و زمان Promotion دارد. Active-Active فقط با طراحی State برنامه، Routing، تعارض داده و ظرفیت زمان خرابی در دو سایت ترافیک می‌پذیرد. دو کپی قابل نوشتن دیتابیس ERP قدیمی طراحی Active-Active نیست. وقتی Latency WAN برای Commit همگام بین سایت‌ها پذیرفته نیست، HA محلی Sync و DR راه دور Async اندازه‌گیری‌شده را ترجیح دهید. Backup مستقل Offsite باید بیرون مسیر مدیریتی هر دو Replication باشد.

### سناریوی ۶ — Kubernetes و برنامه Stateful

رأی‌دهنده‌های Control Plane و etcd و Worker را بین Failure Domainها پخش کنید؛ API Endpoint، CNI، CSI، Registry، Ingress و DNS را حفاظت کنید. etcd و تنظیم API، Secret با کلید رمزنگاری، Manifest و داده برنامه با روش سازگار با دیتابیس Backup شوند. دوام PersistentVolume به Backend و Topology وابسته است؛ StatefulSet هویت و ترتیب می‌دهد، نه Replication دیتابیس. ساخت دوباره Pod، Local Volume ازدست‌رفته را برنمی‌گرداند. Cluster بازیابی جدا و تمرین هم‌زمان Restore PV و تطبیق برنامه لازم است.

### سناریوی ۷ — دفتر مرکزی و پنجاه شعبه

برای ERP مرکزی، Reachability را مستقل از سلامت دیتاسنتر دسته‌بندی کنید. قطع مدار یک شعبه به دو مسیر واقعاً متنوع WAN، طراحی Cache/Forwarding محلی DNS و رویه Offline مجاز نیاز دارد؛ انتقال ERP به DR، Last Mile را تعمیر نمی‌کند. اختلال سراسری WAN تنوع Carrier و تست همگرایی مسیر می‌خواهد. خرابی DNS به زیرساخت Authoritative و Recursive مستقل و رکورد معتبر نیاز دارد. خرابی ERP مرکزی بازیابی برنامه و دیتابیس می‌خواهد. قطعی کل DC به مسیر شعب، Policy فایروال و Name Resolution مقصد DR نیاز دارد و باید از شعب نماینده تست شود.

تداوم محلی می‌تواند صف‌کردن سفارش مجاز با شناسه یکتا و تطبیق بعدی باشد؛ نباید بی‌صدا سیستم مرجع مالی دوم ساخته شود. Configuration تجهیزات شبکه، Templateهای VPN/SD-WAN و دسترسی اضطراری محافظت‌شده را Offsite نگه دارید. اتصال DR در Failover و Failback آزموده شود؛ دو لینک داخل یک کانال خیابان تنوع مسیر معنادار نیستند.

## ۹. Kubernetes و Docker Swarm؛ اجرای جایگزین پیش‌نیاز دارد

![Kubernetes پاد واجد شرایط و Swarm تسک سرویس را پس از خرابی Worker جایگزین می‌کنند؛ هر دو به کنترل، Storage، شبکه و داده برنامه سالم وابسته‌اند](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/orchestrator-ha.svg)

Kubernetes مشکل نود را تشخیص و Workload واجد شرایط را طبق Controller، Eviction و Scheduling بازسازی می‌کند. Managerهای Swarm با وجود Quorum و ظرفیت Worker مجاز، Task سرویس را جایگزین می‌کنند. هیچ‌کدام اجرای فوری یا حفظ حافظه Process را تضمین نمی‌کنند. Docker Volume محلی روی همان نود می‌ماند؛ Volume از نوع ReadWriteOnce در Kubernetes ممکن است Detach/Attach ایمن و ظرفیت سازگار با Topology بخواهد. در Partition، Writer قدیمی Stateful را پیش از واگذاری نقش Fence کنید. Force-delete کردن Pod اثبات مرگ Process قبلی نیست.

در Swarm سه Manager رأی‌دهنده از دست رفتن یکی را تحمل می‌کند؛ Worker رأی اضافه نمی‌کند. روش مستند Backup وضعیت Manager را دنبال و کلید Autolock فعال را جدا نگه دارید. در Kubernetes، Snapshot etcd وضعیت Cluster را حفاظت می‌کند، نه ردیف SQL یا Payload در PV. در هر دو، Image تأییدشده و Configuration را بیرون سایت ازدست‌رفته نگه دارید. Readiness و Health Check باید مسیر وابستگی مورد نیاز کاربر را با Backoff و تغییر کنترل‌شده ترافیک بسنجند.

[منبع: تضمین‌ها و محدودیت StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)

[منبع: Quorum، Backup مدیریت و Recovery در Swarm](https://docs.docker.com/engine/swarm/admin_guide/)

## ۱۰. سایت بازیابی را به‌عنوان مسیر کامل سرویس طراحی کنید

![دیتاسنتر اصلی و بازیابی مستقل، اتصال شعب، هویت، Compute، Storage و لایه برنامه با حفاظت Backup جدا](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/primary-dr.svg)

از Dependency Graph شروع کنید: کلاینت شعبه ← DNS ← WAN/Firewall ← هویت و PKI ← ورودی برنامه و API ← دیتابیس ← Storage. NTP، Secret، License، Queue، Object Storage و API بیرونی را هرجا واقعاً مصرف می‌شوند اضافه کنید. شبکه بازیابی، Compute و IOPS کافی، Monitoring و مدیریت محافظت‌شده را از قبل آماده کنید. Recovery Cluster نباید به vCenter اصلی، Vault رمز فقط در سایت اصلی یا خروجی اینترنت همان سایت وابسته باشد. Runbook قابل خواندن Offline و فهرست Owner دارایی داشته باشید.

| وابستگی / پرسش | طراحی و اعتبارسنجی |
| --- | --- |
| AD and DNS | برای سرویس وابسته به Domain، DC و DNS مناسب در DR و رویه آزموده System-state و Forest Recovery لازم است. AD تکثیرشده آلودگی را هم می‌برد؛ Cyber Recovery برنامه هویت مورد اعتماد جدا می‌خواهد. |
| PKI / certificates | دیتابیس و تنظیم CA، کلید خصوصی، Chain و Endpoint ابطال را حفاظت کنید. SAN و انقضای نام DR بررسی شود؛ دیتابیس سالم خرابی TLS را حل نمی‌کند. |
| Firewall / routing | Rule حداقلی DR، NAT/VPN، Route و دسترسی شعب آماده باشد؛ پس از تأیید مالکیت مقصد با کنترل تغییر فعال شود. |
| IP and application connections | نام سرویس یا Listener پایدار ترجیح دارد. Subnet مسیریابی‌شده DR یا آدرس کشیده پشتیبانی‌شده انتخاب شود؛ TTL، Cache و Retry آزموده شوند. IP ممکن است عوض شود و هر Endpoint ثابت فهرست شود. |
| Split-brain | Quorum، Witness و Fencing پشتیبانی‌شده محصول لازم است. پیش از Promotion، جداسازی Writer قدیمی تأیید شود؛ نبود Ping اثبات ناتوانی در نوشتن نیست. |
| Data validation | زمان یا LSN بازیابی، شواهد Integrity دیتابیس، Offset صف و مانده کسب‌وکار ثبت شود؛ تراکنش بیرونی تطبیق و پذیرش Owner گرفته شود. |
| Failback | سایت قبلی تعمیر و بررسی، داده جاری DR بکاپ و از Writer مرجع DR همگام شود؛ جابه‌جایی کنترل‌شده زمان‌بندی و پایش و مسیر بازگشت به DR حفظ شود. |

نقش HA محلی Sync دیتابیس را از DR راه دور Async اختیاری جدا کنید. Replica راه دور در دیاگرام SQL توسعه مثال پایه دونودی است؛ AG دونودی ناگهان سه نود ندارد. اگر License یا WAN برای Replication مناسب نیست، سرویس بازیابی مبتنی بر Backup با زمان Restore اندازه‌گیری‌شده منطبق با هدف امضاشده قابل دفاع است. کپی مستقل Backup تا حد امکان مرز شکست و مدیریت سوم می‌خواهد، نه فقط پوشه‌ای روی Storage سایت DR.

## ۱۱. اگر ساعت ۳ صبح کل Data Center سازمان قطع شود، از کجا شروع می‌کنیم؟

![تشخیص حادثه، دسته‌بندی، ارزیابی اثر، اعلام بحران، بازیابی زیرساخت و داده، اعتبارسنجی و بازگشت سرویس کسب‌وکار](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/dr-workflow.svg)

این Runbook مرجع ERP فرضی Windows/VMware/SQL است، نه مجوز Failover در Production. نسخه تأییدشده مختص سازمان با Owner، تماس، گراف سرویس، مراحل جداسازی، دستور Promotion مختص محصول و مهلت Escalation نگه دارید. تمام دستورهای زیر تشخیصی‌اند؛ Activation به رویه بازیابی جداگانه تأییدشده اشاره دارد. ساعت مشترک Incident و ثبت امن شواهد داشته باشید؛ با مالکیت متعارض Writer یا احتمال آلودگی متوقف شوید. ترتیب از وابستگی می‌آید: شبکه، زمان، هویت و اعتماد؛ Storage و Compute برحسب نیاز؛ دیتابیس؛ Middleware و برنامه؛ ورودی و Validation کسب‌وکار.

### ۱. Incident Detection

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | NOC و On-call |
| پیش‌نیاز | Monitoring مستقل و دسترسی Incident |
| عملیات | Alert میزبان، Storage، WAN و Probe بیرونی را تطبیق؛ اولین تراکنش ناموفق را ثبت و Incident باز کنید. |
| خروجی مورد انتظار / تفسیر | TcpTestSucceeded وضعیت مسیر آزموده را می‌دهد؛ از نقطه دوم هم بررسی شود. |
| معیار موفقیت | دامنه و زمان اختلال تأییدشده، نه یک Ping ناموفق |
| ریسک / Rollback | خود Monitoring شاید قطع باشد؛ تغییری برای Undo نیست، شواهد حفظ شود. |

```powershell
Test-NetConnection erp.example.internal -Port 443
```

### ۲. Incident Classification

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | مسئول Incident و متخصص هر لایه |
| پیش‌نیاز | شناسه Incident و Console مستقل |
| عملیات | فرض برق، شبکه، Storage، Compute، امنیت و دیتابیس را با شواهد PDU/BMC، Switch، Array و برنامه جدا کنید. |
| خروجی مورد انتظار / تفسیر | وضعیت Host یا خطای دسترسی؛ Disconnect به‌تنهایی علت را تعیین نمی‌کند. |
| معیار موفقیت | دسته‌بندی مستند و Escalation امنیت در ابهام |
| ریسک / Rollback | Reboot زودهنگام شواهد را از بین می‌برد؛ فقط تشخیص، بررسی مداخله‌ای متوقف شود. |

```powershell
Get-VMHost | Select Name,ConnectionState,PowerState
```

### ۳. Impact Assessment

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | Owner سرویس و عملیات |
| پیش‌نیاز | گراف وابستگی و BIA جاری |
| عملیات | مسیر کاربر و شعب متاثر را مشخص؛ بودجه باقی RTO و نقاط داده نامزد را محاسبه کنید. |
| خروجی مورد انتظار / تفسیر | رکورد مورد انتظار یا خطای DNS؛ با Resolver مستقل مقایسه شود. |
| معیار موفقیت | مجموعه وابستگی Critical و اثر کسب‌وکار توافق‌شده |
| ریسک / Rollback | نقشه کهنه Middleware را جا می‌اندازد؛ ارزیابی موقت بماند و کاربر Redirect نشود. |

```powershell
Resolve-DnsName erp.example.internal
```

### ۴. Disaster Declaration

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | فرمانده مجاز Incident و Business Owner |
| پیش‌نیاز | اثر، برآورد تعمیر، RPO/RTO و ارزیابی امنیت |
| عملیات | Go/No-go، مواجهه زیان داده و اختیار ثبت؛ پیش از Activation تصمیم Writer واحد و Fencing گرفته شود. |
| خروجی مورد انتظار / تفسیر | Timestamp در تصمیم ثبت؛ دستور اختیار ایجاد نمی‌کند. |
| معیار موفقیت | تصمیم Activation امضاشده یا Ticketشده و طرح Fence منبع |
| ریسک / Rollback | اعلام اشتباه Writer دوگانه می‌سازد؛ اگر شواهد تغییر کرد پیش از Promotion لغو کنید. |

```powershell
Get-Date -Format o
```

### ۵. Communication

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | مسئول ارتباطات Incident |
| پیش‌نیاز | درخت تماس تأییدشده بیرون سایت خراب |
| عملیات | از کانال توافقی به تیم و Owner اطلاع دهید؛ دامنه، زمان Update بعدی و محدودیت تراکنش مشخص شود. |
| خروجی مورد انتظار / تفسیر | زمان Update و تأیید دریافت؛ اطلاع‌رسانی عملیات انسانی و فرایندی است. |
| معیار موفقیت | تأیید دریافت Ownerها و Status قابل دسترس |
| ریسک / Rollback | ETA تأییدنشده گمراه می‌کند؛ سابقه حفظ و پیام اصلاح شود. |

```powershell
Get-Date -Format o
```

### ۶. Recovery Activation

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | هماهنگ‌کننده DR و امنیت |
| پیش‌نیاز | تصمیم مجاز، دسترسی مورد اعتماد و منبع Fence‌شده |
| عملیات | نسخه مصوب Runbook، ظرفیت مقصد و دسترسی Credential بررسی؛ فقط مراحل مجاز آن فعال شود. |
| خروجی مورد انتظار / تفسیر | مدل Witness و Quorum مورد انتظار در مسیر مدیریت DR؛ Membership جدا بررسی شود. |
| معیار موفقیت | شواهد حفاظت Writer واحد و آمادگی مقصد |
| ریسک / Rollback | Force Quorum میان‌بر نیست؛ در شکست آمادگی توقف و جداسازی منبع حفظ شود. |

```powershell
Get-ClusterQuorum
```

### ۷. Infrastructure Recovery

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | مسئول شبکه، هویت و مجازی‌سازی |
| پیش‌نیاز | Zone بازیابی مورد اعتماد، برق و مسیر مدیریت |
| عملیات | Routing/Firewall، NTP، AD/DNS/PKI، Storage و Compute طبق وابستگی اعتبارسنجی و Provision مصوب شود. |
| خروجی مورد انتظار / تفسیر | تست DNS برای DC مقصد موفق؛ Warning و خروجی حساس بررسی شود. |
| معیار موفقیت | سرویس پایه قابل دسترس و Trust و Certificate معتبر |
| ریسک / Rollback | AD آلوده تکثیرشده حمله را برمی‌گرداند؛ شبکه جدا، Route مرحله‌ای طبق مجوز برگردد. |

```powershell
dcdiag /test:DNS /s:dr-dc01
```

### ۸. Database Recovery

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | DBA و امنیت در حادثه سایبری |
| پیش‌نیاز | نقطه سالم معتبر، کلید، Storage و جداسازی Writer |
| عملیات | مسیر Promotion یا Restore مصوب انتخابی اجرا؛ نقطه و شواهد Consistency و تطبیق برنامه ثبت شود. |
| خروجی مورد انتظار / تفسیر | دیتابیس لازم پس از Recovery مجاز ONLINE؛ این وضعیت به‌تنهایی صحت فیزیکی یا داده کسب‌وکار را ثابت نمی‌کند. |
| معیار موفقیت | پذیرش Integrity توسط DBA و ثبت مواجهه واقعی داده |
| ریسک / Rollback | مقصد غلط تراکنش از دست می‌دهد؛ ترافیک متوقف و نقطه Restore جدا انتخاب، شواهد Overwrite نشود. |

```sql
SELECT name,state_desc FROM sys.databases;
```

### ۹. Application Recovery

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | مسئول Application و DevOps |
| پیش‌نیاز | DB پذیرفته‌شده، Secret، Queue، Certificate و وابستگی |
| عملیات | نسخه مصوب موجی طبق وابستگی اجرا، Endpoint DR تنظیم و Scheduler و Worker پرداخت تا تطبیق کنترل شود. |
| خروجی مورد انتظار / تفسیر | active برای Unit واقعی؛ Readiness و اتصال دیتابیس جدا بررسی شود. |
| معیار موفقیت | Health و Readiness موفق بدون پردازش تکراری ناخواسته |
| ریسک / Rollback | Job تکراری دوباره برداشت می‌کند؛ Worker متاثر متوقف و تنظیم برنامه طبق Runbook برگردد. |

```bash
systemctl is-active erp-api
```

### ۱۰. Validation و بازگشت سرویس

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | Business Owner و QA و عملیات |
| پیش‌نیاز | سرویس پایدار، دسترسی تست محدود و حساب Synthetic مجاز |
| عملیات | Login شعبه، تراکنش خواندن و نوشتن، گزارش، جمع و Integration بیرونی تست؛ ترافیک فقط پس از پذیرش آزاد شود. |
| خروجی مورد انتظار / تفسیر | موفقیت HTTP و Body مستند Readiness؛ تراکنش کسب‌وکار مجاز جدا تأیید شود. |
| معیار موفقیت | Owner مسیر، بار و RTA/RPA واقعی را تأیید کند |
| ریسک / Rollback | Health 200 خرابی مالی را پنهان می‌کند؛ Gate ترافیک بسته و Routing امن قبلی با حفظ Write پذیرفته‌شده برگردد. |

```bash
curl --fail --silent --show-error --max-time 10 https://erp.example.internal/health/ready
```

### ۱۱. Monitoring

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | NOC و Owner پلتفرم |
| پیش‌نیاز | پذیرش سرویس و Telemetry فعال DR |
| عملیات | Latency/Error، صف، Storage، امنیت و Backup پایش؛ تغییر نامرتبط Freeze و انحراف ثبت شود. |
| خروجی مورد انتظار / تفسیر | Log اخیر بدون خطای توضیح‌داده‌نشده؛ محتوای حساس منتشر نشود. |
| معیار موفقیت | پنجره مشاهده توافقی پایدار و Job Backup فعال در DR |
| ریسک / Rollback | وقفه خاموش Backup مواجهه تازه می‌سازد؛ Rollout متوقف و سرویس سالم DR حفظ و Escalate شود. |

```bash
journalctl -u erp-api --since "30 minutes ago" --no-pager
```

### ۱۲. Failback

| فیلد | جزئیات Runbook |
| --- | --- |
| مسئول | مدیر تغییر و DBA و Owner سرویس |
| پیش‌نیاز | Primary تعمیرشده مورد اعتماد، Backup جاری DR، Reverse Sync و پنجره مصوب |
| عملیات | جریان معکوس داده، تطبیق Delta، بررسی Sync و Switch فقط طبق رویه مجاز مختص محصول. |
| خروجی مورد انتظار / تفسیر | وضعیت مطابق طرح Failback؛ مقصد Synchronized همراه Quorum، Fencing و بررسی برنامه لازم است. |
| معیار موفقیت | Writer مرجع واحد، سرویس پذیرفته‌شده و حفاظت ازسرگرفته‌شده |
| ریسک / Rollback | Primary قبلی کهنه است؛ پیش از Switch در DR بمانید، پس از Write جدید Reverse Sync برنامه‌ریزی‌شده لازم است، نه Rollback صرف DNS. |

```sql
SELECT synchronization_state_desc,synchronization_health_desc FROM sys.dm_hadr_database_replica_states;
```

زمینه دستورها: Test-NetConnection، Resolve-DnsName و Get-Date در Windows PowerShell 5.1 و Windows Server 2022؛ Get-VMHost در PowerCLI 13.x احرازهویت‌شده و vSphere 8؛ دستور Cluster با Module مربوط FailoverClusters و دسترسی خواندن؛ dcdiag با ابزار AD DS. DMVها برای SQL 2022 و مجوز مناسب Server-state هستند؛ برای DMVهای مرتبط 2022، VIEW SERVER PERFORMANCE STATE لازم است. Linux مبنای Ubuntu 24.04 دارد؛ erp-api و example.internal نام نمونه‌اند و باید از Inventory مصوب جایگزین شوند. دستور شواهد می‌دهد، نه داور عمومی Pass/Fail.

## ۱۲. بازیابی Ransomware از اعتماد شروع می‌شود

![Production آلوده جدا می‌شود؛ نقطه Immutable سالم پیش از بازگشت مرحله‌ای در محیط پاک اعتبارسنجی می‌شود](/assets/img/articles/content/high-availability-backup-disaster-recovery-enterprise-guide/ransomware.svg)

فرض کنید Windows Server، Domain Controller، VMware و SQL آلوده‌اند و احتمال دسترسی به Console بکاپ هم وجود دارد. HA می‌تواند VM رمز‌شده را Restart کند و Replication فایل رمز‌شده یا تغییر منطقی مخرب را منتقل کند. هیچ‌کدام نیت کسب‌وکار پشت Write را نمی‌شناسند. مخزن ایزوله با هویت مستقل، مدیریت محدود و Retention اعمال‌شده مسیر مشترک حمله را کمتر می‌کند؛ ولی سالم‌بودن سیستم‌عامل یا Credential ذخیره‌شده را ثابت نمی‌کند.

ابتدا با تیم Incident و امنیت، شبکه متاثر را مهار، شواهد Forensic را حفظ و مدیریت مورد اعتماد برقرار کنید. از شواهد Endpoint، هویت، شبکه و Audit بکاپ Timeline بسازید؛ اولین Alert رمزنگاری ممکن است بسیار دیرتر از Initial Access باشد. نقاط نامزد پیش از پنجره نفوذ شناخته‌شده انتخاب و در جداسازی Scan و بررسی شوند. نقطه Immutable در برابر برخی تغییرها حفاظت شده است، نه اینکه خودکار Malware نداشته باشد. در Timeline مبهم چند نامزد حفظ کنید.

Clean Recovery Environment از رسانه نصب مورد اعتماد، میزبان Patch‌شده، مدیریت مستقل، DNS/NTP کنترل‌شده، Egress محدود، EDR و Logging و نبود مسیر خودکار به Production آلوده استفاده می‌کند. هویت و Trust جنگل طبق برنامه تخصصی مصوب بازیابی شود؛ Restore ساده DC ممکن است دسترسی مهاجم را هم برگرداند. Secret، Token و Certificate متاثر با ترتیب وابستگی تعویض، مسیر ورود اولیه بسته، داده و برنامه بازیابی و Integrity و تراکنش کسب‌وکار تأیید شوند؛ اتصال مرحله‌ای با پایش و تأیید امنیت و Owner انجام شود.

اگر Validation شکست خورد، همان محیط بازیابی را قرنطینه و شواهد حفظ کنید؛ هنگام امتحان نقطه دیگر دوباره به شبکه وصلش نکنید. تاریخچه ناقص، سرقت داده، نبود کلید یا Persistence کشف‌نشده می‌تواند بازیابی را ناقص کند. ریسک باقی‌مانده و تصمیم کسب‌وکار را مستند کنید و تضمین بازیابی کامل ندهید.

[مرجع: راهنمای CISA #StopRansomware؛ دسترسی خودکار کامل ناشر محدود بود، نسخه جاری پیش از اجرا بررسی شود](https://www.cisa.gov/stopransomware/ransomware-guide)

## ۱۳. امکان بازیابی را پایش کنید، نه فقط روشن‌بودن سرور

Zabbix سیگنال Host، VMware، SQL و شبکه را جمع می‌کند؛ Prometheus متریک Instrumentشده و Grafana نمایش داده منبع را می‌دهد. هیچ‌کدام جای شواهد Job و Restore پلتفرم Backup را نمی‌گیرند. Probe بیرونی مستقل و Dashboard بازیابی برحسب سرویس کسب‌وکار داشته باشید: دسترس‌پذیری جاری، آخرین Backup معتبر، سن داده قابل بازیابی اندازه‌گیری‌شده، Lag، آمادگی DR و آخرین نتیجه تست Restore. هر Alert قابل اقدام Owner، Runbook و مسیر Escalation می‌خواهد.

| سیگنال | Threshold نمونه، نه پیش‌فرض همگانی | تفسیر / اقدام |
| --- | --- | --- |
| ESXi availability / VM restart events | نبود Poll برای دو دقیقه؛ هر Restart ناخواسته HA | از مسیر دوم تأیید و با برق، شبکه و خطای کاربر تطبیق دهید |
| Datastore space / growth | هشدار زیر ۲۰٪، بحرانی زیر ۱۰٪ یا پرشدن پیش‌بینی‌شده پیش از پنجره پاسخ | بایت آزاد، رشد Snapshot و زمان پاسخ مهم‌اند؛ درصد Array بزرگ متفاوت است |
| Storage latency | بیش از 20 ms پایدار برای ده دقیقه، نقطه شروع بررسی | با p95 عادی و SLA مقایسه؛ خواندن، نوشتن و دید Array/Host جدا |
| AG sync / log send / redo | NOT_HEALTHY غیرمنتظره فوری؛ سن صف بیش از نصف RPO هشدار و بیش از RPO بحرانی | تخمین وابسته به نرخ؛ Redo Lag با زیان احتمالی Commit یکسان نیست |
| Backup job / age | هر Job Critical ناموفق؛ سن آخرین داده قابل بازیابی بیش از RPO | Retry پیش از عبور هدف تمام شود؛ موفقیت Job بدون زنجیره معتبر کافی نیست |
| Repository / integrity | پیش‌بینی پرشدن در چهارده روز؛ هر Corruption یا انحراف Immutability | داده قفل و وابستگی Full لحاظ شود؛ حذف کور Retention ممنوع |
| Restore test / DR readiness | تست Critical قدیمی‌تر از سی روز یا ناموفق؛ نبود ظرفیت DR | زمان، نقطه آزموده، بار و پذیرش Owner ثبت شود، نه آیکون سبز Backup |
| WAN / replication lag | شکست دو Probe مستقل؛ Lag بودجه زیان توافقی را مصرف می‌کند | مسیر شعبه تا DR، تنوع مسیر و پهنای باند Catch-up بررسی شود |

از چند هفته اندازه‌گیری عادی و اوج شروع و Persistence، Hysteresis و Maintenance Window را تنظیم کنید. هر Spike کوتاه Latency نباید Page ایجاد کند. نبود Telemetry خطای جداست. تقسیم KB صف بر KB/s اخیر فقط تخمین است و با نرخ صفر یا Burst بی‌معنا می‌شود. RPO یک‌دقیقه‌ای به Telemetry و Scheduling دقیق‌تر از Poll پانزده‌دقیقه‌ای نیاز دارد.

### نمونه Expression در Zabbix 7.0

ابتدا Custom Item عددی backup.age.seconds و backup.job.failed را روی Host نمونه ERP-Backup با Integration احرازهویت‌شده بسازید؛ Script دارای اختیار بالا یا Credential را منتشر نکنید. Age باید جدیدترین نقطه داده مستقلاً قابل Restore را نشان دهد، نه فقط زمان شروع Job. خروجی TRUE شرط Problem است. Recovery Expression، Hysteresis و Action Routing جدا تنظیم شوند.

```text
last(/ERP-Backup/backup.age.seconds)>900
last(/ERP-Backup/backup.job.failed)=1
nodata(/ERP-Backup/backup.age.seconds,10m)=1
```

[منبع: Expression تریگر در Zabbix 7.0](https://www.zabbix.com/documentation/7.0/en/manual/config/triggers/expression)

## ۱۴. بررسی‌های عملیاتی خواندنی و محدودیت آن‌ها

از Session احرازهویت‌شده و حداقل دسترسی خواندن استفاده کنید. این بررسی‌ها تنظیم HA، Datastore، AG یا شبکه را تغییر نمی‌دهند. نام‌ها عمداً آزمایشگاهی‌اند. خطای مجوز خروجی سالم نیست؛ مشکل دسترسی است. Timestamp بگیرید و با Dependency Map تفسیر کنید. دستور تشخیصی Rollback تنظیم ندارد؛ اگر بار یا افشای خروجی حساس ایجاد کرد جمع‌آوری را متوقف کنید.

### VMware و PowerCLI 13.x روی vSphere 8.0

```powershell
Connect-VIServer -Server vcsa.lab.example
Get-VMHost | Select-Object Name,ConnectionState,PowerState
Get-Datastore | Select-Object Name,State,FreeSpaceGB,CapacityGB
Get-VM | Get-Snapshot | Select-Object VM,Name,Created,SizeGB
Get-Cluster | Select-Object Name,HAEnabled,HAAdmissionControlEnabled,HAIsolationResponse
Get-VM | Select-Object Name,@{N='ConsolidationNeeded';E={$_.ExtensionData.Runtime.ConsolidationNeeded}}
```

هدف و خروجی: اتصال امن تعاملی بدون غیرفعال‌کردن اعتبارسنجی Certificate، وضعیت Host، ظرفیت Datastore، فهرست Snapshot، تنظیم HA/Admission/Isolation و Flag مربوط Consolidation. انتظار Hostهای Connected، Datastore قابل دسترس، HA مطابق Policy و Snapshot شناخته‌شده است؛ خروجی خالی در نبود Snapshot معتبر است. FreeSpaceGB را با رشد و Thin Provisioning در Array مقایسه کنید. HAEnabled=true به‌تنهایی N+1 یا حفاظت VM را ثابت نمی‌کند. پیش از تصمیم ترتیب بازیابی، Override هر VM و Event را در Client ببینید.

### SQL Server 2022؛ سلامت AG و تاریخچه Backup

```sql
SELECT ar.replica_server_name, drs.is_local, drs.database_id,
 drs.synchronization_state_desc, drs.synchronization_health_desc,
 drs.is_suspended, drs.log_send_queue_size, drs.log_send_rate,
 drs.redo_queue_size, drs.redo_rate, drs.last_hardened_time, drs.last_redone_time
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id=drs.replica_id;

SELECT TOP (30) database_name,type,backup_start_date,backup_finish_date,
 is_copy_only,has_backup_checksums,first_lsn,last_lsn
FROM msdb.dbo.backupset
WHERE database_name=N'ResilienceLab'
ORDER BY backup_finish_date DESC;

SELECT database_name,MAX(backup_finish_date) AS LastLogBackup
FROM msdb.dbo.backupset WHERE type='L' GROUP BY database_name;
SELECT name,state_desc,recovery_model_desc,log_reuse_wait_desc FROM sys.databases;
```

هدف و خروجی: ردیف هر دیتابیس و Replica قابل مشاهده با صف KB و نرخ KB/s، Backupهای اخیر D/I/L یعنی Full/Differential/Log، آخرین زمان Log و State دیتابیس. برای دید گسترده AG از Primary و برای تاریخچه از msdb هر نود پرس‌وجو کنید؛ History محلی است. Replica نوع Async ممکن است بدون خرابی SYNCHRONIZING باشد؛ نسبت به نقش تفسیر کنید. History خالی یا Log قدیمی بررسی می‌خواهد؛ رکورد msdb وجود فایل را اثبات نمی‌کند. ONLINE/FULL سالم‌بودن زنجیره Backup نیست. مجوز DMV مرتبط SQL 2022 و دسترسی مصوب msdb لازم است؛ صرف Monitoring، sysadmin ندهید.

### Ubuntu 24.04، systemd و ابزار GNU

```bash
df -hT
df -i
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
systemctl is-active erp-api
journalctl -u erp-api --since "30 minutes ago" --no-pager
find /srv/backup -maxdepth 2 -type f -mmin -60 -printf '%TY-%Tm-%Td %TH:%TM %s %p\n'
ip route get 192.0.2.20
curl --fail --silent --show-error --max-time 10 https://erp.example.internal/health/ready
```

هدف و خروجی: مصرف بایت و Inode، Device و Mount، وضعیت واقعی سرویس و Log، فایل Backup تازه با حجم و زمان، Route انتخاب‌شده به آدرس مستندسازی نمونه و Readiness با HTTPS. انتظار فضای بایت و Inode کافی، Mount مورد نظر، سرویس active، فایل معقول، Route مصوب و پاسخ معتبر است. فایل تازه Backup تأییدشده نیست؛ Checksum مرجع معتبر یا Verifier پلتفرم و Restore لازم است. شکست curl می‌تواند DNS، TLS، شبکه یا برنامه باشد؛ برای سبزکردن TLS را دور نزنید. به‌جای 192.0.2.20 آدرس واقعی مصوب DR را بگذارید.

## ۱۵. شش تمرین بازیابی با شواهد و ریسک متفاوت

| تست / هدف | پیش‌نیاز | ریسک / مرز | موفقیت و شواهد ثبت‌شده |
| --- | --- | --- | --- |
| بازبینی مستندات؛ رفع ابهام | Inventory، Owner و معماری جاری | بدون تغییر زنده؛ Secret در سند افشا نشود | Owner تماس، وابستگی و نسخه دستور را تأیید؛ یافته و اقدام تاریخ‌دار |
| Tabletop؛ تمرین تصمیم | سناریو، تسهیل‌گر و تصمیم‌گیر | فقط شبیه‌سازی؛ فرض‌ها نبود دسترسی را پنهان می‌کنند | تصمیم و اعلام زمان‌دار، Log ارتباط و Gap با مسئول |
| Restore جدا؛ اثبات نقطه بازیابی | شبکه جدا، ظرفیت، کلید و کپی Backup | جلوگیری از Route، هویت تکراری و Job خروجی | داده Restoreشده، شواهد صحت، Throughput و نقطه منتخب ثبت |
| بازیابی برنامه؛ اثبات مسیر کاربر | Stack جدا با تمام وابستگی و داده یا حساب Synthetic | فاکتور، ایمیل و پرداخت واقعی ارسال نشود | Owner Login، تراکنش و جمع را تأیید؛ RTA/RPA و نقص ثبت |
| Failover کنترل‌شده؛ اثبات انتقال مالکیت | Topology Replica در Lab/Staging، مجوز و طرح Fencing/Rollback | Split-brain و زیان؛ این مقاله مجوز Failover زنده نیست | Writer واحد، اتصال، بار و Failback تأیید؛ Timeline شواهد و تصمیم |
| تمرین کامل DR؛ اثبات بازیابی سرویس | محیط بازیابی جدا و واقع‌گرایانه، تیم چندتخصصی و Script کسب‌وکار | تداخل ظرفیت یا شبکه؛ تمرین Production اختیار مدیریت و تغییر جدا می‌خواهد | گراف Critical در هدف امضاشده بازیابی و Rollback/Failback تمرین؛ گزارش تأییدشده Owner |

هر گزارش نسخه Runbook، نقطه Backup، محیط، اپراتور، زمان آغاز و پایان، سن واقعی داده، شواهد Integrity و تراکنش، وابستگی مستثنا، سطح بار، نقص و Owner و مهلت پیگیری را مشخص کند. پس از تغییر مهم هویت، شبکه، Storage، دیتابیس، برنامه یا سیاست Backup تکرار شود. موفقیت Tabletop شاهد Throughput Restore نیست. تمرین Production مستقل و با مجوز صریح است؛ نمونه‌های این مقاله Lab یا محیط بازیابی جدا هستند.

## ۱۶. اشتباهاتی که در طراحی HA، Backup و DR سازمان‌ها اتفاق می‌افتد

### VMware HA به‌جای Backup

VM Restartشده هم فایل حذف‌شده دیروز را ندارد.

### Always On مانع هر زیان است

UPDATE اشتباه Commit‌شده به Secondary هم می‌رسد.

### Backup روی Storage تولید

خرابی یک Array، VM و تنها Backup آن را می‌برد.

### نبود Offsite

برق یا آتش ساختمان همه نسخه محلی را قطع می‌کند.

### نبود Immutable یا Offline

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

### تست‌نکردن Restore

موفقیت Job نبود کلید رمزنگاری را پنهان می‌کند.

### RPO/RTO نامشخص

Full شبانه برای سرویس با تحمل زیان پنج دقیقه پیشنهاد می‌شود.

### ظرفیت ناکافی DR

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

### نبود Backup تنظیم شبکه

پس از تعویض Firewall سرور Restoreشده قابل دسترس نیست.

### بی‌توجهی به DNS و AD

API اجراست ولی هیچ‌کس احراز هویت نمی‌شود.

### نبود Dependency Map

ERP پیش از آمادگی Queue و Certificate شروع می‌شود.

### نبود Runbook

ساعت سه دو ادمین Writer متفاوت Promote می‌کنند.

### نبود Monitoring

Log Backup یک هفته خاموش شکست خورده است.

### نبود Failback

DNS کاربران را به Primary قبلی کهنه برمی‌گرداند.

### اعتماد بیش‌ازحد به Snapshot

Delta در حال رشد همان Datastore مورد حفاظت را پر می‌کند.

## ۱۷. جدول تصمیم‌گیری نهایی

| سناریوی سازمان | HA | Backup | DR | ملاحظات RPO/RTO |
| --- | --- | --- | --- | --- |
| شرکت کوچک | براساس اثر اختیاری | مستقل و Offsite | مقصد Restore مستند | زمان Restore دستی صریح پذیرفته شود |
| ۲۰ VM | Compute از نوع N+1 با بودجه | VM و Database-aware | ظرفیت Restore راه دور | ERP انتها به انتها سنجیده شود |
| ۵۰ VM | Compute و DB | مدیریت ایزوله | موج بازیابی | هدف هر سرویس |
| ۱۰۰ VM | چند Failure Domain | زمان‌بندی براساس IO و تغییر | ظرفیت Warm رده‌بندی‌شده | Throughput بازیابی هم‌زمان |
| SQL Server Always On | طراحی پشتیبانی‌شده Quorum/Sync | Full/Diff/Log و کلید | نقش راه دور یا Restore | تفکیک هدف خرابی زیرساخت و خطای منطقی |
| دو Data Center | HA محلی؛ نقش سایت آگاهانه | بیرون مرز مدیریت مشترک | Failover و Failback آزموده | Lag WAN، Fencing و DNS لحاظ شود |
| Kubernetes | کنترل، Worker و وابستگی | etcd و Config و داده PV/برنامه | Cluster بازیابی مستقل | اجرای Pod برابر بازیابی سرویس نیست |
| ۵۰ شعبه | WAN متنوع و سرویس پایه | داده مرکزی و Config تجهیزات | مسیر شعب تا DR | تداوم محلی و همگرایی مسیر |
| سرویس Critical | Failure Domain بررسی‌شده | نقاط پرتکرار معتبر | ظرفیت رزرو و Load-test‌شده | شواهد اندازه‌گیری با تأیید کسب‌وکار |
| در معرض Ransomware | فقط Availability | Immutable/Offline و هویت جدا | گردش‌کار Clean Room | کشف نقطه سالم زمان بازیابی اضافه می‌کند |

### اگر مسئول زیرساخت این سازمان بودم، چه معماری‌ای طراحی می‌کردم؟

Small Business: Hypervisor قابل نگهداری، Backup مستقل Application-aware، نسخه Offsite و Offline محافظت‌شده، مقصد Restore ذخیره قابل دسترس و بازیابی آزموده هویت و Configuration انتخاب می‌کردم. قطعی پذیرفته‌شده و جانشین قادر به اجرای Restore مستند می‌شد. این روش وقتی اقتصادی است که کسب‌وکار بازیابی دستی را بپذیرد؛ تداوم فوری یا تحمل هر خرابی هم‌زمان نمی‌دهد.

Medium Enterprise: VMware HA از نوع N+1 با Storage تاب‌آور، SQL AG توجیه‌شده روی Host جدا، صفحه Backup ایزوله و تاریخچه Offsite Immutable می‌ساختم. رده بازیابی، بودجه Monitoring و On-call و مقصد Warm برای وابستگی Critical ERP مشخص می‌شد. بازیابی کامل سرویس فصلی و Restore منتخب بیشتر تست می‌شد. هزینه شامل ظرفیت ذخیره، License، رشد مخزن و مالکیت پایدار DBA و پلتفرم است؛ افزودن AG بدون مسئول، پیچیدگی را سریع‌تر از تاب‌آوری بالا می‌برد.

Large Enterprise: سایت مستقل با مسیر آزموده WAN، هویت و Trust، HA محلی و دوام داده راه دور مشخص، ظرفیت رزرو Critical، لایه Immutable/Offline با مدیریت جدا و گزینه Cyber Clean Room طراحی می‌کردم. Runbook نسخه‌دار، نقشه سرویس، تمرین و Failback اندازه‌گیری‌شده نگهداری می‌شد. Active-Active فقط برای برنامه با پشتیبانی ایمن توجیه دارد. هزینه عملیاتی شامل تمرین بین‌تیمی، چرخه امنیت و کلید، تست ظرفیت و پاسخ شبانه‌روزی است. خروجی نهایی دیاگرام Rack نیست؛ شاهدی است از میزان احتمالی زیان داده و مسیر بازگشت تراکنش پذیرفته‌شده کسب‌وکار.

## ۱۸. پرسش‌های رایج

### آیا VMware HA جای Backup را می‌گیرد؟

خیر؛ VM حفاظت‌شده را در خرابی تحت پوشش Restart می‌کند و همچنان نسخه تاریخی مستقل لازم است.

### آیا Always On جدول حذف‌شده را برمی‌گرداند؟

حذف Commit‌شده معمولاً به Replica می‌رسد؛ نقطه پیش از حذف در جداسازی Restore و اصلاح داده مجاز اعتبارسنجی شود.

### آیا RPO و RTO نتیجه اندازه‌گیری‌اند؟

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

### آیا Backup تغییرناپذیر الزاماً پاک است؟

خیر؛ Immutability تغییر را در دوره نگهداری محدود می‌کند و بررسی امنیتی نقطه ذخیره‌شده جداست.

### آیا Restart پاد دیتابیس را بازیابی می‌کند؟

فقط اگر داده، Storage، Topology و مسیر Recovery برنامه قابل استفاده بمانند؛ Orchestration بازیابی تاریخی داده نمی‌دهد.

### هر چند وقت DR تست شود؟

دوره با تأیید کسب‌وکار تعیین و پس از تغییر مهم تکرار شود؛ Restore جدا پرتکرار با تمرین سطح سرویس ترکیب شود.

## ۱۹. منابع رسمی و مقاله‌های مرتبط

مستندات در ۶ نوامبر ۲۰۲۶ بررسی شدند. مرز قابلیت‌ها به مستندات محصول متکی است؛ اندازه‌گذاری، سناریو و Threshold مثال مهندسی برای بررسی محلی‌اند. NIST SP 800-34 Rev.1 مرجع بنیادی Contingency Planning است، نه راهنمای تنظیم محصول جاری. دریافت کامل CISA با HTTP 403 محدود و Broadcom TechDocs غیرقابل دریافت بود؛ مقاله Knowledge Base مربوط VMCP قابل بررسی بود. مستندات محدودشده پیش از استفاده عملیاتی مستقیم بررسی شوند. هنگام تهیه مقاله تمرین خرابی VMware/SQL/Kubernetes یا Failover زنده Production انجام نشده است.

[VMware vSphere 8؛ HA، FT، Admission و Isolation](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-availability-8-0.html)

[Broadcom؛ مرز APD/PDL و VMCP](https://knowledge.broadcom.com/external/article/406100/best-practice-for-vsphere-high-availabil.html)

[Microsoft؛ حالت Failover در AG](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/failover-and-failover-modes-always-on-availability-groups?view=sql-server-ver16)

[Microsoft؛ Backup در SQL Server](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/backup-overview-sql-server?view=sql-server-ver16)

[Microsoft؛ بازیابی Point-in-Time](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-sql-server-database-to-a-point-in-time-full-recovery-model?view=sql-server-ver16)

[Microsoft؛ Backup در Secondary براساس نسخه](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/active-secondaries-backup-on-secondary-replicas-always-on-availability-groups?view=sql-server-ver16)

[Microsoft؛ DBCC CHECKDB و Consistency](https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver16)

[Microsoft؛ محدودیت RESTORE VERIFYONLY](https://learn.microsoft.com/en-us/sql/t-sql/statements/restore-statements-verifyonly-transact-sql?view=sql-server-ver16)

[Kubernetes؛ StatefulSet و محدودیت Storage](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)

[Kubernetes؛ Backup و Recovery در etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)

[Docker؛ Quorum و Recovery در Swarm](https://docs.docker.com/engine/swarm/admin_guide/)

[NIST SP 800-34 Rev.1؛ Contingency Planning](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

[CISA؛ راهنمای #StopRansomware](https://www.cisa.gov/stopransomware/ransomware-guide)

[Zabbix 7.0؛ Expression تریگر](https://www.zabbix.com/documentation/7.0/en/manual/config/triggers/expression)

[مرتبط: نصب و تنظیم ESXi 8](/articles/vmware-esxi-8-installation-basic-configuration)

[مرتبط: شبکه vSphere](/articles/vsphere-standard-switch-vs-distributed-switch)

[مرتبط: Job بکاپ SQL Server](/articles/sql-server-automatic-backup-job)

[مرتبط: زنجیره Backup در Veeam](/articles/veeam-forward-vs-reverse-incremental)

[مرتبط: طراحی سازمانی Docker Swarm و Kubernetes](/articles/docker-swarm-vs-kubernetes-enterprise-guide)

[مرتبط: Monitoring با Zabbix و Agent](/articles/zabbix-server-linux-windows-agents-backup)

[مرتبط: Grafana در کنار Zabbix](/articles/grafana-installation-zabbix-integration)

[دانلود آماده‌سازی Lab جدا SQL؛ نیازمند SQLCMD](/downloads/high-availability-backup-disaster-recovery-enterprise-guide/sql-lab-prepare.sql)

[دانلود Restore آزمایشگاهی SQL؛ ابتدا Target ثبت‌شده تنظیم شود](/downloads/high-availability-backup-disaster-recovery-enterprise-guide/sql-lab-restore.sql)

[نسخه کامل فارسی Markdown](/downloads/high-availability-backup-disaster-recovery-enterprise-guide/article.fa.md)

[نسخه کامل انگلیسی Markdown](/downloads/high-availability-backup-disaster-recovery-enterprise-guide/article.en.md)