Remontnouta.ru

ПК Ремонт техники
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как восстановить контроллер домена

Как восстановить контроллер домена

Неполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях . Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Неполномочное восстановление AD DS

Выполнять неполномочное восстановление будем через бэкап System State нашего КД.

Того же эффекта можно добиться, используя бэкап критически важных томов, а также при восстановлении из полного бэкапа сервера 1 .

Немного теории

Перед началом процесса восстановления контроллера домена необходимо четко себе представлять что же произойдет после, а произойдет следующее:

  1. Система возвратится в состояние на момент снятие бэкапа (это очевидно);
  2. Будет сгенерирован новый DSA Invocation ID;
  3. Текущий пул RID будет сброшен и получен новый;
  4. Произойдет неполномочное восстановление SYSVOL.

Теперь о каждом пункте подробнее, начиная со 2.

DSA Invocation ID

Invocation ID — это уникальный guid-идентификатор базы данных ntds.dit. Сбрасывая этот параметр, контроллер домена сообщает своим «соседям» о том, что он был восстановлен из бэкапа. То есть, по сути, восстановленный КД становится другим источником репликации и ему требуются все изменения в AD, начиная с момента создания бэкапа.

Этот механизм необходим, чтобы избежать отката номеров последовательных обновлений (USN Rollback 2 ), который заключается в следующем.

AD работает таким образом, что между контроллерами домена передаются лишь последние изменения, а не вся база целиком. Каждый КД поддерживает значение USN своих соседей (up-to-dateness vector). Если другой КД вдруг сообщает свой USN и он оказывается выше «запомненного», значит на другом КД произошли изменения и их надо получить посредством репликации данных. Откат к состоянию бэкапа возвращает максимальный последовательный номер изменений восстановленного сервера к меньшему значению. В итоге все другие КД, получая с восстановленного контроллера его USN, будут уверены, что все изменения с него уже реплицированы, ведь их «запомненные» значения USN восстановленного КД будет больше. Все изменения, внесенные в AD на восстановленном КД в промежутке восстановленного USN и «запомненных» USN на других КД, никогда не будут реплицированы на другие контроллеры. Подобная ситуация приведет к рассогласованию баз данных.

RID Pool

Любой принципал безопасности (пользователь, компьютер, группа) в AD имеет уникальный идентификатор, называемый SID. SID, в свою очередь, состоит из нескольких значений, последним из которых является относительный идентификатор — RID.

Если на момент создания резервной копии у КД имеется выданный пул идентификаторов (а на деле в 99% случаев так оно и будет, за исключением ситуации, когда на момент бэкапа пул был израсходован полностью, а связи с хозяином RID для получения нового пула не было), то после восстановления из бэкапа контроллер домена начнет использовать этот пул заново и в лесу появятся принципалы безопасности с одинаковыми SID.

Чтобы такой ситуации не было, во время неполномочного восстановления пул RID сбрасывается и запрашивается новый.

Если же вы восстанавливаете весь лес AD, не забудьте повысить границу выдаваемого пула 3 и сбросить текущие пулы на контроллерах домена 4 .

Переходим к последнему пункту.

SYSVOL restore

Этот момент самый очевидный из всех рассматриваемых. По умолчанию осуществляется именно неполномочное восстановление SYSVOL, чтобы стянуть последние актуальные данные с других КД. Если же необходимо полномочное восстановление 5 , то достаточно поставить соответствующую галочку в мастере WSB или выставить флаг -sysvol, если используете командную консоль.

Когда нужно неполномочное восстановление

Неполномочное восстановление может понадобиться в нескольких ситуациях:

  1. Рабочий КД вышел из строя в связи с аппаратными/программными проблемами и нет желания разворачивать полностью свежий КД (например потому что на старом были какие-то важные приложения и данные);
  2. При откате к снимку виртуальной машины. Если:
    • КД имеет ОС старше Windows Server 2012;
    • Гипервизор не поддерживает VM-Generation ID (все до Windows Server 2012), вне зависимости от гостевой ОС.
Читайте так же:
Где посмотреть драйвера на ноутбуке

Во всех остальных случаях используются другие сценарии восстановления.

Подготовка

К моменту восстановления у вас должны быть:

  1. Резервная копия (я подключил к виртуализованному КД отдельный диск, на который ранее был скопирован бэкап состояния системы);
  2. Пароль DSRM. Придется загружаться в режиме восстановления AD, сервисы будут остановлены, а потому зайти под доменной учеткой не получится, только под локальным админом.

