none
вопрос об восстановлении AD и не только... RRS feed

  • Вопрос

  • Уже, кажется, на эту тему много написано и сказано, но тем не менее после чтения литературы с целью познания мат. части не создалось ощущение полноты картины в связи с этим возникло несколько вопросов об AD. И также есть много других вопросов.

    По поводу имеющегося в наличии: одна физическая машина с windows server 2008r2 c ролями: AD (один лес, один домен), SQL server, 1С Сервер, файловый сервер. (самая распространенная ситуация в малом бизнесе из-за цены и требований бизнеса).

    Планируется ввести новую физическую  машину на той же ОС (2008 r2, с ней давно все понятно, стабильно, поддержка в полном разгаре) с теми же ролями, сделать ее главной постоянно действующей, а вторую оставить на случай аварии на первой и быстрого возврата в рабочее состояние.

    Самый первый вопрос, но не главный, возник, когда пытаемся обкатать процедуру восстановления ОС на новой машине при загрузке с установочного диска требуются драйвера для рейд массива (на котором установлена ОС). Те самые драйвера для рейда удается обнаружить только в случае, если к машине подсоединен внешний HDD, работающий через USB. А вставленная флешка не распознается никак и не удалось найти ответа: почему. (переформатировали ее даже в NTFS). Есть предположение, что такая материнская плата (Asus P9D-X)

    Далее. По поводу размещения на дисковом пространстве разных вещей. В рейд было принято решение вставить диски, традиционные HDD, но со скоростью вращения 10 000, из серии раптор, размером в 250 ГБ. Такие винчестеры показались наиболее оптимальными по надежности быстродействию и по цене. На созданном массиве рейд 1 принято решение размещать ОС и базы SQL. По поводу баз их 4 штуки размером чуть меньше гигабайта в файловом режиме 1С и пятая база около 10 ГБ (файл сиквеловский). В среднем 5 одновременно работающих пользователей, которые не создают сильной активности,  больше простоя, чем активности. Среди этих баз с одной только работают, может быть, чуть активнее, чем с другими эта база не 10 ГБ, а около 750 МБ. По таким вводным было решено базы размещать на том же рейд1, что и ОС, конечно, предварительно разбив его на 2 одинаковых тома. Также есть еще один диск 1ТБ тоже HDD со скоростью 7500 оборотов для склада файлов. Есть предположение, что базы сиквела на рейде 1 получат больше IOPS, чем на терабайтнике… Так ли это? Или это станет видно в продакшене? Последить за загрузкой диске, если % свободного времени рейда  высок, то все хорошо?

    Теперь вопросы резервирования/восстановления инфраструктуры AD и выполнения задуманного плана воплощения обновленной  общей инфраструктуры. Планируется новую машину ввести в существующий домен. Передать ей FSMO. Понизить старый КД, вывести его из домена, почистить все данные о нем на оставшемся КД. Развернуть по новой ОС на старой машине (с ОС не все в порядке) и ввести ее в домен с ролью резервного КД и резервирования всех остальных ролей.

    1 шаг. Этап ввода новой машины, добавление второго КД в домен. Прежде чем это делать нужно четкое понимание процедуры восстановления до исходного состояния старого КД в случае неудачи. Не найдено в литературе прямого указания обязательно или нет при восстановлении единственного в сети КД использовать службу восстановления каталогов и восстанавливать system state. Самостоятельно был сделан вывод: по желанию, как удобнее. Или раз в неделю бэкапить полное исходное состояние системы с системным томом, каждый день бэкапить system state? И при восстановлении сначала накатить полный бэкап, потом последнее состояние системы из режима восстановления каталогов? А можно и каждый день бэкапить полное состояние с системным томом и восстанавливать обычным способом. Правильно ли был сделан вывод? КД, восстанавливаясь из режима восстановления каталогов, всем соседним контроллерам говорит, что «я пришел из прошлого, у меня не актуальные номера USN и в таблице векторов репликации AD все не актуально, сделайте, пожалуйста, на меня кто-нибудь репликацию, я все приму и пойму». Но, когда соседних КД не существует, это делать не обязательно, не то чтобы нельзя. Можно, но не обязательно?

    2 шаг. Предположим, добавление второго КД успешно свершилось, переданы новому КД роли FSMO,и они между собой успешно реплицируются. Настало время выводить старый КД из домена. И опять, прежде чем это делать нужно четкое понимание процедуры восстановления до исходного состояния обоих КД в случае неудачи. Здесь принципы меняются, КД уже 2. Из изученной мат. части стало понятно только то, что восстановление должно происходить обязательно из режима восстановления каталогов. Можно перед этим восстановиться из «полного» бэкапа, но после этого до попадания в сеть восстанавливаемого КД должно обязательно произойти восстановление system state из режима восстановления каталогов. Но появляется вопрос, как делать восстановление одновременно обоих КД в рабочее состояние, чтоб они продолжали реплицироваться. Есть 2 варианта, которые взаимно исключают друг друга, т.е. нужно выбрать какой-то один, а не брать любой: использовать режим восстановления службы каталогов на обоих или только на одном КД?                 1 вариант - на обоих: рекомендация, она есть рекомендация, сказано использовать, значит использовать. Но предположительно может возникнуть проблема. Когда оба КД после восстановления станут говорить дружно: «Кто-нибудь реплицируйте на меня базу AD!» А «уверенных в себе» КД с записями о том, что: «У меня верные USN записаны, собственные и соседей и в таблице векторов репликации все определенно!» не будет существовать, и как же тогда оба эти КД прореплицируются? Вот здесь и есть сомнение. И приходит вариант 2.                 2 вариант – восстанавливать в режиме восстановления службы каталогов только на одном, например, на том КД, где нет ролей FSMO. Этому варианту хочется отдать предпочтение, но нет уверенности, т.к. не найдено прямого указания об этом в неоднократно изученных мануалах. Принцип репликации AD изучен. Есть некая таблица векторов репликации AD, благодаря которой не происходит зацикливания репликации, но, предположительно, из-за рассогласованности которой на разных КД может случиться USN rollback . И кажется вполне разумным наличие одного КД «уверенного в себе». Т.е. его восстановили обычным способом, служба AD и не подозревает, что КД был восстановлен. У него есть все записи: какой-то там номер USN свой и соседей. В таблице векторов согласно этим значениям есть записи предельных значений USN после репликации (на единицу больше). Кажется, все нормально. Появляется второй КД рассказывающий, я был восстановлен, все у меня не актуально, прореплицируйте на меня всё. Первый КД отвечает: «Да нет проблем…» Берет свои значения и переписывает у второго USN, таблицу векторов. Таблицы векторов репликации согласованы. И потекла новая репликация… Этот подход также вписывается в концепцию AD, в которую по умолчанию видимо при разработке включили условие, что она должна быть отказоустойчивой, т.е. всегда должен оставаться хотя бы один КД с рабочей службой AD. Также есть варианты с одновременным по времени выполнением полного бэкапа обоих КД и последующим одновременным обычным восстановлением и после этого должно все заработать. Такие варианты совсем сомнительны… Какому из двух вариантов довериться или, может оба будут работать?  Времени осваивать виртуализацию и экпериментировать нет, к сожалению.

    Попутный вопросы: когда КД работает, но не подключен к сети у него не может происходить повышения номера USN? Как часто в базе AD происходят изменения гуидов компьютеров -членов домена в работающей доменной сети? И эти обновления гуидов также повышают USN?

    Шаг3. Процедура восстановления утверждена и понятна, выводим второй КД из домена. Как его понизить, вроде бы несложно и понятно. Но как грамотно полностью очистить метаданные о нем на первом КД? (после переустановки на windows на старом КД IP адрес планируется оставить тот же, так можно сделать?)  Дайте, пожалуйста, ссылочку на грамотные исчерпывающие инструкции об этом. И как проверить, полностью ли все очищено?

    Шаг4. Вводим старый КД, на котором переустановили все, в домен. Все вроде понятно и несложно. Стратегию восстановления используем уже из шага1.

    Шаг5.Настраиваем работу в паре по резервированию, копированием всех бэкапов (ОС, SQL) с основного на резервный КД. Настраиваем DFRS на наличие на втором КД всегда актуальной с точностью 5 минут реплики файлов пользователей, исключая бэкапы ОС, SQL, которые реплицируются другими средствами. SQL самостоятельно может по сети передавать. Для копирования бэкапов ОС пришлось придумывать. Хочется , чтоб архивы были на обоих машинах, а архивация windows может только либо в сеть архивировать либо на свой HDD. Придуман запуск скрипта с триггером по событию – записи в журнал события от приложения backup с кодом 734, кажется. Может есть еще варианты по интереснее? Наверно с командной строкой… И кстати, можно ли настроить запуск архивации и в сеть и на свой HDD батником без использования средства архивации?  Если да, будет ли это так же безотказно работать? А дневное резервирование SQL баз с полной моделью восстановления было решено сделать только созданием бэкапов журналов транзакций каждые 5 минут. Весить будут не много, сеть не займут. А, вот, если запустить полный бэкап базы 10 ГБ, в это время сеть просядет хорошо? Или все-таки не отразится. (общая СВИЧ панель только с одним гигабитным выходом – только для главного КД). Но если придумывать соединение обеих машин кабелем напрямую, что возможно, тогда встают вопросы, как вторая сетевая карта отразится на AD? И как настроить грамотное эффективное использование прямого соединения? И надо ли его настраивать, может само нормально будет жить? Дайте, пожалуйста, ссылочки?

    Шаг6. Со всем разобрались, инфраструктура работает, остается вовремя отслеживать некоторые вещи, а вот какие? Как ничего не пропустить, что и где смотреть. Известно только об отслеживании, когда размеры баз SQL вырастут, и, избегая любой фрагментации файлов, (даже 2 фрагмента) перезаливать 1С базы по новой, в базы SQL с новыми первоначальными размерами. Чтобы добиться максимальной производительности. Так  делать нужно, не нужно, можно, нельзя, не обязательно, не имеет смысла? Размеры первоначальные были рассчитаны: сделали полную реструктуризацию базы 1С, прибавили 10%, вот размеры и базы и журнала. Автоприращение сделали в мегабайтах, умножив на 10% полученные размеры. Принцип такой, чтобы минимизировать обслуживание, сделать, насколько есть смысл, базы и лог побольше и долго не касаться, (не перезаливать)… Такой подход обоснован? Но есть еще AD , DFRS  и прочее, о чем может не догадываемся… Подскажете ссылочки, советы, как за всем хозяйством правильно и эффективно и наименее трудозатратно следить?

    21 августа 2014 г. 10:38

