فرآیند Authoritative Restore

فرآیند authoritative restore یک Object یا یک container به اشتباه حذف شده را باز گردانی می کند. به عنوان مثال اگر یک OU به صورت اشتباه حذف شود که شامل تعداد بسیاری کاربر، گروه و کامپیوتر ممکن است باشد می توان با استفاده از فرآیند authoritative restore آن اشیاء را بازیابی کرد. در Windows Server 2012 متد های متعددی همانند Active Directory Recycle Bin وجود دارد با این وجود این متد به صورت سنتی یکی از متداول ترین روش های بازیابی است. در اغلب سناریو ها این فرایند شامل دو مرحله می باشد: ۱- انجام یک nonauthoritative restore را روی یک backup اخیر که شامل Object های مناسب بوده و سپس انجام authoritative restore برای Object های حذف شده. بدیهی است با انجام nonauthoritative restore امکان باز گردانی OU حذف شده در مثال فوق وجود ندارد زیرا پس از انجام restore، آن دامین کنترلر با استفاده از Replication به آخرین نسخه تغییرات که شامل حذف شده اشیاء است به روز شده است. بنابراین لازم است بلافاصله پس از nonauthoritative restore، عملیات authoritative restore انجام گردد. در این فرایند، OU حذف شده را با عنوان authoritative مارک می کنیم و با مارک کردن authoritative، شماره ورژن به روز می شود و سایر دامین کنترلر ها تحت فرایند Replication به روز شوند. اگر دامین کنترلری وجود دارد که Replication مربوط به حذف شدن اشیاء را دریافت نکرده است انجام nonauthoritative restore لزومی ندارد. برای بازگردانی یک تمام دامین کنترلر نباید از authoritative restoreاستفاده گردد. امکان بازیابی اشیاء از domain directory partitions، application directory partitions و configuration directory partition به نحو زیر وجود دارد:

  • Domain directory partitions: باید اشیاء مطلوب روی یکی از دامین کنترلر های دامین بازیابی شود.
  • Application directory partitions: باید اشیاء مطلوب روی دامین کنترلری که آن Application Partition را host کرده است بازیابی گردد. اگر تمام Application Directory Partition حذف شده است، لازم است Domain Naming Operation Master بازیابی آن Application Directory Partition صورت گیرد.
  • Configuration directory partitions: روی هر کدام از دامین کنترلر های forest امکان بازیابی وجود دارد.

هموار توصیه می گردد از یک Global Catalog Server برای عملیات Restore استفاده گردد. Global Catalog Server ها دارای یک Replica نوشتنی از دامین و یک Replica خواندنی محدود از دامین های دیگر در Forest دارند و از انجایی که شامل اطلاعات عضویت های گروه های Universal در Forest و تمام گروه های Global در دامین هستند بهترین گزینه هستند.

تعیین اشیاء جهت بازیابی

پیش از انجام بازیابی بهتر است معین کردد کدام اشیاء لازم است بازیابی گردند. برای این منظور می توان از ابزار Ntdsutil برای گرفتن یک Snapshop از datastore و log ها و سپس با ابزار Dsamain آن Snapshot را mount کرد و از یک ابزار Lightweight Directory Access Protocol (LDAP) مشابه ADSI Edit برای مشاهده اشیاء استفاده کرد. مقایسه اشیاء موجود و اشیاء مطلوب سبب می گردد از بازگرداندن چندین نسخه پشتیبان جلوگیری حاصل گردد. برای انتخاب اشیائی که می خواهید authoritative شوند، پایین ترین ساختار ممکن در ساختار درختی را در نظر بگیرید زیرا، به این طریق تعداد اشیائی که به عقب بازگشت داده می شوند حداقل می گردد. به عنوان مثال زمانی که یک OU را restore می کنید، این امر سبب می گردد، علاوه بر اشیاء حذف شده، سایر کاربرانی نیز به وضعیت زمان تهیه نسخه پشتیبان بازگشت پیدا کنند. در بازگردانی کاربران توجه داشته باشید با توجه به Forest Functional Level بازیابی گروه های آن اشتراک کاربری متمایز است. در Windows Server 2003، با توجه به linked-value replication (LVR) مقدار attribute مربوط به Member ها به عنوان یک مقدار واحد Replicate می شود، بنابراین پس از وقوع هر تغییر در عضویت گروه، تمام اعضای آن (مقدار Member attribute) با توجه به Scope گروه Replicate می شود. بنابراین در این شرایط، عضویت ها restore می گردند.

Group Memberships

زمانی که یک authoritative restore انجام می شود، ntdsutil فایل های زیر را جهت بازگردانی عضویت گروه ها ایجاد می کند: ۱) ar_YYYYMMDD-HHMMSS_links_Domain.ldf: فایلی است که برای انجام فرایند ریستور برای دامین تولید می شود. این فایل شامل اطلاعات ارتباطات اشیاء با یکدیگر می باشد که بازیابی می گردند. اگر فرایند روی یک Global Catalog Server انجام می گردد، یک فایل ldf مجزا برای هر دامین موجود در Forest ساخته می شود. با استفاده از Ldifde.exe می توان برای بازگرداندن عضویت گروه های Global و Universal در محیط هایی که شامل pre-LVR هستند استفاده کرد. در محیط هایی که شامل pre-LVR نمی باشند، Ntdsutil عضویت گروه ها را به صورت خودکار بازگردانی می کند اگر و تنها اگر دامین کنترلر تحت ریکاوری یک Global Catalog باشد. اگر ریکاوری شامل اشیائی باشد که عضو گروه های Domain Local باشند، لازم است از فایل متنی ar_YYYYMMDD-HHMMSS_objects.txt برای ساخت یک فایل .ldf جهت بازگردانی membership ها در دامین های اضافی استفاده شود. ۲) ar_YYYYMMDD-HHMMSS_objects.txt: این فایل حاوی لیستی از اشیائی است که به صورت authoritative بازیابی شده اند. این فایل به صورت مستقل برای هر شیئ یا Container ای که برای Restore انتخاب شده باشد ایجاد می گردد. Global Catalog ها اطلاعات اطلاعات Member مربوط به گروه های Domain Local را نگه داری نمی کنند. بنابراین حتی اگر، عملیات Restore روی یک Global Catalog Server صورت پذیرد، لازم است از این فایل جهت بازگردانی عضویت های گروه های Domain Local استفاده کرد. با وجود آنکه در LVR Group ها ntdsutil به صورت خودکار بازگردانده می شوند، بهتر است جهت اطمینان ریکاوری، فایل های .ldf بازبینی گردند.

