Такие ошибки при запуске бэкапа могут возникать по причине наличия остатков в реестре от VSS-провайдеров, которые ранее были удалены из системы. В моем случае ошибки появлялись на хостовой машине Hyper-V на Windows Server 2008 R2 при запуске резервного копирования. Запустив команду vssadmin list providers я увидел, какие VSS-провайдеры зарегистрированы у меня в системе, и сравнил их с PID-ами тех, которые были в ошибках. Выяснилось, что ошибки возникали в отношении провайдеров, которые мне были не нужны и которых я ранее удалил из системы. Далее я удалил записи в реестре от этих провайдеров следующим образом:
1) Находим в реестре ключ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS\Providers\] 2) На всякий случай создаем резервную копию этого ключа 3) Удаляем ключи с соответствующим PID 4) Перезапускаем службу "Microsoft Software Shadow Copy Provider" 5) Запускаем бэкап и смотрим на наличие ошибок. Если ошибки появились вновь, перезагружаем систему.
При изменении пути перенаправленной папки через групповые политики на новый путь, при этом когда сами данные физически продолжают оставаться в том же самом месте (например, в случае использования нового пути DFS или кластера), можно столкнуться с тем, что все файлы из папки будут удалены. Это может произойти тогда, когда в настройках перенаправления папки включен параметр "Move contents of ... to the new location" (Перенести содержимое ... в новое местоположение). Конечным действием операции переноса является удаление файлов из начального местоположения, но так как физически оно одно и тоже, происходит полное удаление всех файлов из перенаправленной папки. Будьте внимательны в таких случаях! Не забывайте снимать указанную галку в настройках перенаправления папки, либо включите параметр групповой политики "Verify old and new Folder Redirection targets point to the same share before redirecting" (Проверить перед перенаправлением, указывают ли старый и новый конечный объект перенаправления папки на один общий ресурс). Этот параметр находится в Computer Configuration/Polices/Administrative templates/Windows Components/Windows Explorer. При включении этой политики, Windows перед переносом файлов определяет путем записи временного файла - в одно и то же физическое место хранения происходит перенаправление или нет. В случае обнаружения, что папка перемещается в одно и то же место, происходит только изменение пути без операции копирования и удаления файлов.
При использовании перенаправленных папок (redirected folders) на компьютерах с Windows 7, 8, Vista на сетевые ресурсы DFS с включенным использованием Автономных файлов (Offline files) столкнулся со следующей проблемой - при попытке синхронизировать автономные файлы через Центр синхронизации операция зависает в статусе "Синхронизация ожидается" (Sync pending) и так никогда и не происходит. После изучения сайтов Microsoft с рекомендациями по настройке Автономных файлов и обзора зарубежного опыта отыскал таки проблему - для корректной работы синхронизации при использовании DFS в силу особенностей работы кэширования возможность использования Автономных файлов должна быть включена не только на уровне непосредственно Конечного объекта папки (Folder target), но и на уровне корня DFS. В настройках автономного режима сетевой папки, которая является корнем DFS, по крайней мере должно быть указано "Вне сети доступны только указанные пользователем файлы и программы". Далее уже на уровне Конечного объекта папки (Folder target) вы можете указывать, какие из них могут быть доступны автономно, а какие нет, в зависимости от вашей необходимости.
В моем случае указанный корень DFS использовался для хранения перемещаемых профилей пользователей и перенаправленных папок Мои документы и Рабочий стол. Пути имели следующий вид:
\\domain.local\data\profiles\ - тут хранились профили пользователей, для Folder target "profiles" использование автономных файлов отключено \\domain.local\data\userdata\ - тут хранились перенаправленные папки пользователей, для Folder target "userdata" автономные фалы были включены принудительно
На корне DFS "data" - автономные файлы были выключены принудительно. В итоге синхронизация через Центр синхронизация зависала в бесконечном "Синхронизация ожидается". Установка возможности кэширования на уровне корня решило проблему, при этом папка profiles не кэшируется, так как на ее уровне автономные файлы выключены.