«Операции восстановления, которые выполняются с помощью следующей процедуры, не поддерживаются Майкрософт и должны использоваться только в крайнем случае при отсутствии других вариантов».

Переходим к кульминации.

Восстановление

Хочу отметить, что мой сервер перед операцией восстановления полностью доступен. Если же у вас более сложный случай, то возможно вам понадобится установочный диск операционной системы. В любом случае сценарий восстановления будет отличаться.

Есть несколько способов загрузить сервер в режиме восстановления служб каталогов и я воспользуюсь самым простым из них — нажатие F8 во время загрузки.

bcdedit /set safeboot dsrepair
shutdown -t 0 -r
После выполнения восстановления выполните команду bcdedit /deletevalue safeboot для загрузки в нормальном режиме.
Третий способ — использовать всем знакомую утилиту Msconfig (Загрузка -> Параметры загрузки -> Безопасный режим -> Восстановление Active Directory).
После восстановления также не забудьте вернуть сервер в нормальный режим загрузки.

Итак, нажав F8 дожидаемся загрузки сервера и входим под учетной записью локального администратора:

Неполномочное восстановление AD DS 02

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

Неполномочное восстановление AD DS 03

Не забудьте выбрать Восстановление системы:

Неполномочное восстановление AD DS 04

После этого увидите предупреждение:

Неполномочное восстановление AD DS 05

Подтверждаем, далее нажимаем Восстановить и снова соглашаемся с всплывшим предупреждением. Дожидаемся окончания процесса восстановления и перезагружаемся.

Windows Server — восстановление контроллера домена Windows Server 2012 из резервной копии

Возможно, эта статья была переведена автоматически. Если вы хотите поделиться своим мнением о ее качестве, используйте форму обратной связи в нижней части страницы.

Симптомы

В данной статье предполагается, что резервное копирование было создано с помощью встроенной утилиты резервного копирования Windows сервера. Порядок восстановления контроллера домена с помощью другого программного обеспечения для резервного копирования может отличаться от приведенного ниже. Конкретные инструкции можно найти в документации по программному обеспечению для резервного копирования.

Если контроллер домена Active Directory (DC), на котором работает Windows Server 2012, не может загрузиться в обычном режиме или режиме восстановления служб каталогов (DSRM), может потребоваться восстановить контроллер домена из резервной копии. Эта процедура аналогична процедуре, описанной в разделе Windows Server 2008 R2, но интерфейс среды Windows Recovery (WinRE) изменился. Полное восстановление по все же можно выполнить в среде WinRE.

Чтобы восстановить в резервной копии контроллер домена, который работает под управлением Windows Server 2012, выполните следующие действия.

    Загрузите сервер с носителем ОС в DVD диск и нажмите любую клавишу при появлении соответствующего запроса.

SLN156955_ru__5iconОбратите внимание, что образ восстановления должен находиться в папке Виндовсимажебаккуп на внутреннем или внешнем диске, чтобы быть отобранным.

Последнее изображение выбрано по умолчанию, но при желании вы можете выбрать более раннюю версию.
SLN156955_ru__8I_RestoreDC3_JP_V1a

При необходимости нажмите кнопку Advanced (дополнительно ), чтобы установить драйвер или выполнить поиск образа в сети.
SLN156955_ru__9I_RestoreDC4_JP_V1a

Если вы хотите предотвратить переформатирование некоторых дисков, нажмите « Исключить диски » и выберите диски, которые вы не хотите переформатировать. Нажмите кнопку OK.
SLN156955_ru__111375824508768.exclude-disks

Начнется восстановление.
SLN156955_ru__141375824736512.in-progress

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

Разрешение

SLN156955_ru__15cloud (Custom) (Custom)

Найти дополнительные Ресурсы продуктов

Посетите веб-узел и обратитесь в службу технической поддержки Назначают

Восстановление виртуализованного контроллера домена

Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим non-authoritative или потребуется воспользоваться режимом authoritative.
Разница между этими двумя режимами заключается в том, что при режиме восстановлении non-authoritative контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. А при authoritative восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.
В большинстве сценариев восстановления вам потребуется режим non-authoritative, поскольку в среде имеется несколько контроллеров домена. (Кроме того, authoritative восстановление может привести к новым проблемам.)

Читайте так же:
Видеодрайвер выдал ошибку и был восстановлен

Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется non-authoritative восстановление, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров.

Чтобы выполнить authoritative восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые будут описаны позже.

Полезно: Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.

