فرض کنید ساعت ۹ صبح است و تیم منابع انسانی خبر می‌دهد یک مدیر واحد به‌اشتباه حذف شده است. حساب کاربری او در Active Directory دیگر وجود ندارد، دسترسی به فایل‌ها قطع شده و عضویت در گروه‌های سازمانی نیز از بین رفته است. در سناریوی ساده، اگر Active Directory Recycle Bin از قبل فعال بوده باشد، احتمالاً می‌توان Object حذف‌شده را بازیابی کرد و بسیاری از Attributeها و Group Membershipها را برگرداند.

اما سناریوی واقعی همیشه به همین سادگی نیست. اگر حذف قبل از فعال شدن Recycle Bin رخ داده باشد چه؟ اگر مشکل حذف Object نباشد و یک اسکریپت اشتباه صدها Attribute را تغییر داده باشد چه؟ اگر یک Group Policy یا DNS Object خراب شده باشد؟ اگر لازم باشد Microsoft Entra ID، Exchange Online، OneDrive یا Teams هم به نقطه قبلی بازگردند؟ یا اگر حمله باج‌افزاری به خود Backup Repository هم برسد؟

در چنین شرایطی تفاوت میان Recycle Bin و یک راهکار واقعی Backup & Recovery روشن می‌شود. ManageEngine RecoveryManager Plus برای پشتیبان‌گیری و بازیابی Active Directory، Microsoft Entra ID، Microsoft 365 و سرویس‌های مرتبط طراحی شده و به‌جای تکیه صرف بر «حذف‌شدن Object»، امکان بازیابی نسخه‌های قبلی Object، Attribute، Domain Controller و داده‌های Cloud را فراهم می‌کند.

در این راهنما می‌بینیم Recycle Bin چه کاری را خوب انجام می‌دهد، کجا محدود می‌شود، RecoveryManager Plus چه لایه‌ای اضافه می‌کند و برای طراحی یک استراتژی بازیابی هویت سازمانی باید چه معیارهایی را در نظر گرفت.

Active Directory Recycle Bin دقیقاً چه کاری انجام می‌دهد؟

مایکروسافت Active Directory Recycle Bin را برای بازیابی Objectهایی طراحی کرده که به‌صورت تصادفی حذف شده‌اند. وقتی این قابلیت فعال باشد، اطلاعات Link-valued و Non-link-valued Object حذف‌شده حفظ می‌شود؛ بنابراین کاربری که Restore می‌شود می‌تواند Membershipهای گروهی و بسیاری از ویژگی‌های قبلی خود را نیز بازیابد.

اما سه نکته مهم وجود دارد:

• Recycle Bin به‌صورت پیش‌فرض فعال نیست.
• فعال کردن آن برگشت‌پذیر نیست؛ پس از Enable شدن نمی‌توان آن را Disable کرد.
• فقط Objectهایی که بعد از فعال شدن Recycle Bin حذف شده‌اند قابل بازیابی هستند.

یعنی Recycle Bin ابزار بسیار مفیدی است، اما ماهیت آن بیشتر «Deleted Object Recovery» است تا یک سیستم جامع Backup.

مشکل اصلی: همه بحران‌ها «حذف Object» نیستند

در محیط واقعی Active Directory، بخش بزرگی از خطاها به‌جای Delete شدن Object، ناشی از Modification هستند.

برای مثال:

• یک PowerShell Script اشتباه Department صدها کاربر را تغییر می‌دهد.
• Group Membershipهای حساس به‌اشتباه حذف یا اضافه می‌شوند.
• یک GPO تغییر می‌کند و Policy نامناسب روی صدها سیستم اعمال می‌شود.
• DNS Object یا Zone دچار تغییر اشتباه می‌شود.
• Attributeهای Exchange یا Schema تغییر می‌کنند.
• یک Administrator تنظیمات چند OU را در مدت کوتاهی دستکاری می‌کند.

در این موارد چیزی حذف نشده که بتوان آن را از Recycle Bin برگرداند. سؤال اصلی این است: «این Object یا Attribute یک ساعت، یک روز یا یک هفته قبل چه وضعیتی داشت؟»

