Попытка резервного копирования фермы SharePoint 2013 приводит к исключению Backup-SPFarm : An update conflict has occurred, and you must re-try this action …SPUpdatedConcurrencyException

Ранее мы рассматривали пример скриптового решения для автоматизации периодического полного резервного копирования фермы SharePoint 2013. И это решение благополучно работало у нас до недавнего времени, но в какой-то момент резервные копии перестали создаваться успешно.

Проверочный запуск скрипта резервного копирования от имени учётной записи фермы, показал, что в ходе выполнения скрипта на моменте вызова командлета Backup-SPFarm возникает какое-то малопонятное исключение SPUpdatedConcurrencyException.

В лучших традициях прохождения шагов по решению "мутных" проблем с SharePoint был сделан заход на поисковые системы, который привёл к старой статье KB939308 Error message when you try to modify or to delete an alternate access mapping in Windows SharePoint Services 3.0: "An update conflict has occurred, and you must re-try this action". Описание исходных данных, приводящих к возникновению ошибки мало совпадало с нашей ситуацией, но по тексту ошибки создавало некоторую ассоциацию.

В качестве решения в статье рассматривается методика очистки файлового кеша на серверах SharePoint Web Front End. В статье указан путь размещения файлов кеша в старом формате, типа:

C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config{GUID}

На серверах Windows Server 2012 R2 этот каталог расположен по пути: C:\ProgramData\Microsoft\SharePoint\Config{GUID}

В этом каталоге мы найдём множество XML файлов и файл cache.ini, который, как я понимаю, содержит текущий номер версии файлового кеша.

Чтобы произвести очистку и полное перестроение данного файлового кэша нам потребуется выполнить следующую последовательность действий:

  1. Останавливаем на сервере SharePoint WFE системную службу "SharePoint Timer Service" (команда net stop SPTimerV4);
  2. Удаляем все XML-файлы из выше обозначенного каталога. После этого в каталоге должен остаться только один файл cache.ini;
  3. Открываем с правами администратора на редактирование файл cache.ini, меняем имеющееся в нём большое целое число на число "1" и сохраняем файл;
  4. Снова запускаем системную службу "SharePoint Timer Service" (команда net start SPTimerV4).

Через несколько минут после запуска службы каталог кеша снова должен наполнится XML-файлами, а число в cache.ini должно измениться на другое значение.

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

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

Добавить комментарий