Исходные данные:
- ОС Windows Server 2003,
- на сервере системный диск и диск с данными,
- диск с данными в несколько сотен GB с большим количеством папок и файлов разного размера (файлов около 2 млн.), на большее количество папок наложены специфические разрешения для доступа пользователей (ACL), как правило входящих в доменные и локальные группы (в общем довольно большая и важная помойка).
В один прекрасный день диск с данными становится не доступен. ОС его видит как диск, назначает ему букву, но данные на нем и его свойства не читаются.
Запускаем проверку на диске с исправлением ошибок:
chkdsk d: /f ,
d - буква диска с данными.
Через 10-15 минут после запуска останавливаем проверку, не дождавшись ее окончания, т. к. такая проверка на нашем объеме будет выполнятся несколько часов. Диск и данные уже доступны, но на них отсутствуют данные ACL. Как показал опыт, разрешения на папках и файлах не будут восстановлены и при завершении проверки. Правильный ACL берем из бэкапа. В нашем случае это Veeam Backup&Replication. Восстанавливаем сервер, используя Instant Recovery, и бэкапим на нем ACL в файл с помощью утилиты командной строки icacls:
icacls d:\folder\* /save c:\temp\AclFile /T /C ,
d:\folder - папка на сбойном диске,
AclFile - файл бэкапа разрешений на объекты в d:\folder,
/T - параметр для работы с вложенными объектами (папками и файлами),
/С - параметр для продолжения работы утилиты при сбоях (нет прав на объект или объект неисправен).
Восстановление Instant Recovery и бэкап ACL занимает 15 минут.
Полученный AclFile копируем на боевой сервер и восстанавливаем разрешения на нем:
icacls
d:\folder\ /restore AclFile /C .
Если для резервирования файлового ресурса используется Symantec BacupExec, то восстановить ACL можно из резервной копии Symantec, указав при создании задания параметр "Restore only the NTFS permissions for files that exist at the destination; do not restore the file content".
Восстановление ACL в нашем случае происходит около двух часов.
После восстановления ACL данные доступны для работы, но диск до сих пор имеет dirty bit, т. е. будет проверятся на ошибки при перезагрузке сервера. Наличие dirty bit можно проверить запросом
fsutil dirty query d: .
Т. к. проверка на нашем объеме будет выполнятся несколько часов, отключаем проверку диска при загрузке ОС:
- chkntfs /x d: ,
- или правим в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager параметр BootExecute. Его значение по умолчанию "autocheck autochk *" изменяем на "autocheck autochk /k: D", где D - буква сбойного диска.
При этом диск все еще имеет dirty bit, т. е. с точки зрения ОС находится в неустойчивом состоянии. Для снятия dirty bit необходимо выполнить полностью проверку диска.
chkdsk d: /f запускаем в нерабочее время.