این دقیقاً جایی است که Versioned Backup و Rollback معنا پیدا می‌کند.

RecoveryManager Plus چه تفاوتی ایجاد می‌کند؟

RecoveryManager Plus از تغییرات Active Directory نسخه نگه می‌دارد و امکان Restore در سطح Object و حتی Attribute را فراهم می‌کند. در مستندات فعلی ManageEngine، این محصول می‌تواند از Domain Controllerها و Objectهایی مانند User، Group، GPO، OU، Computer، DNS، Contact و Schema پشتیبان بگیرد و نسخه‌های قبلی آن‌ها را برای بازیابی نگه دارد.

در حالت Granular Restore، لازم نیست کل Object را به نسخه قدیمی برگردانید. می‌توان فقط Attribute مشخصی را Restore کرد. برای مثال اگر فقط Department یا Group Membership اشتباه شده است، بازیابی می‌تواند محدود به همان بخش باشد.

این تفاوت برای محیط‌های Production مهم است؛ زیرا بازگرداندن یک Object کامل ممکن است تغییرات صحیح دیگری را هم از بین ببرد.

مقایسه Recycle Bin و RecoveryManager Plus

Recycle Bin را حذف نکنید؛ آن را لایه اول Recovery بدانید

نتیجه این مقایسه این نیست که Active Directory Recycle Bin بی‌فایده است. برعکس، در بسیاری از حذف‌های تصادفی سریع‌ترین راه بازیابی همان Recycle Bin است.

طراحی درست به‌جای «Recycle Bin یا Backup»، مدل Recycle Bin + Backup است:

1. Recycle Bin برای بازیابی سریع حذف‌های ساده.
2. Versioned Backup برای Modification و Rollback.
3. Domain Controller Backup برای Disaster Recovery.
4. Repository جدا و امن برای Cyber Resilience.
5. Runbook و تست دوره‌ای برای اطمینان از قابلیت بازیابی.

این نگاه با مفاهیم RPO و Disaster Recovery Plan نیز هم‌راستا است: داشتن Backup به‌تنهایی کافی نیست؛ باید بدانید تا چه نقطه‌ای از داده و در چه مدت زمانی باید سرویس را برگردانید.

Rollback چه زمانی از Restore مهم‌تر است؟

Restore معمولاً برای برگرداندن Object یا Attribute مشخص استفاده می‌شود. Rollback زمانی مهم می‌شود که تعداد زیادی تغییر در یک بازه کوتاه رخ داده باشد.

فرض کنید Script اشتباه در ساعت ۱۴:۱۰ اجرا شده و صدها User، Group و Attribute را تغییر داده است. اگر بخواهید تک‌تک تغییرات را دستی پیدا و اصلاح کنید، احتمال خطای انسانی بالا می‌رود.

RecoveryManager Plus می‌تواند براساس Restore Point، Scope موردنظر را به وضعیت قبلی برگرداند. در مستندات ManageEngine امکان انتخاب OU، Object Type و حتی Attribute برای Rollback وجود دارد. این یعنی لازم نیست همیشه «کل Directory» به عقب برگردد؛ Scope می‌تواند محدود و کنترل‌شده باشد.

Granular Restore برای جلوگیری از بازگردانی بیش از حد

یکی از مشکلات بازیابی سنتی، Over-Restore است. فرض کنید Display Name کاربر اشتباه شده ولی شماره تلفن و Manager او بعداً به‌درستی تغییر کرده‌اند. اگر کل User Object را به Backup هفته قبل برگردانید، احتمالاً تغییرات صحیح جدید هم از بین می‌روند.

در Granular Restore می‌توان نسخه‌های مختلف Attribute را مقایسه و فقط مقدار موردنظر را Restore کرد. این قابلیت در محیط‌هایی که Objectها دائماً در حال تغییر هستند، بسیار مهم است.

Domain Controller Recovery چرا لایه جداگانه‌ای است؟

بازیابی یک User با بازیابی Domain Controller یک مسئله نیست.

اگر مشکل محدود به Object یا Attribute باشد، Object-level Recovery کافی است. اما در سناریوهایی مانند خرابی شدید DC، Corruption یا Disaster گسترده، باید خود Domain Controller هم قابل بازیابی باشد.

