Назад | Перейти на главную страницу

NTBackup непоследовательно пропускает файлы

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

WARNING: Portions of "\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.000" cannot be read.  The backed up data is corrupt or incomplete.
This file will not restore correctly.
Warning: Unable to open "E:\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.001" - skipped. 
Reason: The system cannot find the file specified.

Warning: Unable to open "E:\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.002" - skipped. 
Reason: The system cannot find the file specified.

...

Warning: Unable to open "E:\OBJECTS\SERVER\STORAGE\DOCS101\SomeFile.012" - skipped. 
Reason: The system cannot find the file specified.

Could not access portions of directory E:\OBJECTS\SERVER\STORAGE\DOCS101.
You may not have permission to open the file, or the directory may be missing or damaged.
Please contact the owner or administrator.

Дело в том, что это разные файлы. Это всегда разные, казалось бы, совершенно случайные группы последовательных файлов. И это тоже не новые файлы. Я видел в этом списке документы, датированные еще 2006 годом. Я проверил, все файлы находятся по путям, указанным в файле журнала, и я могу просматривать их без проблем. Есть идеи, почему это происходит?

РЕДАКТИРОВАТЬ: Это постоянная проблема уже почти три года, и я полностью озадачен.

Эти файлы заблокированы чем-то еще. У вас есть антивирусное сканирование или что-то индексирует файловую систему (локально или через общий ресурс)? Я предполагаю, что chkdsk станет чистым?

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

 net files > opensharedfiles.txt
 handle > handleList.txt

(handle.exe - это инструмент от sysinternals, который вы можете скачать здесь).

opensharedfiles.txt покажет вам, есть ли у кого-то еще удаленно открытый файл, а handleList.txt покажет вам все дескрипторы на машине, что позволит вам определить, какой локальный процесс мог открыть его.

Беззастенчиво украдено у Fulgan @ Arstechnica