Один из моих клиентов имеет Windows Server 2016 и использует wbadmin для создания резервной копии с нуля на некоторых NAS-устройствах Synology с использованием SMB. Это работало в прошлом, где "прошлое" - это несколько неопределенных недель / месяцев назад по разным причинам, и больше не работает. Вполне вероятно, что «что-то» изменилось из-за обновлений NAS, дополнительно установленных пакетов и прочего, но, конечно, никто больше не знает, и это был не я. ;-)
После некоторого тестирования и регистрации с различными версиями SMB, Wireshark, Process Monitor и т.д. Проблема, по-видимому, заключается в том, что по какой-то причине wbadmin может создать необходимые необработанные файлы VHDX для томов для резервного копирования на общем ресурсе NAS, но, похоже, не может инициализировать эти диски и опубликовать на них необходимую файловую систему. Процесс резервного копирования всегда прерывается довольно рано после создания одного файла VHDX с фиксированным размером, например, 4 МБ для Esp.vhdx или 6 МБ для VHDX, содержащего C: . Это просто зависит от настроек резервного копирования, таких как -allCritical vs. only -include:C:
Всякий раз, когда возникает эта проблема, в программе просмотра событий появляется следующее сообщение об ошибке:
Log Name: System
Source: Virtual Disk Service
Date:[...]
Event ID: 9
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer:[...]
Description:
Unexpected provider failure. Restarting the service may fix the problem. Error code: 80070037@02000014
Я не вижу каких-либо других соответствующих сообщений об ошибках в Wireshark в SMB-коммуникации, Samba регистрирует NAS или Process Monitor, но особенно в последнем я не уверен, потому что Windows делает много вещей автоматически в фоновом режиме это прекрасно, чтобы потерпеть неудачу. NAS предоставляет некоторые протоколы Samba, что тоже немного странно, поскольку он регистрирует большое количество SMB-соединений для пользователя, который не настроен для использования wbadmin . Но поскольку все протестированные пользователи имеют одинаковые / все разрешения для этой цели резервного копирования, я не думаю, что это является частью проблемы, и я также тестировал с разными пользователями.
Интересно то, что я могу прикрепить автоматически созданные файлы VHDX с помощью wbadmin вручную, могу инициализировать их, добавить некоторую файловую систему, а затем, например, выполнить резервное копирование только -include:C: без проблем. -allCritical продолжает сбой, потому что Esp.vhdx кажется, удаляется и воссоздается каждый раз, снова сталкиваясь с той же ошибкой, что и раньше.
Другая интересная вещь заключается в том, что использование некоторого устройства iSCSI, размещенного на том же NAS, в качестве цели резервного копирования, даже -allCritical успешно проходит каждый раз при тестировании. Все файлы VHDX создаются, инициализируются и форматируются автоматически без ручного вмешательства. Так что, похоже, это не Windows/wbadmin и не связано с самой сетью.
Поэтому я предполагаю, что есть некоторая проблема, касающаяся Samba, но я уже пробовал использовать самую низкую версию SMB1, на которую способен NAS, пробовал такие вещи, как strict allocate = yes люди предлагают, хотя я и дал понять, что NAS не ' В любом случае я не могу создавать разреженные файлы, и я могу прикреплять, инициализировать и публиковать файлы VHDX, созданные wbadmin вручную. Что не должно быть возможно в случае редких файлов из того, что я прочитал.
Единственное, что осталось на данный момент - это код ошибки из службы виртуальных дисков, о котором я не нахожу много информации. Часть 0x37 может быть ERROR_DEV_NOT_EXIST и это может иметь смысл, но что такое @ -part? Где я могу найти, что означает весь синтаксис этой ошибки? Является ли @ -часть какой-то строкой кода, дополнительной деталью или чем-то совершенно другим? Я надеюсь, что это даст мне дополнительные подсказки о фактической основной проблеме, потому что я не понимаю, почему что-то не так для самого wbadmin , что я могу сделать вручную.
Спасибо!