Восстановление в режиме «non-authoritative»

  1. Запустить мастер восстановления в консоли Veeam Backup.
  2. Найти нужный контроллер домена.
  3. Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM).
  4. Указать точку восстановления.
  5. Выбрать исходное или новое место восстановления.
  6. Завершить процедуру.

Самое примечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя вот такую последовательность действий:

  1. Восстановление файлов и дисков ВМ.
  2. Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode).
  3. Применение настроек.
  4. Перезапуск в обычном режиме.

Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.

Восстановление контроллера домена из резервной копии с помощью Veeam - 2

Восстановление в режиме «authoritative»

С большой долей вероятности вам не потребуется этот режим восстановления. Однако давайте познакомимся с ним поближе, чтобы вы поняли, почему это так.

Этот режим можно использовать, например, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.). В этой ситуации, разумеется, предпочтительно, чтобы поврежденные котроллеры домена принимали изменения от вновь восстановленного контроллера.

Примечание: Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.

Чтобы выполнить восстановление удаленного объекта или контейнера в режиме authoritative и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:

  1. Выберите в Veeam операцию восстановления ВМ полностью: программа автоматически выполнит стандартное восстановление DC в режиме «non-authoritative» (см. выше).
  2. При втором перезапуске DC откройте мастер загрузки (нажмите F8), выберите пункт DSRM и войдите в систему с данными учетной записи DSRM (та учетная запись, которую вы указали, когда назначали данный компьютер контроллером домена).
  3. Откройте командную строку и запустите утилиту ntdsutil
  4. Используйте следующие команды:
    • activate instance ntds;
    • затем authoritative restore;
    • затем restore object “distinguishedName” или restore subtree “distinguishedName”

Процедура authoritative восстановления SYSVOL (при использовании службы DFSR) осуществляется следующим образом:

  1. Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
  2. При второй загрузке перейдите в ветку реестра HKLMSystemCurrentControlSetServicesDFSR, создайте ключ Restore, а затем создайте строку SYSVOL со значением authoritative.
    Это значение будет считано службой DFSR. Если значение не установлено, по умолчанию производится восстановление SYSVOL в режиме non-authoritative.
  3. Перейдите к HKLMSystemCurrentControlSetControlBackupRestore, создайте ключ SystemStateRestore, затем создайте строку LastRestoreId с любым значением GUID, например, 10000000-0000-0000-0000-000000000000.
  4. Перезапустите службу DFSR.

Восстановление контроллера домена из резервной копии с помощью Veeam - 3

Процедура authoritative восстановления SYSVOL (при использовании службы FRS):

  1. Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
  2. При второй загрузке перейдите в ветку реестра HKLMSystemCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup и измените значение ключа Burflag на 000000D4 (hex) или 212 (dec).

Это обеспечит принудительное копирование данных на контроллеры домена, использующие старую технологию FRS, в «authoritative» режиме. Подробнее о восстановлении FRS можно почитать здесь.

Защитите свои серверы Active Directory с помощью Zmanda

Zmanda — это комплексное решение для аварийного восстановления, которое помогает вам защитить базы данных и контроллеры домена ваших серверов Active Directory. Он обеспечивает восстановление Windows Active Directory (AD) в случае аппаратного сбоя, сбоя программного обеспечения, ошибки пользователя или любого другого события, которое ставит под угрозу Active Directory.

Теперь с упрощенным лицензированием

Или поговорите с нашим менеджером по продажам в 888-496-2632 (США) или 408-732-3208 (INTL)

1 млн
серверы под резервным копированием.

Открытый аудит
Аудиты доступны через Аманду.

Сертификация Coverity Rung 2
Стандарт национальной безопасности для сертификации продуктов для использования в правительстве.

Авторитетное восстановление контроллера домена

Чтобы упростить обширную процессы аварийного восстановления, Zmanda поддерживает автоматическое восстановление серверов Active Directory. В этом процессе настройки реплицируются с восстановленного контроллера домена на все остальные контроллеры домена в вашей корпоративной сети. Этот тип восстановления используется в сценариях, когда один или все контроллеры домена вышли из строя одновременно (например, после атаки программы-вымогателя или вируса) или когда поврежденная база данных NTDS.DIT ​​реплицируется по домену.

ZBA упрощает процесс резервного копирования и восстановления | Зманда

Интеграция | Клиент резервного копирования Zmanda Server

Полная интеграция с ZMC

Zmanda справляется со многими сложностями интеграции, сводя к минимуму накладные расходы и текущие усилия, необходимые системным администраторам. Мы также поддерживаем широкий спектр носителей резервного копирования, начиная от экономичное ленточное хранилище современным облачным провайдерам.