ManageEngine در RecoveryManager Plus امکان Backup از Domain Controllerها و Restore آن‌ها به وضعیت قبلی را ارائه می‌کند. برای طراحی DR باید مشخص کنید:

• کدام DCها Backup می‌شوند؟
• آخرین Full Backup چقدر قدیمی است؟
• Incremental Backup با چه فاصله‌ای انجام می‌شود؟
• Backup Repository در همان Failure Domain قرار دارد یا جداست؟
• Restore واقعی آخرین بار چه زمانی تست شده است؟

Backupی که هیچ‌وقت Restore نشده، بیشتر یک فرض است تا یک کنترل قابل اتکا.

Microsoft Entra ID: Recycle Bin بومی محدودیت زمانی و Scope دارد

در Microsoft Entra ID نیز برخی Objectها Soft Delete می‌شوند، اما این مدل محدودیت دارد. مستندات فعلی Microsoft می‌گویند Objectهای Soft-deleted معمولاً ۳۰ روز در وضعیت قابل بازیابی باقی می‌مانند و همه Object Typeها نیز Soft Delete را پشتیبانی نمی‌کنند. برخی Objectها Hard Delete می‌شوند و باید دوباره ساخته و پیکربندی شوند.

این موضوع در محیط Hybrid اهمیت بیشتری پیدا می‌کند، چون Identity فقط در Active Directory نیست. User، Group، Application، Service Principal، Role، Policy و Device می‌توانند در Entra ID بخشی از زنجیره دسترسی باشند.

RecoveryManager Plus برای Microsoft Entra ID امکان Backup و Restore Object و Attribute، Retention مستقل، Incremental Backup و Rollback را ارائه می‌کند. در نتیجه Recovery Window دیگر صرفاً به Recycle Bin بومی وابسته نیست.

Microsoft 365 Recovery را از Identity Recovery جدا نبینید

یک حساب کاربری ممکن است فقط یک Object در AD نباشد. همان Identity به Exchange Online، OneDrive، SharePoint و Teams متصل است. در Disaster واقعی، بازیابی Account بدون بازیابی Data همیشه کافی نیست.

RecoveryManager Plus در Scope Microsoft 365 از Exchange Online، SharePoint Online، OneDrive for Business و Microsoft Teams پشتیبانی می‌کند. بسته به Workload، امکان Restore در سطح Mailbox، Message، File، Site یا سایر Itemها وجود دارد.

اگر سازمان Microsoft 365 را بخش حیاتی عملیات خود می‌داند، Recovery Plan باید هم Identity و هم Data را در یک Runbook ببیند.

Immutable Backup در برابر باج‌افزار چه نقشی دارد؟

یک اشتباه رایج این است که Backup Repository روی همان زیرساختی قرار گیرد که Production روی آن است. اگر Credentialهای Administrator compromise شوند یا باج‌افزار به Repository دسترسی پیدا کند، Backup نیز ممکن است حذف یا رمزگذاری شود.

ManageEngine برای RecoveryManager Plus امکان ذخیره Backup روی Local، NAS و Repositoryهای Cloud را ارائه می‌کند و برای بعضی Cloud Repositoryها مانند Azure Blob Storage، AWS S3، Wasabi و S3-compatible Storage امکان Immutability را مطرح کرده است.

Immutable Backup به این معنی نیست که سازمان «ضدباج‌افزار» شده است؛ بلکه یک لایه دفاعی ایجاد می‌کند تا مهاجم نتواند به‌سادگی نسخه‌های Recovery را تغییر دهد یا حذف کند.

یک سناریوی عملی: Script اشتباه ۴۰۰ کاربر را تغییر داده است

فرض کنید تیم HR Automation یک Script جدید اجرا می‌کند. به‌دلیل اشتباه در Filter، فیلد Department و Manager برای ۴۰۰ User تغییر می‌کند.

Recycle Bin کمکی نمی‌کند، چون هیچ Objectی Delete نشده است.

مسیر منطقی Recovery می‌تواند چنین باشد:

1. متوقف کردن Script و جلوگیری از Modification بیشتر.
2. مشخص کردن بازه زمانی Incident.
3. باز کردن Restore Point قبل از اجرای Script.
4. فیلتر Userهای درگیر.
5. مقایسه Attributeهای Current و Backup.
6. Restore فقط Department و Manager.
7. تأیید نمونه‌ای چند User قبل از Rollback گسترده.
8. اجرای Recovery.
9. ثبت Incident، Root Cause و اقدام پیشگیرانه.

این سناریو نشان می‌دهد ارزش Backup فقط «برگرداندن Object حذف‌شده» نیست؛ مهم‌تر از آن، توان بازگشت کنترل‌شده از تغییر اشتباه است.

یک سناریوی دیگر: User حذف شده ولی Entra ID هم Sync شده است

در محیط Hybrid، حذف User در Active Directory می‌تواند از طریق Sync به Microsoft Entra ID هم برسد. Microsoft توصیه می‌کند AD Recycle Bin برای محیط‌های Sync‌شده فعال باشد تا Restore همان Object با Source Anchor قبلی انجام شود و Entra ID نیز بتواند Object متناظر را به‌درستی Restore کند.

اما اگر Retention بومی گذشته باشد یا Object/Configuration موردنظر Soft Delete را پشتیبانی نکند، مسیر بازیابی پیچیده‌تر می‌شود. به همین دلیل Backup مستقل Entra ID برای سازمان‌های حساس اهمیت پیدا می‌کند.

RPO و Frequency Backup را بر اساس نرخ تغییر تنظیم کنید

یک Domain با روزانه ۲۰ تغییر با Domainی که هر ساعت صدها Join/Move/Change دارد یکسان نیست.

RecoveryManager Plus امکان Full Backup دوره‌ای و Incremental Backup با Frequencyهای کوتاه‌تر را می‌دهد. برای AD، Full Backup می‌تواند هفتگی یا ماهانه و Incremental Backup می‌تواند حتی ساعتی تنظیم شود.

قاعده درست این نیست که «هرچه Backup بیشتر، بهتر». باید Frequency با Recovery Point Objective، حجم تغییرات، ظرفیت Repository و Criticality سرویس هماهنگ شود.

لایسنس RecoveryManager Plus چگونه محاسبه می‌شود؟

مدل Licensing فعلی RecoveryManager Plus اشتراک سالانه است و Metric براساس Workload متفاوت می‌شود. طبق مستند رسمی ManageEngine:

بنابراین برای استعلام لایسنس باید قبل از Quote، Scope واقعی مشخص شود. برای مثال سازمانی که فقط AD Backup می‌خواهد با سازمانی که AD + Entra ID + Exchange Online + Teams را Backup می‌کند، مدل Sizing متفاوتی دارد.

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

RecoveryManager Plus در معماری AD360 کجا قرار می‌گیرد؟

ManageEngine RecoveryManager Plus را به‌عنوان جزء Backup & Recovery در خانواده AD360 معرفی می‌کند. در معماری Identity Security، محصولاتی مانند ADManager Plus، ADAudit Plus، ADSelfService Plus و RecoveryManager Plus هرکدام نقش متفاوتی دارند:

• ADManager Plus: مدیریت و Governance تغییرات هویت.
• ADAudit Plus: Audit و تشخیص فعالیت‌های حساس.
• ADSelfService Plus: SSPR، MFA و Passwordless.
• RecoveryManager Plus: Backup، Restore و Rollback.

برای دیدن لایه‌های جدیدتر Identity Security نیز مقاله ISPM در AD360؛ از Risk Score تا Attack Path می‌تواند مکمل این بحث باشد.

چه زمانی RecoveryManager Plus ارزش بررسی دارد؟

اگر یکی یا چند مورد زیر در سازمان وجود دارد، Backup تخصصی Identity ارزش بررسی جدی دارد:

• Active Directory بخشی از Tier-0 و سرویس حیاتی است.
• تغییرات AD زیاد و Automation گسترده است.
• Microsoft Entra ID و Microsoft 365 بخش اصلی عملیات هستند.
• RTO و RPO مشخص دارید و باید Recovery قابل‌اندازه‌گیری باشد.
• نیاز به Retention طولانی‌تر از Recycle Bin بومی دارید.
• باید Attribute یا Object را به نسخه مشخص قبلی برگردانید.
• Compliance نیازمند Backup و Audit قابل اثبات است.
• Backup باید در Repository جدا یا Immutable نگهداری شود.
• Restore در سطح Domain Controller هم بخشی از DR Plan است.