انجام عملیات

قدم اول: انتخاب recovery domain controller

با توجه به آنکه Replication برای اشیاء حذف شده و یا ویرایش شده روی دامین کنترلری که قصد Restore روی آن را دارید دو مسیر مختلف برای Restore ایجاد می گردد. اگر دامین کنترلری وجود دارد که تغییرات روی آن Replicate نشده است، توصیه می شود از آن دامین کنترلر برای restore استفاده کنید. همچنین علاوه بر آن فاکتور، Global Catalog که در توضیحات فوق به آن اشاره شد در انتخاب دامین کنترلری که جهت ریستور در نظر گرفته می شود دارای اهمیت است. در صورتی که تغییرات به دامین کنترلری که قصد restore روی آن را دارید (به آن recovery domain controller می گوییم)، انجام نشده است، کافی است Inbound Replication را خاموش کنید و عملیات Restore را پیش بگیرد. در غیر این صورت لازم است ابتدا عملیات non authoritative restore صورت گیرد. برای غیر فعال کردن Replication ورودی کافی است مقدار DISABLE_INBOUND_REPL را ۱ کنید. برای این منظور از ابزار repadmin استفاده می کنیم:

repadmin /options <ServerName> +DISABLE_INBOUND_REPL

جهت انجام non authoritative restore با توجه به توضیحاتی که در قسمت non authoritative restore ارائه شده است، عملیات صورت می پذیرد.

قدم دوم: مارک کردن اشیاء

پیش از شروع لازم است: ۱) full distinguished name اشیاء مطلوب را بدانید ۲) اگر ریستور در حالتی است که non authoritative restore انجام شده است، عملیات در DSRM mode صورت می گیرد. ۳) اگر ریستور در حالتی است که تغییرات هنوز Replicate نشده است، عملیات می تواند حتی در normal mode و Stop کردن سرویس Active Directory Domain Services صورت گیرد. اگر عملیات Restore را روی یک Global Catalog Server انجام می دهید Back-link های مربوط به اشیائی که قصد ریستور کردن آن ها را دارید تنها به شرطی ریستور می شوند که، Forward-link های آن ها در Global Catalog وجود داشته باشند. به عنوان مثال؛ مقادیر back-link برای خصیصه ی MemberOf تنها در شرایطی ریستور می شود که FowoardLink آن Member در Global Catalog یا Domain Directory Partition موجود باشد. برای گروه های Domain Local، که خصیصه Member آن در Global Catalog ذخیره نمی شود، لازم است اقدامات دیگری صورت گیرد اگر Recovery Domain Controller در Domain تحت ریکاوری نباشد. برای مارک کردن اشیاء فرایند زیر لازم است صورت گیرد: ۱) ورود به ابزار NTDSUtil با دستور ntdsutil 2) در NTDSUtil وارد کنید: activate instance ntds 3) سپس وارد کنید: authoritative restore 4) برای بازگردانی یک زیردرخت دستور restore subtree <DistinguishedName> را وارد کنید. برای مثال:

restore subtree “OU=Marketing NorthAm,DC=corp,DC=contoso,DC=com”

۵) برای بازگردانی یک شیئ دستور زیر را وارد کنید.

restore object <DistinguishedName>

۶) توصیه می شود از .ldf file برای بازگردانی backlink های Object ها استفاده کنید.

قدم سوم: همگام سازی

با استفاده از دستور repadmin /syncall <DomainControllerName>انجام Replication را Replication Partner های دامین کنترلر آغاز کنید و اطمینان حاصل کنید Replication بین دامین کنترلر های مختلف به درستی انجام می گیرد.

قدم چهارم: بررسی نهایی

اگر Inbound Replication را غیر فعال کرده اید آن را مجددا فعال کنید و سپس ریستور شدن اشیاء و backlink های آن را مورد بررسی قرار دهید.

استفاده از یک فایل LDIF برای ریکاور کردن Backlinkها

سطح دسترسی Domain Admins برای این عملیات کفایت می کند. برای انجام عملیات ریکاوری، کافی به سادگی از دستور زیر استفاده کنید :

ldifde -i -k -f <FileName>

<FileName> نام فایل در Path اجرای دستور می باشد. به عنوان مثال ar_20080609-174604_links_corp.contoso.com.ldf توجه گردد عملیات فوق الذکر عملیات حساسی است و نباید در محیط عملیاتی به منظور آموزش و آزمایش انجام گیرد.

یک دیدگاه در “فرآیند Authoritative Restore

دیدگاه ها بسته شد اند