Ключевый функции

Резервное копирование в реальном времени
Резервное копирование баз данных Office SharePoint в режиме реального времени, не затрагивая пользователей или приложения.

Бесшовное восстановление
Базы данных можно быстро восстановить с помощью интуитивно понятного интерфейса, работающего по принципу «укажи и щелкни».

Disaster Recovery
Zmanda модернизирует и упрощает защиту файлов с неструктурированными данными и файловых серверов в любом масштабе с помощью новых мощных возможностей, таких как поддержка уровней как полного, так и инкрементного резервного копирования.

VSS и поддержка релизов
Zmanda использует Microsoft Служба теневого копирования тома (VSS) писатель для обеспечения целостности во время горячего резервного копирования.

Масштабирование без забот
Начните с малого и эффективно развивайтесь без прерывистых обновлений благодаря подписке с оплатой по мере использования.

Оптимизация в реальном времени
Планировщик Zmanda оптимизирует резервное копирование на нескольких клиентах, чтобы максимально эффективно использовать сетевые и аппаратные ресурсы.

Особенности

Чем мы вам выгодны?

Гибкие возможности хранения

Zmanda отвечает требованиям аварийного восстановления и нормативным требованиям, храня файлы резервных копий и базы данных на ленте, диске, в сетевом хранилище, оптическом хранилище или в гибридных облаках. Он легко интегрируется с Amazon Web Services, Виртуальная платформа Google, Microsoft Azureи многое другое для длительного хранения, аварийное восстановление, и резервное копирование в облаке.

Стандартные форматы

Zmanda использует международные стандарты данных, такие как формат zip и tar для сжатия данных. Он позволяет создавать архивы резервных копий на уровне файлов, упрощая варианты восстановления и устраняя страх перед блокировками от поставщиков.

Интеллектуальное планирование

Уникальный планировщик оптимизирует уровень резервного копирования для разных клиентов таким образом, чтобы уравнять общее время резервного копирования от одного запуска резервного копирования к следующему. Сетевые и аппаратные ресурсы используются максимально эффективно.

Сжатие и шифрование

С Zmanda вы можете быть уверены, что ваши данные будут сохранены в сжатом формате для оптимизации пространства, в то время как ваши данные никогда не будут доступны для тех, кто не должен иметь к ним доступ.

Отзывы

Мы вкладываем все свои силы в создание самых надежных решений для резервного копирования, и наши клиенты подтверждают нашу приверженность.

Zmanda гарантирует сквозную целостность данных и удобство хранения . Они исправляют наши проблемы и каждый раз очень быстро реагируют.

Марчин Мазурек, директор по инфраструктуре и ИТ-операциям Allegro

У нас стабильная система, всегда обновляемая. Мы хорошо спим.

Леонардо Корато, менеджер по ИКТ в VDP Fonderia

Если вы немного разбираетесь в технических вопросах, я не вижу причин использовать какой-либо другой продукт, кроме Amanda Enterprise.

Йохан Хибинетт, директор по информационной безопасности в Schryver Medical

Часто задаваемые вопросы

Какова цель службы Active Directory Server?

Active Directory хранит информацию об объектах в сети и упрощает поиск и использование этой информации администраторами и пользователями. Active Directory использует хранилище структурированных данных как основу для логической иерархической организации информации каталога. Это хранилище данных, также известное как каталог, содержит информацию об объектах Active Directory. Эти объекты обычно включают общие ресурсы, такие как серверы, тома, принтеры, а также учетные записи пользователей и компьютеров сети.

Зманда — это комплексное решение для аварийного восстановления который помогает вам в защите баз данных и контроллеров домена ваших серверов Active Directory. Он обеспечивает восстановление и резервное копирование Active Directory в случае аппаратного сбоя, сбоя программного обеспечения, ошибки пользователя или любого другого события, которое ставит под угрозу Active Directory.

Зачем нужно делать резервную копию серверов Active Directory?

Вы должны полностью сделать резервную копию Active Directory. Все контроллеры домена могут выйти из строя, может произойти повреждение базы данных, вирусы, программы-вымогатели или другая катастрофа могут уничтожить все контроллеры домена. В этой ситуации вам потребуется восстановление из резервной копии Active Directory.