Checklist طراحی Backup برای Active Directory و Entra ID

• Active Directory Recycle Bin را در صورت مناسب بودن معماری فعال و مستند کنید.
• تمام Domain و DCهای حیاتی را Inventory کنید.
• Critical Object Typeها مثل User، Group، GPO، OU و DNS را مشخص کنید.
• RPO و RTO را برای Identity جداگانه تعریف کنید.
• Full و Incremental Backup را براساس نرخ تغییر تنظیم کنید.
• Retention را فقط براساس ظرفیت Disk تعیین نکنید؛ الزامات Audit و Recovery را لحاظ کنید.
• Repository را از Production Failure Domain جدا کنید.
• برای Cloud Backup در صورت نیاز Immutability را فعال کنید.
• Restore در سطح Object، Attribute و Domain Controller را تست کنید.
• Runbook مشخص برای Human Error، Ransomware و Disaster داشته باشید.
• Credentialهای Backup Platform را با Least Privilege و MFA محافظت کنید.
• نتیجه Restore Test را ثبت و به‌صورت دوره‌ای بازبینی کنید.

نکات کلیدی

• Active Directory Recycle Bin ابزار بسیار خوبی برای Deleted Object Recovery است، اما جای Backup را نمی‌گیرد.
• اگر مشکل Modification، GPO، DNS، Attribute یا Domain Controller باشد، نیاز به Versioned Backup و Rollback مطرح می‌شود.
• RecoveryManager Plus امکان Object-level و Attribute-level Restore، Rollback و Domain Controller Recovery را ارائه می‌کند.
• Microsoft Entra ID فقط برای بعضی Objectها Soft Delete دارد و Window بومی بازیابی محدود است.
• در محیط Hybrid باید Identity و Data Recovery را هم‌زمان دید.
• Immutable Repository لایه مهمی برای Cyber Resilience است، اما جای Security Controlهای دیگر را نمی‌گیرد.
• Backup بدون Restore Test، تضمین Recovery نیست.

سخن پایانی

اگر Active Directory ستون هویت سازمان شماست، «قابل بازیابی بودن» باید مثل Availability و Security یک Requirement طراحی‌شده باشد، نه یک امید پس از وقوع حادثه.

Recycle Bin برای حذف تصادفی بسیار ارزشمند است، اما Disaster Recovery واقعی باید سناریوهای گسترده‌تری را پوشش دهد: تغییر اشتباه، Rollback، خرابی Domain Controller، Retention طولانی‌تر، Microsoft Entra ID، Microsoft 365 و حتی حمله به Backup Repository.

RecoveryManager Plus این فاصله را با Versioned Backup، Granular Restore، Rollback و پشتیبانی از Workloadهای هویتی و Cloud پر می‌کند. مهم‌تر از خود محصول، طراحی درست Scope، RPO، RTO، Retention و تست بازیابی است.

برای بررسی اینکه RecoveryManager Plus در معماری Active Directory یا Microsoft 365 سازمان شما چه Scope و لایسنسی نیاز دارد، می‌توانید از درخواست دمو و مشاوره مدانت استفاده کنید یا از طریق استعلام لایسنس ManageEngine تعداد User، Mailbox و Siteهای محیط را برای Sizing دقیق ارسال کنید. در صورت نیاز به طراحی DR و نگهداری سرویس نیز برنامه‌های پشتیبانی مدانت در دسترس است.

منابع

• Microsoft Learn – Active Directory Recycle Bin
• Microsoft Learn – Recover from deletions in Microsoft Entra ID
• ManageEngine – Active Directory Backup and Recovery
• ManageEngine – RecoveryManager Plus Restore
• ManageEngine – RecoveryManager Plus Rollback
• ManageEngine – Microsoft Entra ID Backup
• ManageEngine – RecoveryManager Plus Licensing