Veeam ошибка при восстановлении

Резервное копирование виртуальной машины с SharePoint Server 2019 в  Veeam Backup & Replication v12 выполнялось успешно до тех пор, пока в SharePoint не была настроена и запущена служба поиска Search Service Application. Каждое последующее задание резервного копирования ВМ стало завершаться ошибкой создания контрольной точки Hyper-V production checkpoint следующего вида:

Failed to create VM recovery checkpoint (mode: Veeam application-aware processing) Details: Failed to create VM (ID: ba7b4b0c-3fbd-4c51-8737-2ae39aee005f) recovery checkpoint. Job failed ('Checkpoint operation for 'KOM-WEB01' failed. (Virtual machine ID BA7B4B0C-3FBD-4C51-8737-2AE39AEE005F) 'KOM-WEB01' could not initiate a checkpoint operation: %%2147754996 (0x800423F4). (Virtual machine ID BA7B4B0C-3FBD-4C51-8737-2AE39AEE005F)'). Error code: '32768'.
Retrying snapshot creation attempt (Failed to create production checkpoint.)
Task has been rescheduled
Unable to allocate processing resources. Error: Failed to create production checkpoint.

Анализ логов на сервере SharePoint в момент выполнения задания в VBR показал наличие ошибки с кодом Event ID 8194:

Log Name:      Application
Source:        VSS
Date:          29.04.2023 3:12:51
Event ID:      8194
Level:         Error
Keywords:      Classic
Computer:      KOM-WEB01.holding.com
Description:   Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface.  hr = 0x80070005, Access is denied. This is often caused by incorrect security settings in either the writer or requestor process. 
Operation:   PrepareForSnapshot Event
Context:
   Execution Context: Writer
   Writer Class Id: {0ff1ce16-0201-0000-0000-000000000000}
   Writer Name: OSearch16 VSS Writer
   Writer Instance Name: OSearch Replication Service
   Writer Instance ID: {4ce2a6c6-2cf2-4f58-872f-9ce95adf804a}

Попытка создать контрольную точку ВМ вручную в консоли Hyper-V Manager также приводила к ошибке «could not initiate a checkpoint operation: %%2147754996 (0x800423F4)«

При этом в логе Application фиксировалась аналогичная ошибка с кодом 8194.

Команда листинга модулей записи теневого копирования на сервере SharePoint показала ошибочное состояние модуля «OSearch16 VSS Writer«:

vssadmin list writers
...
Writer name: 'OSearch16 VSS Writer'
   Writer Id: {0ff1ce16-0201-0000-0000-000000000000}
   Writer Instance Id: {268f99a2-1231-41d2-81e2-8f3ee565ee8e}
   State: [8] Failed
   Last error: Non-retryable error
...

Так как в тексте ошибки в event-логе фигурирует информация о нехватке прав («…0x80070005, Access is denied…»), в первую очередь нужно понять о какой учётной записи идёт речь.

Если посмотреть на стандартные поля в событии об ошибке, то в поле User мы не увидим информации о пользователе:

Однако, если переключиться на отображение подробностей на вкладке Details, то в варианте просмотра Friendly View в разделе с листингом бинарных данных мы сможем увидеть имя учётной записи, в контексте которой возникла шибка:

В нашем случае, это учётная запись фермы SharePoint (Farm account). И в контексте именно этой учётной записи у нас выполняется служба поиска SharePoint. При этом данная учётная запись не имеет полных административных прав на сервере.

Теперь относительного того, куда именно не может получить доступ учётная запись.

При проблемах с резервным копированием службы поиска SharePoint, в качестве одного из моментов, на который стоит обращать внимание, является состояние ключа реестра для службы «Volume Shadow Copy» (VSS):

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesVSS

Как минимум, в этом ключе:

1) В под-ключе VssAccessControl должен присутствовать параметр REG_DWORD с именем учётной записи, в контексте которой работает ферма/служба поиска, и значением «1»;

2) В под-ключе Diag должен присутствовать под-ключ с именем VSS модуля для службы поиска SharePoint (в нашем случае должен быть под-ключ с именем «OSearch16 VSS Writer«):

В нашем случае обнаружилось, что под-ключа «OSearch16 VSS Writer» нет.

В такой ситуации некоторые граждане предлагают выдать полные права доступа для учётной записи фермы/службы поиска на под-ключ Diag. Однако, если присмотреться к действующим разрешениям на этот ключ реестра, то можно заметить, что запись в него разрешена локальной группе безопасности «Backup Operators«.

Включаем учётную запись фермы/службы поиска в эту группу на нашем виртуальном сервере SharePoint со службой поиска и перезагружаем этот сервер.

После перезагрузки удостоверимся в наличии ключа реестра «OSearch16 VSS Writer» и увидим, что владельцем этого ключа является учётная запись, включенная нами ранее в группу «Backup Operators».

После этого снова попробуем создать контрольную точку виртуальной машины в оснастке Hyper-V Manager.

В нашем случае контрольная точка создалась успешно и в гостевой системе виртуального сервера SharePoint ошибка с кодом 8194 больше не появляется.

Теперь можно проверить, как изменилась ситуация в Veeam Backup & Replication. Убеждаемся в том, что в ходе выполнения задания резервного копирования для ВМ успешно создаётся, а затем автоматически удаляется временная контрольная точка, и, как следствие задание VBR отрабатывает без ошибок.

Стоит отметить, что описанная проблема является не проблемой VBR, а проблемой корректной настройки прав доступа для сервисных учётных записей SharePoint. При этом в официальном документе «Plan for administrative and service accounts in SharePoint Server» мне не удалось найти каких-либо явных указаний по включению сервисных учётных записей SharePoint в группу «Backup Operators» или каких-либо схожих по смыслу рекомендаций.

Сен 4, 2016 02:19

I had to restore one of the VM machines from backup, fortunately a test machine and I am getting errors no matter which restore point I try. Errors below. Anyone saw anything similar? I am quite new to Veeam.

Error: Failed to decompress LZ4 block: incorrect block header. Failed to download disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: Shared memory connection was closed. Failed to upload disk.

Error Restore job failed Error: Failed to decompress LZ4 block: incorrect block header. Failed to download disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from server: Shared memory connection was closed. Failed to upload disk.

Время на прочтение
4 мин

Количество просмотров 9.4K

Привет, с вами сегодня команда техподдержки Veeam Support Team. Мы уже рассказывали читателям Хабра о

фантастических тварях

разнообразных клиентах и где они обитают, и о том, чем и как занимается наш отдел.

А в новом сезоне мы решили начать публикацию технических постов с разбором реальных кейсов, с которыми к нам обращаются пользователи. Хочется верить, что эти материалы помогут кому-то разобраться в тонкостях работы с нашим продуктом без звонка в саппорт – а мы используем сэкономленное таким образом время для написания новых полезных статей.

Итак, сегодня разбираем кейс «Проблема с восстановлением на уровне файлов – ошибка при развертывании Linux FLR appliance», который стал одним из наиболее популярных за прошедшие месяцы.

Суть вопроса

При нормальной работе для восстановления файлов гостевой ОС (не Windows) забэкапленной виртуальной машины выполняется монтирование (mount) дисков этой самой забэкапленной машины на вспомогательную линуксовую ВМ (Linux FLR appliance). После этого можно просматривать содержимое файловой системы с помощью Veeam Backup Browser, выбирать необходимые файлы и восстанавливать их в нужное местоположение. Подробнее см. здесь (на англ. языке) или здесь (на русском).

Вспомогательная ВМ временно развертывается на ESXi-хосте исключительно с целью поддержки восстановления, а затем убирается. Однако при ее развертывании в консоли Veeam Backup & Replication может появиться сообщение об ошибке вот такого вида: “Linux FLR appliance deploy failed: Module ‘MonitorLoop’ power on failed.”

Как понять, что что-то пошло не так

Нюанс в том, что проблема происходит на довольно специфическом этапе – только при восстановлении файлов гостевой ОС, отличной от Windows, и конкретно при развертывании вспомогательной ВМ.

Сообщение об ошибке выглядит в консоли вот так:

Мы видим, что проблема связана с модулем MonitorLoop. Об этом же говорит и журнал соответствующей сессии FLR-восстановления, который хранится в файле с именем вида year_month_day_hour_minute_second.log. В нем мы обнаруживаем следующие записи:

[05.07.2017 17:16:49] <06> Info Mounting restore point. VM: [fileserver], BackupDate: [09.01.2017 18:31:12], Oib: [aa6038d3-bf68-42d6-86c0-de3a48784066]
[05.07.2017 17:17:49] <06> Error Failed to mount oib «aa6038d3-bf68-42d6-86c0-de3a48784066»
[05.07.2017 17:17:49] <06> Error Linux FLR appliance deploy failed: Module ‘MonitorLoop’ power on failed. (Veeam.Backup.Common.CAppException)

Кроме того, поскольку за развертывание вспомогательной ВМ (FLR appliance) отвечает сервис монтирования VeeamMountSvc, то в его журнале Svc.VeeamMount log тоже будет сделана подобная запись (правда, в ней не будет фигурировать проблемный модуль):

[05.07.2017 17:16:49] <23> Error Recreating WCF proxy…
[05.07.2017 17:16:49] <23> Error Linux FLR appliance deploy failed (System.ServiceModel.FaultException`1[Veeam.Backup.Interaction.MountService.CRemoteInvokeExceptionInfo])

«Кто виноват?»

Продолжая наше расследование, выясняем, что имеется статья VMware KB, из которой явствует, что модуль MonitorLoop контролирует ресурсы, выделяемые виртуальной машине. Конкретно же наша ошибка генерируется VMkernel, и ее можно обнаружить в журнале VMkernel:

Первопричиной является тот факт, что у хоста ESXi недостаточно ресурсов для работы вспомогательной ВМ. Естественно, процесс восстановления файлов без нее даст сбой. Чтобы выяснить, чего не хватает, можно углубиться в анализ логов VMkernel, а можно оценить необходимые ресурсы, основываясь на здравом смысле. А он утверждает, что критичные ресурсы – это, скорее всего, CPU и RAM, доступные для работы ВМ на данном хосте, а также свободное место для хранения файла подкачки. Недостаток последнего встречается довольно часто, так что если вы уверены, что ресурсами оперативной памяти и процессора все в порядке, то причина возникающей ошибки почти наверняка — недостаток места для хранения файлов вспомогательной ВМ и ее файла подкачки.

«Что делать?»

Для того, чтобы уяснить, что конкретно нужно поправить, запускаем мастер восстановления File-Level Restore и идем в настройки вспомогательной ВМ (FLR Helper Appliance).

Здесь для хоста, указанного в поле Host, нужно проверить две вещи:

1. Достаточно ли у хоста ресурсов памяти и ЦПУ для работы ВМ. Вспомогательная машина потребляет минимум этих ресурсов, так что главное, чтобы они были доступны на момент ее развертывания. Если нужно, выберите другой хост, где эти ресурсы гарантированно будут в наличии.
2. По умолчанию Veeam сохраняет файл подкачки вспомогательной ВМ на хранилище, указанное как NFS datastore – это обычная Windows-папка на сервере монтирования (mount server). Однако так бывает не всегда.

   На картинке ниже показана настройка хоста ESXi, отвечающая за дефолтное место хранения файлов подкачки виртуальных машин: host → Configuration → Virtual Machines → Swap File Location.

   

   Есть вероятность, что дефолтная настройка – Virtual machine directory (хранить в каталоге ВМ) – была изменена, а на вновь указанной для этой цели СХД закончилось место. В результате развернуть новые ВМ, включая вспомогательные, невозможно. Проверьте, не ваш ли это случай.

Аналогичая ошибка может произойти со вспомогательной ВМ в ходе SureBackup – причиной будет все та же нехватка ресурсов.

Бонус-трек

А знаете ли вы, что подробнее о работе продуктов Veeam всегда можно почитать в онлайн-справке, которая открывается по нажатию клавиши F1 из любого диалога в консоли продукта, включая главное окно?

Это относится и к шагам разнообразных мастеров настроек – нажимаете F1 на любом шаге мастера, и в вашем дефолтном браузере открывается соответствующий параграф документации в справочной онлайн-системе Help Center.

Профит!

Мы собираемся и дальше выкладывать разборы популярных кейсов из числа тех, которые поступают к нам в саппорт. Cвои пожелания можно высказывать в комментариях. До новых встреч!

Ссылки к сегодняшнему посту:

• Документ «Базовые сценарии использования Veeam Backup & Replication 9.5» на русском языке
• Описание процесса восстановления файлов гостевой ОС (FLR)
• Статья базы знаний VMware