Directory Services Restore Mode (DSRM) is a Safe Mode boot option for Windows Server domain controllers. DSRM enables an administrator to repair, recover or restore an Active Directory (AD) database. Restarting a domain controller in DSRM takes it offline so it functions only as a regular server.
DSRM is similar to the Safe Mode in the Windows operating system. However, it is only available in Windows Server domain controllers. The DSRM mode is available in these versions of Windows Server:
- Windows Server 2022.
- Windows Server 2019.
- Windows Server 2016.
- Windows Server 2012 R2.
- Windows Server 2008 R2.
- Windows Server 2008.
- Windows Server 2003.
The main purpose of DSRM is to help system admins log in to the system to restore or repair an AD database. To use DSRM, admins must create a DSRM local admin account with a password. They must use that account when they need to sign in to a domain controller with DSRM — during server bootup — and to restore AD backups after a system error or failure. The admin account password rarely changes during the deployment of a domain controller. However, it can be reset for any server in the domain without restarting the server using the Ntdsutil tool.
DSRM vs. Safe Mode
For a Windows Server domain controller, DSRM is not the same as Safe Mode. DSRM is used when the controller attempts to start in Safe Mode and is unable to. In general, DSRM is required only when the AD is damaged and doesn’t allow an administrator to log on using their regular AD credentials. In such situations, the AD does not boot normally, so DSRM is required, especially when performing an AD domain-wide or forest-wide restore.
Process to log in to a DSRM account for admins
To restart a domain controller in DSRM, administrators must log in to the DSRM admin account. The process consists of these steps:
- Boot DSRM, and click on Switch User > Other User.
- As logon account name, type .\Administrator.
- Reset the DSRM password for the .\Administrator account with the Ntdsutil command-line tool.
- If the AD server is not working, reset the DSRM password with the lost-password recovery tool.
When logging in to the DSRM account, the initial logon prompt may show the account name as MyDomain\Administrator. However, that does not work, so the admin user must first click on Switch User and manually type the name .\Administrator.
Manual booting in DSRM is also possible by pressing the F8 key repeatedly after the BIOS power-on self-test screen and before the Windows logo appears. Doing this opens a text menu with advanced boot options, like Directory Services Restore Mode or DS Restore Mode. Admins can select the option and press the Enter key to enter DSRM.
Process to reset the DSRM admin password in Windows Server
When AD is installed on Windows Server and during the promotion process for the domain controller, the install wizard prompts the administrator to choose a DSRM password. This password provides the administrator with a backdoor to the database in case something goes wrong later on. The password is also essential for performing maintenance and recovery tasks in DSRM; however, it does not provide access to the domain or to any services.
If admins forget or lose the DSRM password, they can change it by using the Ntdsutil command-line tool. The tool is integrated with the Setpwd utility that has been part of Microsoft Windows since Windows 2000. The procedure to reset the DSRM admin password in Windows Server is as follows:
- Click Start > Run, type Ntdsutil, and then click OK.
- At the Ntdsutil command prompt, type set dsrm password.
- At the DSRM command prompt, type either reset password on server null to reset the password on the current server or reset password on server servername to reset the password on another server.
- Type the new password.
- At the DSRM command prompt, type q.
- At the Ntdsutil command prompt, again type q to exit.
The DSRM password can be reset for the server the administrator is currently working on or for another domain controller in the domain. Every time the password is changed, a Windows Event ID (4794) is generated so other authorized admins can see these attempts and determine if any attempt was made by a nonadmin or malicious user.
Security risks of DSRM
The password for the DSRM admin account can be exploited by malicious intruders, creating a huge security risk for organizations. For example, threat actors can use the password to create a permanent backdoor into the domain controller. This backdoor enables them to maintain persistence in the enterprise network and access AD at any time to gain entry to sensitive resources and data. They may also steal credentials from AD, manipulate privileged service accounts and intercept traffic packets by using the Local Loop Multicast Name Resolution function in Windows.
In some cases, hackers may also be able to steal privileged account hashes or elevate their privileges by exploiting open vulnerabilities or through social engineering. Forgotten, lost or default DSRM admin account passwords also increase the risk of malware attacks, Lightweight Directory Access Protocol reconnaissance and even domain dominance. Unfettered access to AD can also enable attackers to compromise the organization’s backup process and extract all AD data from the ntds.dit file.
To avoid these risks, admin users must regularly update their DSRM account passwords. In addition, they must not use default passwords. It’s also important to set unique account passwords for each domain controller.
Other good security practices to keep DSRM admin account passwords safe include the following:
- In the Registry, set the value of the HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior registry key to 1.
- In the Registry, ensure that the value of the HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior registry key is not set to 2.
- Monitor Windows Event ID 4794, and set alerts to notify admins if they occur.
Learn what techniques can be used to troubleshoot common issues in AD and tips on replication troubleshooting.
This was last updated in August 2023
Continue Reading About Directory Services Restore Mode (DSRM)
- How Windows 11 Safe Mode works and when to use it
- Get back on the mend with Active Directory recovery methods
- Learn to perform a DNS backup and restore
- DNS server troubleshooting for Linux and Windows
- How to perform an AD group membership backup and restore
Dig Deeper on Microsoft identity and access management
-
What is a domain controller?
By: Gavin Wright
-
Deploy a read-only domain controller for security, speed
By: Damon Garn
-
New Active Directory features coming in Windows Server 2025
By: Brien Posey
-
How to create a local admin account with Microsoft Intune
By: Brien Posey
For Windows Server, Directory Services Restore Mode (DSRM) is a special boot mode to repair or recover damaged Active Directory (AD). If the AD on your Windows Server is so damaged, using DSRM is recommended. In our previous article, we’ve seen how to reset Directory Services Restore Mode password. Now, in this article, we’ll see how to boot Windows Server in Directory Services Restore Mode (DSRM).
DSRM would be the only way to log in to a Windows Server, in case if you can’t login with AD. Also, when you boot into DSRM, the domain controller is taken offline. To login into DSRM, you can only use DSRM password. This is because the DSRM password used is for the local Administrator account. It is authenticated by the local Security Accounts Manager (SAM) database.
Here’s how to boot your Windows Server into DSRM.
Page Contents
How to boot Windows Server in Directory Services Restore Mode (DSRM)
Method 1 – Using MSCONFIG
1. Press + R and type msconfig in Run dialog box to open System Configuration Utility. Click OK.
2. In System Configuration Utility, go to Boot tab. Under Boot options, check Safe boot and then select Active Directory repair. Click Apply, OK.
3. After that, you would immediately see a pop-up, click on Restart in that.
Now your Windows Server will restart and then boot into DSRM.
Method 2 – Using Advanced Recovery Options
1. Right click Start Button or press + X keys and select Settings.
2. In the Settings app, navigate to Update & Security > Recovery and click on Restart now under Advanced startup.
3. Choose a reason to restart and click Continue.
4. You should be now seeing recovery mode interface. Under Choose an option, click Troubleshoot.
5. Moving on, under Advanced options, click on Startup Settings.
6. In the next window, under Startup Settings, click on Restart.
7. Finally, under Advanced Boot Options, select Directory Services Repair Mode and press Enter.
Your system should now restart and boot into DSRM.
That’s it!
RELATED ARTICLES
Режим восстановления служб каталогов — Directory Services Restore Mode
Режим восстановления служб каталогов (DSRM) — функция на Active Directory Контроллеры домена чтобы отключить сервер для аварийного обслуживания, в частности, для восстановления резервных копий объектов AD. Он доступен на Windows Server через расширенное меню запуска, аналогично безопасный режим.
Пароль
В Windows 2000 пароль DSRM обычно создается как ноль значение (пусто), которое также является Консоль восстановления пароль. Начиная с Windows Server 2003, пароль DSRM должен быть определен при повышении уровня контроллера домена.
Любой, у кого есть пароль и имеет доступ к контроллеру домена, может перезагрузить компьютер, скопировать и изменить базу данных Active Directory, а также перезагрузить сервер, не оставляя следов активности. Смена пароля DSRM не может быть написана по сценарию, но может быть выполнена вручную через командную строку; Пароли DSRM также можно автоматически изменять и проверять с помощью Управление привилегированной идентификацией программного обеспечения.[1]
Альтернативы
На Windows Server 2008 R2 была добавлена «корзина Active Directory», которая позволяет в оперативном режиме восстанавливать случайно удаленные объекты AD. Его функциональность напоминает собственный Windows Корзина функция.[2]
Смотрите также
- Список компонентов Microsoft Windows
Рекомендации
- ^ «Безопасность режима восстановления служб каталогов, программное обеспечение Lieberman, дата обращения 7 декабря 2012 г.». Архивировано из оригинал 27 января 2013 г.
- ^ Томпсон, Трой (11 ноября 2015 г.). «Как включить корзину Active Directory». Redmondmag. Получено 2020-10-10.
внешняя ссылка
- Защита пароля DSRM
- Перезапустите контроллер домена в режиме восстановления служб каталогов локально.
В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.
Содержание:
- Развертывание нового контроллера домена AD через репликацию
- Полномочное и неполномочное восстановление Active Directory
- Восстановление контроллера домена AD из system state бэкапа
- Восстановление отдельных объектов в Active Directory
При выходе из строя контроллера домена, даже если у вас актуальный бэкап, нужно выбрать сценарий восстановления, который вы будете использовать. Это зависит от того, есть ли у вас в сети другие исправные контроллеры домена, доступны ли они по сети с площадки со сломанным DC и цела ли база Active Directory на них.
Развертывание нового контроллера домена AD через репликацию
Если у вас развернуто несколько контроллеров домена (а это рекомендуемая конфигурация для Active Directory), вместо восстановления неисправного сервера с ролью DC из бэкапа, бывает проще развернуть на площадке новый контроллер домена.
Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа. Старый контроллер нужно просто удалить из AD (если на вышедшем из строя DC были запущены роли FSMO, нужно их предварительно передать на другой сервер).
После повышения сервера до DC, новый контроллера домена синхронизирует (реплицирует) базу данных ntds.dit, объекты GPO, содержимое папки SYSVOL и другие объекты AD с других DC, оставшихся доступными онлайн. Это самый простой способ восстановления работоспособности DC, который гарантирует что вы не внесете непоправимых изменений в AD.
Полномочное и неполномочное восстановление Active Directory
Есть два типа восстановления службы каталогов Active Directory Domain Services из резервной копии, в которых нужно четко разобраться перед началом восстановления:
- Authoritative Restore (полномочное или авторитетно восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Такие восстановленные объекты будут считаться более новыми другими DC, и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно!!!
При полномочном восстановлении вы потеряете все изменения в AD, произошедших с момента создания бэкапа (членство в группах AD, атрибуты Exchange и т.д.).
- Non-Authoritative Restore (неполномочное или не-авторитиативное восстановление) – способ используется при выходе из строя физического/виртуального сервера, на котором развернут DC. Восстановленный контроллер домена после развертывания из бэкапа сообщает другим DC, что он восстановлен из резервной копии и ему нужны последние изменения в AD (для DC создается новый DSA Invocation ID). Этот способ восстановления можно использовать на удаленных площадках, когда сложно сразу реплицировать большую базу AD по медленному WAN каналу; или когда на сервере имелись какие-то важные данные или приложения.
Восстановление контроллера домена AD из system state бэкапа
Предположим, что в домене имелся только один DC, который стал недоступен вследствие выхода из строя физического сервера. У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.
Подготовьте новый сервер (физический или виртуальный) для развертывания DC из бэкапа:
- На новом сервере должна быть установлена та же самая версия Windows Server, что на неисправном DC
- Выполните чистую установку Windows Server. Не нужно пока задавать ему имя компьютера (hostname) старого DC и IP адрес.
- Установите роль Active Directory Domain Services (не настраивая ее) и компонент Windows Server Backup. Можно установить эти компоненты из Server Manager или с помощью PowerShell:
Install-WindowsFeature -Name AD-Domain-Services, Windows-Server-Backup
Чтобы приступить к восстановлению Active Directory, нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите
msconfig
и на вкладе Boot выберите Safe Boot -> Active Directory repair. Или выполните команды:
bcdedit /set safeboot dsrepair
shutdown /r /t 0
После перезагрузки сервер перейдет в безопасный режим DSRM. Запустите консоль управления Windows Server Backup (
wbadmin.msc
) и в правом меню выберите Recover.
В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).
Выберите диск, на котором находится резервная копия DC, или укажите UNC путь к сетевой папке, содержащей WindowsImageBackup. Например
\\FileServer1\Backup\DC1
.
Если вы хотите использовать для восстановления резервную копию с локального диска, нужно поместить каталог
WindowsImageBackup
в корень диска. Проверить наличие резервных копий на диске с помощью команды:
wbadmin get versions -backupTarget:D:
Выберите дату, на которую нужно восстановить резервную копию.
Укажите, что вы восстанавливаете состояние System State.
Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files). (напоминаю что мы рассматриваем сценарий авторитативного восстановления AD, когда в сети единственный DC, других исправных контроллеров домена нет!!).
Если эта опция отключена, будет выполнено non-authoritative восстановление.
Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.
Согласитесь с еще одним предупреждением:
Windows Server Backup Note: This recovery option will cause replicated content on the local server to re-synchronize after recovery. This may cause potential latency or outage issues.
После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет автоматически изменено на имя DC в бэкапе).
После перезагрузки, войдите на сервер с локальной учтённой записью администратора DSRM. Указав имя пользователя в формате
.\administrator
Теперь можно загрузить DC в обычном режиме, отключив загрузку DSRM из
msconfig
или командой:
bcdedit /deletevalue safeboot
Авторизуйтесь на сервере под учетной записью с правами администратора домена. (если не знаете пароль администратора домена, его можно сбросить).
На данный момент служба ADDS еще не работает. При попытке запустить оснастку ADUC, появится ошибка:
Active Directory Domain Services Naming information cannot be located for the following reason: The server is not operational.
Выводит список опубликованных общих папок на сервере командой:
net share
Как вы видите, отсутствуют сетевые сетевых папки SYSVOL и NETLOGON.
Чтобы исправить ошибку:
- Запустите regedit.exe;
- Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
- Измените значение параметра SysvolReady с 0 на 1;
- Потом перезапустите службу NetLogon:
net stop netlogon & net start netlogon
Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.
Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.
Восстановление отдельных объектов в Active Directory
Если вы случайно удалили какой-то объект в AD, не обязательно восстанавливать его из резервной копии. В Active Directory можно настроить корзину AD, из которой в течении 180 дней (значение по умолчанию для tombstoneLifetime) можно восстановить удаленный объект домена с помощью командлета
Restore-ADObject
или из оснастки Active Directory Administrative Center.
Если время захоронения уже просрочено, или ActiveDirectory RecycleBin не включена, вы можете восстановить отдельные объекты AD в режиме авторитетного восстановления. Для этого в режиме DSRM после восстановления DC из бэкапа нужно воспользоваться утилитой
ntdsutil
.
- Выведите список доступных резервных копий:
wbadmin get versions - Запустите восстановление выбранной резервной копии:
wbadmin start systemstaterecovery –version:[your_version] - Подтвердите восстановление DC (в не-авторитативном режиме);
- После перезагрузки запустите:
ntdsutil -
activate instance ntds -
authoritative restore
Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:
restore subtree "OU=Users,DC=winitpro,DC=ru"
Или один объект:
restore object "cn=Test,OU=Users,DC=winitpro,DC=ru"
Данная команда запретит репликацию указанных объектов с других контроллеров домена и увеличит USN объекта на 100000.
Выйдите из ntdsutil:
quit
Загрузите контроллер домена в обычном режиме и убедитесь, что удаленный объект AD был восстановлен.
Неполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях. Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.
Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.
Содержание
- 1 Неполномочное восстановление AD DS
- 1.1 Немного теории
- 1.1.1 DSA Invocation ID
- 1.1.2 RID Pool
- 1.1.3 SYSVOL restore
- 1.2 Когда нужно неполномочное восстановление
- 1.3 Подготовка
- 1.4 Восстановление
- 1.1 Немного теории
Выполнять неполномочное восстановление будем через бэкап System State нашего КД.
Того же эффекта можно добиться, используя бэкап критически важных томов, а также при восстановлении из полного бэкапа сервера 1.
Немного теории
Перед началом процесса восстановления контроллера домена необходимо четко себе представлять что же произойдет после, а произойдет следующее:
- Система возвратится в состояние на момент снятие бэкапа (это очевидно);
- Будет сгенерирован новый DSA Invocation ID;
- Текущий пул RID будет сброшен и получен новый;
- Произойдет неполномочное восстановление 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.
Примечание: за выдачу пулов относительных идентификаторов отвечает держатель роли FSMO RID Master, о котором я подробно рассказывал в статье RID master — Хозяин относительных идентификаторов.
Если на момент создания резервной копии у КД имеется выданный пул идентификаторов (а на деле в 99% случаев так оно и будет, за исключением ситуации, когда на момент бэкапа пул был израсходован полностью, а связи с хозяином RID для получения нового пула не было), то после восстановления из бэкапа контроллер домена начнет использовать этот пул заново и в лесу появятся принципалы безопасности с одинаковыми SID.
Чтобы такой ситуации не было, во время неполномочного восстановления пул RID сбрасывается и запрашивается новый.
Примечание: может так получиться, что восстанавливать из бэкапа придется хозяина RID. На этот счет Microsoft рекомендует не выполнять восстановление, а захватить все необходимые роли с других КД и вместо утраченного контроллера развернуть другой. Тем не менее, восстановление хозяина RID вполне возможно. Главное, чтобы на момент восстановления хозяина RID остальные КД были реплицированы друг с другом и хотя бы один из их был доступен восстановленному КД для выполнения начальной репликации, иначе роль RID master не стартанет.
Если же вы восстанавливаете весь лес AD, не забудьте повысить границу выдаваемого пула 3 и сбросить текущие пулы на контроллерах домена 4.
Переходим к последнему пункту.
SYSVOL restore
Этот момент самый очевидный из всех рассматриваемых. По умолчанию осуществляется именно неполномочное восстановление SYSVOL, чтобы стянуть последние актуальные данные с других КД. Если же необходимо полномочное восстановление 5, то достаточно поставить соответствующую галочку в мастере WSB или выставить флаг -sysvol, если используете командную консоль.
Когда нужно неполномочное восстановление
Неполномочное восстановление может понадобиться в нескольких ситуациях:
- Рабочий КД вышел из строя в связи с аппаратными/программными проблемами и нет желания разворачивать полностью свежий КД (например потому что на старом были какие-то важные приложения и данные);
- При откате к снимку виртуальной машины. Если:
- КД имеет ОС старше Windows Server 2012;
- Гипервизор не поддерживает VM-Generation ID (все до Windows Server 2012), вне зависимости от гостевой ОС.
Во всех остальных случаях используются другие сценарии восстановления.
Подготовка
К моменту восстановления у вас должны быть:
- Резервная копия (я подключил к виртуализованному КД отдельный диск, на который ранее был скопирован бэкап состояния системы);
- Пароль DSRM. Придется загружаться в режиме восстановления AD, сервисы будут остановлены, а потому зайти под доменной учеткой не получится, только под локальным админом.
Примечание: если пароль DSRM безвозвратно утерян, его можно сбросить 6. Разумеется такой вариант возможен только при локальном входе на КД.
Примечание: если бэкапа системы нет, то все же остается возможность “сообщить” партнерам по репликации о том, что КД был восстановлен. Сделать это можно по инструкции из официальной документации 7. Выполнять эту процедуру нужно аккуратно, убедившись на 100% в корректности завершения всех шагов. Обратите внимание на комментарий в статье:
“Операции восстановления, которые выполняются с помощью следующей процедуры, не поддерживаются Майкрософт и должны использоваться только в крайнем случае при отсутствии других вариантов”.
Переходим к кульминации.
Восстановление
Хочу отметить, что мой сервер перед операцией восстановления полностью доступен. Если же у вас более сложный случай, то возможно вам понадобится установочный диск операционной системы. В любом случае сценарий восстановления будет отличаться.
Есть несколько способов загрузить сервер в режиме восстановления служб каталогов и я воспользуюсь самым простым из них – нажатие F8 во время загрузки.
Примечание: если вам интересно, то второй способ – с помощью утилиты bcdedit, выполнив последовательно команды:
bcdedit /set safeboot dsrepair
shutdown -t 0 -r
После выполнения восстановления выполните команду bcdedit /deletevalue safeboot для загрузки в нормальном режиме.
Третий способ – использовать всем знакомую утилиту Msconfig (Загрузка -> Параметры загрузки -> Безопасный режим -> Восстановление Active Directory). После восстановления также не забудьте вернуть сервер в нормальный режим загрузки.
Итак, нажав F8 дожидаемся загрузки сервера и входим под учетной записью локального администратора:
Вводим пароль DSRM, дожидаемся пока система загрузится.
Не забудьте выбрать Восстановление системы:
После этого увидите предупреждение:
Подтверждаем, далее нажимаем Восстановить и снова соглашаемся с всплывшим предупреждением. Дожидаемся окончания процесса восстановления и перезагружаемся.
На этом восстановление завершено.