Ответы

Все ответы

  • Я бы честно что-нибудь посоветовал, но дальше чем до половины меня не хватило :)
    21 августа 2014 г. 12:50
  • Спасибо за готовность. После размещения поста тоже подумал, что многовато, и что есть негласное правило, задавать в одном посте один конкретный вопрос.
    А самы волнующий и неотложны вопрос про принцип действия репликации в домене и рестор КД:

    Планируется новую машину ввести в существующий домен. Передать ей FSMO. Понизить старый КД, вывести его из домена, почистить все данные о нем на оставшемся КД. Развернуть по новой ОС на старой машине (с ОС не все в порядке) и ввести ее в домен с ролью резервного КД и резервирования всех остальных ролей.

    1 шаг. Этап ввода новой машины, добавление второго КД в домен. Прежде чем это делать нужно четкое понимание процедуры восстановления до исходного состояния старого КД в случае неудачи. Не найдено в литературе прямого указания обязательно или нет при восстановлении единственного в сети КД использовать службу восстановления каталогов и восстанавливать system state. Самостоятельно был сделан вывод: по желанию, как удобнее. Или раз в неделю бэкапить полное исходное состояние системы с системным томом, каждый день бэкапить system state? И при восстановлении сначала накатить полный бэкап, потом последнее состояние системы из режима восстановления каталогов? А можно и каждый день бэкапить полное состояние с системным томом и восстанавливать обычным способом. Правильно ли был сделан вывод? КД, восстанавливаясь из режима восстановления каталогов, всем соседним контроллерам говорит, что «я пришел из прошлого, у меня не актуальные номера USN и в таблице векторов репликации AD все не актуально, сделайте, пожалуйста, на меня кто-нибудь репликацию, я все приму и пойму». Но, когда соседних КД не существует, это делать не обязательно, не то чтобы нельзя. Можно, но не обязательно?

    2 шаг. Предположим, добавление второго КД успешно свершилось, переданы новому КД роли FSMO,и они между собой успешно реплицируются. Настало время выводить старый КД из домена. И опять, прежде чем это делать нужно четкое понимание процедуры восстановления до исходного состояния обоих КД в случае неудачи. Здесь принципы меняются, КД уже 2. Из изученной мат. части стало понятно только то, что восстановление должно происходить обязательно из режима восстановления каталогов. Можно перед этим восстановиться из «полного» бэкапа, но после этого до попадания в сеть восстанавливаемого КД должно обязательно произойти восстановление system state из режима восстановления каталогов. Но появляется вопрос, как делать восстановление одновременно обоих КД в рабочее состояние, чтоб они продолжали реплицироваться. Есть 2 варианта, которые взаимно исключают друг друга, т.е. нужно выбрать какой-то один, а не брать любой: использовать режим восстановления службы каталогов на обоих или только на одном КД?                 1 вариант - на обоих: рекомендация, она есть рекомендация, сказано использовать, значит использовать. Но предположительно может возникнуть проблема. Когда оба КД после восстановления станут говорить дружно: «Кто-нибудь реплицируйте на меня базу AD!» А «уверенных в себе» КД с записями о том, что: «У меня верные USN записаны, собственные и соседей и в таблице векторов репликации все определенно!» не будет существовать, и как же тогда оба эти КД прореплицируются? Вот здесь и есть сомнение. И приходит вариант 2.                 2 вариант – восстанавливать в режиме восстановления службы каталогов только на одном, например, на том КД, где нет ролей FSMO. Этому варианту хочется отдать предпочтение, но нет уверенности, т.к. не найдено прямого указания об этом в неоднократно изученных мануалах. Принцип репликации AD изучен. Есть некая таблица векторов репликации AD, благодаря которой не происходит зацикливания репликации, но, предположительно, из-за рассогласованности которой на разных КД может случиться USN rollback . И кажется вполне разумным наличие одного КД «уверенного в себе». Т.е. его восстановили обычным способом, служба AD и не подозревает, что КД был восстановлен. У него есть все записи: какой-то там номер USN свой и соседей. В таблице векторов согласно этим значениям есть записи предельных значений USN после репликации (на единицу больше). Кажется, все нормально. Появляется второй КД рассказывающий, я был восстановлен, все у меня не актуально, прореплицируйте на меня всё. Первый КД отвечает: «Да нет проблем…» Берет свои значения и переписывает у второго USN, таблицу векторов. Таблицы векторов репликации согласованы. И потекла новая репликация… Этот подход также вписывается в концепцию AD, в которую по умолчанию видимо при разработке включили условие, что она должна быть отказоустойчивой, т.е. всегда должен оставаться хотя бы один КД с рабочей службой AD. Также есть варианты с одновременным по времени выполнением полного бэкапа обоих КД и последующим одновременным обычным восстановлением и после этого должно все заработать. Такие варианты совсем сомнительны… Какому из двух вариантов довериться или, может оба будут работать?  Времени осваивать виртуализацию и экпериментировать нет, к сожалению.

    21 августа 2014 г. 12:57
  • По поводу восстановления - все правильно. Если контроллер был поднять из системстейта или баре металла он будет знать о своем восстановлении и USN rollback вы не получите при любых раскладках. И действительно такая проблема бывает только если контроллера больше одного но поднимать в таком случае надо не посекторно, то есть Acronis true image или типа того принесут вам именно эту проблему (но и с этим можно справиться сняв системстейт с него после раскатки образа). Восстановление невиртуального кд (в 2012 R2 это поправили для виртуалок) его можно поднимать только из SYSTEMSTATE или Bare Metall что я бы вам и рекомендовал.

    Процедура поднятия второго контроллера и передача ролей, абсолютно обычная процедура. Просто почаще делайте dcdiag /q и выводите первый из домена только когда убедитесь, что репликация на второй прошла успешно. 

    Сделайте Bare Metall сервера и в путь!



    21 августа 2014 г. 13:07
  • Про акронис и прочее все понятно, что нужен систем стейт, но был вопрос когда точно он нужен когда не обязательно.
    Что я понял: когда 1КД без разницы, хочешь акронис, хочешь систем стейт, хочешт фулл бэкап?

    и когда 2КД и восстанавливаем в одно время оба через систем стейт из режима восстановления? и они найдутся ? неважно что они будут оба считать себя востановленными просить их отреплицировать а откуда они прореплицируюся в первый раз? каким образом согласуют между собой таблицы векторов репликации?
    (про баре металл вообще не слыхали)

    21 августа 2014 г. 13:26
  • Systemstate нужен всегда.

    Есть такая штука http://technet.microsoft.com/ru-ru/library/cc816878(v=ws.10).aspx для восстановления КД

    21 августа 2014 г. 13:32
  • Из Systemstate не восстановишь весь сервер, АД - да без проблем, а вот для восстановления целого сервера нужен Bare Metal

    http://blogs.technet.com/b/askcore/archive/2011/05/12/bare-metal-restore.aspx

    21 августа 2014 г. 13:34
  • вот спасибо, теперь будем знать как делать бэки! а то не удалось найти однозначного ответа самостоятельно...
    за ссылку тоже спасибо, но (про себя, еще бы кто перевел бы, кроме google, а нормально).
    Когда будут вопросы, наверно сюда же напишу..... 
    21 августа 2014 г. 13:39
  • не сразу увидел второй пост BMR вполне знаком, даже удалось настроить автоматический запуск команды робокопи для репликации образа еще куда-нибудь (по событию бэкап с кодом 754).

    Значит не смотреть один или 2 КД запускать в случае чего тот архив из баре метал потом еще из режима восстановления службы каталогов накатить системстейт сделанный после (наверно лучше после) полного архива?
    21 августа 2014 г. 13:46
  • все равно боюсь неправильно понял.
    Насколько я понял: BMR мы восстановили. Но делать это можно только без использования режима восстановления службы каталогов!
    А нас как раз интересует, вот, мы BMR восстановили, отлично! А после него всегда нужно еще накатить системстейт сделанный после снятия BMR? Неважно один у нас КД или больше вот изначально был такой вопрос?
    Ведь если один КД то вторая процедура вроде бы и не нужна? .... Партнеров репликации нет..... А ОС и AD в том состоянии и так, которое было во время снятия BMR?
    А когда более одного и восстанавливаем оба в одно время после первой процедуры возврата BMR е
    ще накатить системстейт сделанный после снятия BMR? И это сделать на обоих или только на одном?

    Bare Metall - в ангийском варианте не приходилось встречать такие слова, вот и не понятно было, а так эту штуку знаем, как оказалось. только не знали английский вариант.


    • Изменено biscom 21 августа 2014 г. 14:09
    21 августа 2014 г. 14:04
  • Накатываете Bare Metal - перезагружается в DSM и помечаете authoritative restore.

    С systemstate тоже самое восстанавливаетесь - перезагружаетесь в DSM.

    P.S. Пардон - восстановление из systemstate выполняется в DSM. Хотя тоже еще проверить надо, что-то мне подсказывает, что даже если просто в обычном режиме накатить systemstate и после перезагрузки зайти в DSM результат будет такой же...

    21 августа 2014 г. 14:08
  • кажется начинает проясняться: накатывать архив BMR можно по разному, можно как обычно, а можно из режима DSM. Если из это делать из режима DSM (это же и есть режим восстановления службы каталогов?)  тогда нужный нам эффект достигнут?

    И если есть Bare Metal архив, то systemstate восстановление не нужно вобщем то?

    И если есть BMR архив, то 
    при любом раскладе один или два КД, восстанавливаем перезагрузившись  в DSM?
    • Изменено biscom 21 августа 2014 г. 14:29
    21 августа 2014 г. 14:27
  • Смысл DSM в данном случае это зайти в ntdsutil до обычной загрузки и пометить восстановление объектов, так как если он запустится в обычном режиме сразу начнет реплицировать изменения с партнеров.

    Bare Metal включает в себе systemstate. Соответсвенно вы можете восстановить хоть так, хоть так. Сайты Microsoft утверждают, что systemstate можно восстановить только из DSM и потом пометить разделы базы для восстановления, почему-то я другого мнения, но убедится можно только попробовав. Допускаю, что в этом месте я не прав. Хотя вообщем-то для вас это не так важно. Зайдете в DSM =)

    Вот не я один такого мнения, можно просто сервис ADDS тормознуть.



    21 августа 2014 г. 14:54
  • Так вот systemstate не можно, а нужно восстановить только из DSM! В том весь сакральный смысл. Даже если мы сделали полное восставновление, но не пользовались DSM, КД "запустится в обычном режиме сразу начнет реплицировать изменения с партнеров.
    Это полностью справедливо для КД более одного. Но когда один нужно ли обязательно после полного восстановления пользоваться загрузкой DSM?. Партнеров то нет!
    21 августа 2014 г. 15:13
  • Так вот systemstate не можно, а нужно восстановить только из DSM! В том весь сакральный смысл. Даже если мы сделали полное восставновление, но не пользовались DSM, КД "запустится в обычном режиме сразу начнет реплицировать изменения с партнеров.
    Это полностью справедливо для КД более одного. Но когда один нужно ли обязательно после полного восстановления пользоваться загрузкой DSM?. Партнеров то нет!

    Насчет сакрального смысла: вы пробовали восстановить systemstate в обычном режиме остановив службу ADDS?

    Authoritative restore это ручное увеличение USN-номера объекта, какая разница делать его из DSM или нет? Я вот разницы не вижу, скажете в чем научусь еще чему-то получается, тоже неплохо :)

    Вот в 2003 Windows server нельзя было точно так сделать, отсюда видимо и мануалы все об этом пестрят...

    Если партнеров нет то и номер увеличивать не надо, тем более он знает, что он один - кого ему искать? :)

    • Изменено Dmitry_Vasilyev 21 августа 2014 г. 15:31 правописание подкачало
    21 августа 2014 г. 15:22
  • А в каких случаях вобще нужно ручное увеличение USN номера? когда немножко чего-то удалили, по моему тогда...
    Я же про такой вариант и в мыслях не держал и все время имел ввиду только вариант непринудительного восстановления 

    Насчет сакрального смысла: вы пробовали восстановить systemstate в обычном режиме остановив службу ADDS? 
    Нет, не пробовали. Но сакральность заключаются при варианте непринудительного восстановления.
    В этом варианте без DSRM никак. Только после DSRM служба AD скажет, что: "Я восстановлена, и хочу закончить непринудительное восстановление, выполнив репликацию с партнеров" Я в этом уверен, но не пробовал пока... Хочется сначала все понять, чтобы не наступить никуда...
    Принудительное восстановление после наших неудачных манипуляций ВЫ считаете возможно?
    Я на 100% уверен, что про него нужно вспоминать, когда что-то удалили, а изменения прореплицировались везде. Там нужно в ручную помечать все объекты. Это как аварийное восстановление в принципе базы AD. Предположим после наших манипуляций нужно оба КД восстановить. Сначала один восстановить принудительно. Он скажет потом второму, когда востановим второй: "Теперь я главнее и направление репликации брать с меня". И мне ничего не важно. Я все равно на вас буду реплицировать. (это при выходе из строя одного из КД у него не понижены будут а наоборот повышены номера УСН)
     Тогда второй нужно восстанавливать в этого же время с вариантом непринудельного восстановления без sutil , а вместо нее запускать wbadmin. Он потом скажет я был восстановлен, на меня все реплицируйте. Вроде бы сходится, два противопложных варианта как бы должны подружиться? И Не будет никаких несовместимостей таблиц векторов репликации? Но это же, с командой sutil гораздо сложнее... А помечать нужно будет вообще все объекты а не какой то один.... Это разве возможно? И все-таки принудительный вариант, думается, использовать в случае когда восстановить сразу два КД не надо. 

    Начинает казаться, даже в M$ не ответят как нужно восстанавливать одновременно 2 КД...

    "Делалась эта процедура с помощью утилиты ntdsutil. В Windows Server 2008 утилита ntdsutil осталась, но теперь мы не можем принудительно восстановить всю базу данных." о чем и речь, нельзя так сделать. можно только непринудительно и аккуратно.

    • Изменено biscom 21 августа 2014 г. 16:20
    21 августа 2014 г. 16:11
  • А в каких случаях вобще нужно ручное увеличение USN номера? когда немножко чего-то удалили, по моему тогда...
    Я же про такой вариант и в мыслях не держал и все время имел ввиду только вариант непринудительного восстановления 

    Насчет сакрального смысла: вы пробовали восстановить systemstate в обычном режиме остановив службу ADDS? 
    Нет, не пробовали. Но сакральность заключаются при варианте непринудительного восстановления.
    В этом варианте без DSRM никак. Только после DSRM служба AD скажет, что: "Я восстановлена, и хочу закончить непринудительное восстановление, выполнив репликацию с партнеров" Я в этом уверен, но не пробовал пока...

    Раз уверены, тогда в бой :)

    А вот я ссылочку вам приведу http://technet.microsoft.com/en-us/library/cc772519(WS.10).aspx

    вона че пишут

    Whenever you perform a full server recovery of a domain controller, you perform a nonauthoritative restore of Active Directory Domain Services (AD DS). Про DSRM ни слова :)

    DSRM не нужен для nonauthoritative. Хотите делайте через него, но не надо утверждать что работать будет только из него.

    21 августа 2014 г. 17:08
  • Да, понятно теперь это, насчет этого больше не возражаю )

     я читал http://technet.microsoft.com/en-us/library/cc772519(WS.10).aspx но только на русском, то же самое "При выполнении полного восстановления контроллера домена автоматически выполняется непринудительное восстановление доменных служб Active Directory. " и этот первый абзац видно невнимательно читал.

    идем дальше теперь,вопрос все равно еще не закрыт ))

    мы сделали в одно время для двух КД full server recovery и после него нужно  еще что-то делать, чтобы AD были на
    обоих КД в содружестве, реплицировались?

    2) вопрос причастный к восстановлению:

    при загрузке с установочного диска требуются драйвера для рейд массива (на котором установлена ОС). Те самые драйвера для рейда удается обнаружить только в случае, если к машине подсоединен внешний HDD, работающий через USB. А вставленная флешка не распознается никак и не удалось найти ответа: почему. (переформатировали ее даже в NTFS). Есть предположение, что такая материнская плата (Asus P9D-X)

    22 августа 2014 г. 5:44
  • 1) Это что за ситуация когда вам два КД и обязательно в одновременно надо поднять?

    Достаточно одного бэкапа и одного восстановления, второй контроллер можно и руками почистить.

    2) Ну хорошо хоть внешний винчестер распознается, у меня бывало такое что приходилось напрямую в SATA втыкаться. Вопрос к BIOS и прошивке.


    22 августа 2014 г. 7:39
  • 1) Ситуация ровно следующая.

    Когда будет настроено 2 КД нормально работающих в паре, будет задача выводить старый контроллер из домена и чистить о нем данные. Предполагается, чтобы зарезервировать от неправильных действий на этом шаге инфраструктуру для последующего восстановления. 
    Слово одновременно, может ни к чему. Ну предположим восстановили одну основную машину. вторую в сеть не подключаем, через какое то время ну или опять же сразу (разницы для нас нет) восстанавливаем вторую машину? как они себя поведут после этого, адекватно?
    Второй можно руками?.... Это как?... Предпочел бы все равно фул бэкап рекавэри ....

    2) БИОС сразу нужно перепрошивать? или пробовать найти нужную настройку какую нибудь и примерно как и о чем настройка должна быть? (рэйд аппаратный делался не моими руками, не хочется после перепрошивки его изучать как создать, потом создавать)

    22 августа 2014 г. 8:53
  • 1)Смысл в том, что домен и лес поднимается прекрасно из одного бэкапа, не обязательно для этого восстанавливать второй контроллер, упоминания о нем можно просто удалить с сервера. А потом просто ввести новый контроллер. Смысл двух контроллеров - не потерять базу.

    Я честно и с самого начала вас не очень понимал, а сейчас и подавно перестал.

    У вас есть 1 контроллер с ошибками, вы их исправляете, затем вводите второй. В этом месте у вас два ПОЛНОЦЕННЫХ КОНТРОЛЛЕРА, поднять домен можно будет из бэкапа каждого из них. Выводите из домена первый контроллер. Делаете с ним что хотите - возвращаете обратно с новой ОС или не возвращаете. Где тут вопросы?

    2) Аппаратному рэйду на биос все равно. Никаких настроек запрещающих флешки и разрешающих только внешний жесткие диски нет. Я бы посоветовал вам просто подсунуть драйвера так, как у вас получилось уже и не выдумывать. Хотя сам бы начал с перепрошивки биос.

    22 августа 2014 г. 9:07
  • 1)Да полная каша в моей голове согласен.
    Прочитано много, а ложится все не верно.

    Понятно следующее: если получится неудача при выведении старого контроллера.
    То после этого сделать фулл восстановление нового и просто убрать руками старый из него? не пытаться восстановить обратно инфраструктуру которая была? руками можно вывести его не хуже чем спец средством?

    сам перепрошивать биос тем более на плате которая недешевая, на гарантии не собирались в принципе.

    22 августа 2014 г. 9:33
  • Если на втором контроллере кроме роли ADDS ничего больше нет, то вообщем я бы наверное просто новый ввел. Руками он просто вычищается из первого контроллера

    типа того http://fawzi.wordpress.com/2010/11/11/remove-failed-dc-from-ad-manually-never-been-easier/

    Но не забывайте что мы о каких-то мефических ситуациях говорим, два контроллера одновременно вышли из строя - ситуация у вас такая получается :)
    22 августа 2014 г. 9:38
  • Но не забывайте что мы о каких-то мефических ситуациях говорим, два контроллера одновременно вышли из строя - ситуация у вас такая получается :)

    если получится неудача при выведении старого контроллера из инфраструктуры 2 КД
    22 августа 2014 г. 10:52
  • Удалите его вручную с нового :))
    • Помечено в качестве ответа biscom 22 августа 2014 г. 12:22
    22 августа 2014 г. 11:18