Вынесенный в заголовок текст об ошибке - это мой личный ночной кошмар. Был. До недавнего времени, когда все же нашелся способ, как реплику файлового ресурса можно "починить" без пересоздания. Довольно долго предполагал, что проблема где-то на стороне самого файловика - и что только с ним не делали. И перезапуск, и проверка прав на черт знает какой глубине каталогов, и миграция файлов туда-сюда... Стопроцентно рабочим вариантом было только пересоздание реплики. Иииии... до следующего раза. А поскольку реплики эти измеряются в терабайтах - процесс очень не быстрый и очень ресурсозатратный.

И вот где-то в апреле мне во время очередного разбора полетов попалась на глаза статья, где предлагалось чинить не сам файловик, а именно реплику. Потому что проблема может быть на ее стороне. DAFUQ?!, подумал я
тогда. Это же реплика, там ничего никогда не делается без ведома самого DPM, какие там могут быть проблемы? С другой стороны - во многих аспектах DPM это синоним слова "проблема", а поскольку других вариантов нет, почему-бы и не попробовать. Тем более, что админам это не стоит ничего, а пользователи вообще ничего не заметят, работа будет проходить на сервере резервного копирования, а не на файловике. Каково же было удивление, когда это сработало. Система, действительно, исправила ошибку внутри тома с репликой, после чего запуск задачи на синхронизацию реплики с источником данных дал нужный результат - Sync OK. Что ж, алгоритм действий был таким:

1. Определяем том, где лежит пораженная реплика. Для этого в DPM открываем свойства источника данных по ссылке Replica Path: Click to view details. Нам покажут окно с примерно следующей информацией:

D:\ on FS1.DOMAIN.COM c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_48342fb3-5e1f-43b9-b1a3-641aea404c23\8b28e1f0-0e38-4c4c-a1b8-af5881f4a4bf\Full\

Из этого всего нам нужен путь. А если точнее - кусок пути от начала строки до конца сегмента vol_..., в нашем случае это будет выглядеть так:

c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_48342fb3-5e1f-43b9-b1a3-641aea404c23

Именно по этому пути DPM будет искать реплику при любых операциях с оной.

2. Исходя из найденного пути нужно определить, на каком томе лежит нужная нам реплика. Тут все просто - mountvol. Выводим список всех точек подключения и смотрим, где появится найденный путь. Наша цель - идентификатор тома примерно такого вида:
\\?\Volume{GUID}

3. После того, как найден том с репликой, выполняем проверку этого тома на наличие ошибок и их коррекцию:
chkdsk /f \\?\Volume{GUID}
Процесс займет какое-то время, после чего в результате получаем стандартный вывод команды chkdsk о том, что система нашла проблемы в структуре файлов внутри реплики и исправила их.

4. Финальный шаг - синхронизация отремонтированной реплики с источником данных. Штатная команда самого DPM, расписывать которую здесь смысла нет.

В результате всего этого безобразия получаем рабочую реплику, восстановление работоспособности задач по резервному копированию и заслуженное право сказать "Я сегодня хорошо поработал, могу идти домой".

Однако, есть еще кое-что, чего хотелось бы избежать. Правильно, слишком много ручной работы. А потому пришла мысль обернуть все это (ну или почти все) в powershell-скрипт. На входе он принимает путь к файлам с репликой (все та же строка вида c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_48342fb3-5e1f-43b9-b1a3-641aea404c23\8b28e1f0-0e38-4c4c-a1b8-af5881f4a4bf\Full\, а на выходе отдаст сообщение:
Use: chkdsk /f \\?\Volume{найденный GUID}

После чего уже запускаем проверку реплики и синхронизацию.

Скрипт ниже. Надеюсь, кому-то он будет полезен.