Чтобы упростить обширные процессы аварийного восстановления, Zmanda поддерживает автоматическое восстановление серверов Active Directory. В этом процессе настройки реплицируются с восстановленного контроллера домена на все остальные контроллеры домена в вашей корпоративной сети. Этот тип восстановления используется в сценариях, когда один или все контроллеры домена вышли из строя одновременно (например, после атаки программы-вымогателя или вируса) или поврежден NTDS. База данных DIT реплицируется в домене. Zmanda помогает предприятиям достичь решений и задач резервного копирования Active Directory — даже во время серьезных сбоев в работе ИТ. ИТ-команды могут рассчитывать на надежные стратегии резервного копирования Active Directory. Zmanda — это мощное предложение для резервного копирования и восстановления Active Directory по более низкой цене, чем вы ожидаете.

Как мне начать пробовать резервные копии Zmanda для активного каталога?

Чтобы ИТ-специалисты могли протестировать Zmanda в демонстрационных средах — мы предлагаем полностью лицензированную версию Zmanda на 14 дней. Пожалуйста, заполните наш Бесплатная пробная форма, и наш отдел продаж поможет вам начать работу.

Каковы основные компетенции Zmanda?

Zmanda также предлагает бесшовное корпоративное резервное копирование для гибридной облачной среды. Zmanda гарантирует, что все критические рабочие нагрузки, такие как серверы, базы данных, приложения и виртуальные машины в гибридных облачных ресурсах, защищены от нарушений безопасности и случайных ошибок.

Zmanda прошла сертификацию для использования государством. Компания Coverity, которая создает автоматизированные инструменты анализа исходного кода, объявила о своем первом списке проектов с открытым исходным кодом, которые были сертифицированы как свободные от дефектов безопасности, и мы очень рады быть в списке, сертифицированном для использования в государственных учреждениях.

Предлагаете ли вы круглосуточную поддержку?

Да, группа технической поддержки Zmanda доступна круглосуточно и без выходных по телефону и электронной почте. Вы можете выбрать наш уровень поддержки Стандартный или Премиум, доступный вам с полным доступом к базе знаний, поддержкой по электронной почте и телефону, управлением обращениями, улучшениями программного обеспечения и обновлениями безопасности. Пожалуйста, посетите- обратитесь в службу поддержки, чтобы связаться с нашей службой поддержки.

Восстановление контроллера домена в режиме «non-authoritative»

Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим «non-authoritative» или потребуется воспользоваться режимом «authoritative». Разница между этими двумя режимами заключается в том, что при режиме восстановлении «non-authoritative» контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам домена обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. При «authoritative» восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.

В большинстве сценариев восстановления вам потребуется режим «non-authoritative», поскольку в среде имеется несколько контроллеров домена. Кроме того, «authoritative» восстановление контроллера домена может привести к новым проблемам. Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется «non-authoritative» восстановление DC, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров домена. Чтобы выполнить «authoritative» восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые описаны ниже.

ПРИМЕЧАНИЕ. Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.

Давайте вернемся к файлам резервных копий, которые были описаны в предыдущей статье. Восстановить контроллер домена из резервной копии Veeam Backup & Replication очень легко. Для этого нужно:

  • Выбрать мастер восстановления в пользовательском интерфейсе
  • Найти нужный контроллер домена
  • Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM)
  • Затем указать точку восстановления
  • Выбрать исходное или новое место восстановления
  • Завершить процедуру

Самое замечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя особый алгоритм:

  • Восстановление файлов и жестких дисков ВМ
  • Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode)
  • Применение настроек
  • Перезапуск в обычном режиме

Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.

1 - Entire VM recovery

Рис. 1. Veeam Backup & Replication: Восстановление ВМ целиком

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup. Вам потребуется заранее подготовленный аварийный загрузочный диск Veeam и доступ к самой резервной копии (на USB-носителе или сетевом диске). Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет. После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний будет полезна.

2 - Veeam Endpoint Backup bare-metal recovery

Рис. 2. Veeam Endpoint Backup: восстановление «на голое железо»

Знакомство с программой Arcserve UDP

Более 20 лет, компания Arcserve разрабатывает превосходные программы для резервного копирования и восстановления информационных ресурсов.

Многие поколения системных администраторов по всему миру используют программные продукты Arcserve Backup, Arcserve UDP и Arcserve RHA

Получить более подробную информацию о программе Arcserve UDP можно в статье » Arcserve UDP — знакомство с Unified Data Protection » на этом сайте.

Вы можете получить бесплатную пробную версию Arcserve, что бы лично убедиться в ее превосходном функционале.

Внимание! Нам важно ваше мнение. Поставьте свою оценку этой статье в верхней части экрана.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector