آیاBackup به صورتImage صحیح است؟
خیر به علت آنکه در مورد اکتیو دایرکتوری Active Directory ما با دیتابیسی Database که به صورت توزیع شده Distributed است مواجه هستیم. در ضمن فقط با پشتیبان آنلاین Online Backup میتوان از ثبات دیتابیس Database Consistency مطمئن بود. با Image Backup ممکن است شما دوران طولانی یک دیتابیس خراب Defective Database را بک آپ Backup گرفتید و در روزی که مشکلی پیش بیاید و لازم به استفاده از آن Image Backup هستید، Backup قابل اطمینانی در دست ندارید ولی اگر Backup به صورت آنلاین گرفته شود تناقض یا ایراد Inconsistency آن توسط یک پیغام خطا Warning/Error Message نشان داده میشود .
برای فهمیدن بهتر یک مثال کوچک میزنیم :
دیتابیس Database ما در هارد Hard از سکتور ۱ تا ۲۵۰۰ توزیع شده است و حالا نرم افزار Image از سکتور ۱ تا ۲۵۰۰ را Backup کرده و در حالیکه کارش را ادامه میدهد (چون دیتابیس توزیع شده Distributed است و سیستم در حال استفاده است) دیتای روی سکتور ۵۰۰ تا ۱۲۰۰ تغییر میکند. چه اتفاقی در این لحظه رخ میدهد؟
نرم افزار این تغییر را حس یا درک نمیکند (تغییرات را نمیفهمد)، در نتیجه Database روی Image Backup شما از سکتور ۱ تا ۴۹۹ اطلاعات قدیم، از سکتور ۵۰۰ تا ۱۲۰۰ اطلاعات قدیم و از سکتور ۱۲۰۱ تا ۲۵۰۰ اطلاعات قدیم است, اما دیتابیس جدید سیستم شما که در حال کار است از سکتور ۵۰۰ تا سکتور ۱۲۰۰ اطلاعات جدید است .
پسورد اکانت کامپیوتر
وقتی یک کامپیوتر Computer خود را به یک دومین Domain وارد میکند، همه ما درعمل از یک اکانت یوزر User Account استفاده میکنیم تا وارد شویم. اما در حقیقت یک کامپیوتر نیز برای ورود به دومین به یک پسورد Password احتیاج دارد. این پسورد فقط بین کامپیوتر و دومین کنترولر DCمذاکره یا رد و بدل میشود و در یک زمان مشخص تغییر کرده و جدید میشود.چه زمانی دقیق این اتفاق انجام میشود، به راحتی قابل تشخیص نیست. در اینجا باز ایراد خود را نشان میدهد، Image Backup این پسورد را که مربوط به زمان حال است را نیز در خود ذخیره میکند. خوب حساب کنید Imageگرفته میشود و سپس زمان تغییر پسورد میرسد و پسورد جدید جایگزین پسورد قدیمی میشود .
خوب کامپیوتر خراب میشود و حال مجبور میشویم از Image استفاده کرده و به زمانی که Image را گرفتیم بازگردانی Restore کنیم. چه اتفاقی رخ میدهد؟
کامپیوتر دیگر نمیتواند وارد دومین شود یا لاگان Logon کند. چون دومین کنترولر به آن پسورد جدید داده است ولی در Image پسورد قدیم بوده و این پسوردها با هم تفاوت دارند. خوب میتوان برای این مشکل راه حل داشته باشیم و آن این است که یکبار کامپیوتر را از دومین Disjoin کرده و سپس Join کنیم . حالا حساب کنید که شما بالای ۱۰۰ یا بیشتر کلاینت داشته باشید، آیا این ریسک ارزش دارد (فقط تا کنون ما از سمت یک کلاینت صحبت کرده و ماجرا را دیدیم)!!
اما این قانون برای یک سرور Server اینگونه نیست، مانند یک ترمینال سرور Terminal Server ، سرورExchange یا دومین کنترولر Domain Controller و ماجرا طور دیگری است .
این مشکل به ماشینهای ویندوز محدود نمیشود، زیرا که اصل پسورد Password به صورت محلی Local ذخیره میشود که بدون هیچ دخالتی از سمت کاربر User ، تغییر میکنند .
در ضمن غیر فعال کردن پسورد کامپیوتر در شرایط خاصی باید انجام شود، پس اینکار را تا حد امکان انجام ندهید .
How to disable automatic machine account password changes
How to detect and remove inactive machine accounts
Domain member: Disable machine account password changes
Effects of machine account replication on a domain
Domain member: Maximum machine account password age
Threats and Countermeasures
Account Passwords and Policies
مشکل USN-Rollback
در یک محیط اکتیو دایرکتوری که دومین کنترولرهای DCs متعددی وجود دارد، استفاده از تکنیک Image-Backup کار بسیار اشتباهی است یا در حقیقت بهتر بگوییم کاملا اشتباه است و ادمین یا ادمین های آن محیط AD باید هر لحظه منتظر اتفاق باشند. علت آن است که دومین کنترولرها برای داشتن دیتابیس Database یکسان از عملیات Replication استفاده میکنند تا هر کدام یک کپی یکسان از این دیتابیس داشته باشند. در عملیات Replication هر دومین کنترولر DCبرای این که اطلاعات شریک Partner خود را بداند و این عملیات قوی و بدون ایراد انجام شود، برای هر تغییر شی Objectشماره سریال USN - Update Sequence Number اختصاص داده شده و ذخیره میشود و در عملیات Replication انتقال داده میشود. با این کار هر دومین کنترولری بدون آنکه ابهامی برایش بوجود آید، میتواند تشخیص دهد که آیا دیتابیس خودش به روز است یا اینکه باید تغییرات را به دیتابیس خود اعمال کند. دقیقا همین جا Image-Backup به مانند یک زهر عمل میکند و کشنده است. برای اینکه مطلب را درک کنیم این اتفاق را با یک مثال شرح میدهیم .
توجه:
در اینجا به علت اینکه خواننده از یک سری تئوریهای خشک خسته نشود، وارد جزییات نشدیم. فقط منظور این است که اطلاعات بیس را درک کند و خسته نشود .
مثال :
دومین ما به نام Contoso.com میباشد که دارای 3 دومین کنترولر است. ما 3 یوزر User1, User2, User3 جدید میسازیم که با عملیات Replication این یوزرها با موفقیت در همه دومین کنترولرها تکرار Replicatedمیشوند. دومین کنترولر DC01 آخرین شماره سریال USN آن 5001، دومین کنترولر DC02 آخرین شماره سریال USN آن 3501 و دومین کنترولر DC03 آخرین شماره سریال USN آن 7099 میباشند .
از دومین کنترولر DC01 در ساعت 18:00 یک Image-Backup گرفته میشود .
در ساعت 19:30 بر روی دومین کنترولر DC01 یک یوزر جدید User4 ایجاد میشود. همراه با برخی تغییرات ایجاد شده، در حال حاضر، دومین کنترولر دارای آخرین شماره سریال USN=5201 است. اطلاعات با موفقیت با دیگر دومین کنترولرها Replicated شده است .
در ساعت 21:00 ، دومین کنترولر DC01 ، به هر علتی خراب میشود و ما برای برگرداندن آن به شرایط عادی از Image-Backup که در ساعت 18:00 گرفتیم (مرحله ۲) استفاده میکنیم .
در این لحظه دومین کنترولر DC01 تصور میکند وضیت ساعت 18:00 را دارد و فقط User1, User2, User3 را میشناسد و شماره سریال USN=5002 به Object در آینده تخصیص میدهد .
در اینجا هر ادمینی که فکر کند حالا با استفاده از عملیات Replication از طریق DC02 یا DC03 موفق به داشتن User4 میشود، کاملا در اشتباه است. DC02 و DC03 فکر میکنند که User4 در DC01 وجود دارد، زیرا آنها خودشان User4 را از DC01 دریافت کردند. نتیجه این است که DC01 نمیتواند User4 را داشته باشد .
DC01 با یک سری از تغییرات روی Database ،میخواهد اطلاعات خود را با شماره سریال USN=5002 به DC02 و DC03 انتقال دهد. ولی آنها USN=5002 را قبول نمیکنند، چون قبلا DC01 از این شماره سریال USN=5002 استفاده کرده و میدانند که از شماره سریال USN=5201 دیتاهای آن جدید است .
در همین مدت زمان، DC01 عاقبت میفهمد که یک چیزی این بین اشتباه است، پس آغاز به ثبت پیغامهای خطا Errors در Eventlog میکند تا ادمین یا ادمین ها مشکل را حل کنند .
حل کردن این مشکل در اکثر موارد بسیار سخت است، درست است که میتوان DC01 را از اکتیو دایرکتوری Delete کرد و دوباره DC01 جدید اینستال و اضافه کرد، ولی امکان زیاد دارد که این مشکل به محیط اکتیو دایرکتوری صدمه زده باشد. به طور مثال امکان دارد SIDs - Security IDs مربوط به یوزر و کامپیوتر 2 تایی یا دوبله شده باشد و یا اشکالات دیگر .
نکته:
یک راه وجود دارد که دومین کنترولر را از Image بازگردانی کنیم و بعد از بازگردانی این دومین کنترولر بدون هیچ مشکلی با دیگر دومین کنترولرها عملیات Replication را انجام دهد. طریقه به این صورت است که یک Invocation ID جدید تولید میشود و به دیتابیس اکتیو دایرکتوری در عملیات Replication با دیگران شناسایی میشود. این کار توسط چند برنامه بسیار مدرن و بسیار گران انجام میشود. در ضمن این تکنیک گفته شده بر روی VMware یا SAN جواب نمیدهد .
نتیجه:
مشاهده کردیم لذت آسان بودن Image و استفاده از آن برای بازگردانی سرور به مشکلات آینده نمی ارزد و برای همین هربار سوال میشود، میگویم راهی برای ایراد وجود ندارد تا کسی حتی فکر استفاده کردن از Image بر روی دومین کنترولر را در سر نداشته باشد .
DC’s and VM’s – Avoiding the Do-Over 1505: Backing Up and Restoring Active Directory Server with Acronis True Image 1501: Windows 2000/2003 Active Directory is out of Sync After Primary Domain Controller Rollback Distributed File System Replication (DFSR) no longer replicates files after restoring a virtualized server's snapshot How to be effective in backing up and restoring virtual Domain Controller with host-based backup solutions - Sander Berkouwer MVP Disk Image Backups and Multi-Master Databases - Ask Directory Services Blog
Patris_70 edited Revision 4. Comment: farsi display problem
Patris_70 edited Revision 3. Comment: added new links
ممنون جناب پاتریس از مقاله خوب و کاربردی تون.
فقط یک سوال در خصوص رفرنسهای این مقاله داشتم و اینکه ایا مقالات رو از رفرنس خاصی ترجمه می کنید یا برگرفته و تالیف از چند مقاله انگلیسی دیگه هست ؟