Veeam Backup: existing backup meta file on repository is not synchronized with the DB

Привет! Недавно столкнулся с очередной проблемой на Veeam Backup and Replication 9.5. Сервер Veeam подвис и я не смог к нему подключиться ни через RDP или RPC, ни через managment интерфейс (HP iLO). Пришлось сервер перезагружать по питанию. После этого я попытался запустить задания бекапа, которые не выполнились за прошедшую ночь и тут посыпались одинаковые ошибки:
Cannot proceed with the job: existing backup meta file 'D:\Backup\test.vbm' on repository 'Scale-Out_Repository' is not synchronized with the DB. To resolve this, run repository rescan.
Я попытался сделать сканирование репозитория но ничего не вышло: ошибка появлялась вновь.  При этом задания бекапа логов автоматически запустились через повторный перезапуск сервисов Veeam и начали успешно бекапить SQL.  Попытался создать клон задания — оно начало выполняться. Далее начал смотреть сами vbm  файлы, точнее их содержание и тут обнаружилось: все файлы, на которые ругался Veeam полностью либо частично повреждены, точнее в них содержится набор нечитаемых символов. Так это выглядело в Notepad++:

В логах бекапа SQL логов нашлось более интересная вещь:По крайней мере стало понятно, что произошел какой-то сбой на сервере, в результате которого вместо информации о бекапах текущего задания в файл сам Veeam начал заносить текст со слетевшей кодировкой.
После этого обратился в поддержку Veeam, где они посоветовали удалить файл vbm и запустить задание вновь. О чудо все заработало. Оказывается в случае если в директории нет файла  vbm, то тогда Veeam  берет информацию о бекапе из базы своей базы данных. Вот такая вот интересная история.

Ошибка восстановления базы данных SQL

Veeam Backup & Replication 9.5 Update 4. Столкнулся с ошибкой при восстановлении базы MSSQL на не оригинальный сервер. После нескольких десятков минут копирования данных (база более 2 ТБ) задание завершалось с ошибкой:
Database restore failed: Failed to read block from file: C:\Windows\TEMP\o1p4abst.bwj\MSSQL.1\MSSQL\Data\work_data.mdf The system cannot find the file specified.
Database restore failed: Failed to read block from file: C:\Windows\TEMP\o1p4abst.bwj\MSSQL.1\MSSQL\Data\work_data.mdf The system cannot find the file specified.

Если глянуть логи на сервере, куда данные восстанавливаются, то там будет следующий текст:
dpl| ERR |Failed to execute DoRpcWithBinary. Command name: 'DoSerialRpc'.
dpl| >> |[NO_SESSION_ERROR] Cannot find session
dpl| >> |--tr:Failed to get session with id {e59b788f-ccea-4656-b68d-3392c8176097}
dpl| >> |--tr:Failed to call DoRpc. CmdName: [DoSerialRpc] inParam: [<InputArguments/>].
dpl| >> |An exception was thrown from thread [3876].

В системном логе была найдена такая ошибка:
Log Name: System
Source: Microsoft-Windows-NDIS
Date: 28.09.2020 17:17:15
Event ID: 10400
Task Category: None
Level: Warning
Keywords:
User: N/A
Description:
The network interface "vmxnet3 Ethernet Adapter" has begun resetting. There will be a momentary disruption in network connectivity while the hardware resets.
Reason: The network driver detected that its hardware has stopped responding to commands.
This network interface has reset 3 time(s) since it was last initialized.

Последний лог и подтолкнул сделать обновление драйверов на виртуальную сетевую карту vmware, т.к. vmware tools были очень древние. И, о чудо, обновление помогло. Следующий раз восстановление прошло успешно!

Veeam: Ошибка «Full backup file merge failed»

Привет! При бекапе большой базы данных на хранилище, располагающееся на Windows Server 2008R2 возникла ошибка «Full backup file merge failed Error: Agent: Failed to process method {Transform.Patch}: The parameter is incorrect. Failed to write data to the file«. При проверке выяснилось, что полный файл бекапа (.vbk) составляет 15,9 Tb, файловая система NTFS и размер кластера на нем 64KПоддержка Veeam нашла статью, в которой говорится, что «максимальный размер файла в Windows 2008R2 составляет меньшее из 2 чисел: 2^32-1 помноженное на размер кластера ИЛИ 16 ТБ». Отсюда вывод: пора переносить бекап на другой сервер с более новой операционной системой 🙂

Veeam Backup: Failed to call RPC function ‘GetBiosUuid’: Error code: 0x80041017

Привет! Сегодня новая ошибка. При добавлении сервера в оснастку Veeam Backup возникла такая ошибка: «Collecting hardware info Error: Failed to call RPC function ‘GetBiosUuid’: Error code: 0x80041017. Cannot query class instance from enumerator object»

Для решения проблемы проверяем, что локально на проблемном сервере wmi запрос выполняется, запускаем powershell и запускаем команды:
gwmi -Class win32_bios
gwmi -Class win32_computersystemproduct | fl *
wmic path win32_computersystemproduct get uuid

Должны они выполниться успешно. Если это так, то перезапускаем службу «Windows Management Instrumentation» и радуемся жизни 🙂

Veeam — Восстановление на нестандартный порт SQL

Если у вас SQL работает на нестандартном порту, например как здесь:то тогда при восстановлении SQL через консоль Veeam Backup & Replication на такой порт вы столкнетесь с тем, что будет стандартная ошибка:

«The server was not found or was not accessible».
Для решения этой проблемы при восстановлении нужно указывать порт, но при этом в инструкциях Veeam об этом ничего не сказано. Вот как это сделать правильно:

порт указываем после адреса сервера и запятой. Для DBA такое написание не новость, а вот для остальных админов это немного непривычно.

 

 

Ошибка «[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied»

При бекапе SQL находящимся на сервере, на котором отключен TLS 1.0 возникает ошибка, указанная в заголовке темы.
Для ее решения у Veeam есть статья , в которой сказано, что нужно создать ключ UseSqlNativeClientProvider типа DWORD со значением 1 в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication.
Самое обидное, что в этой статье ничего не сказано про агенты Veeam, на которых у меня возникла проблема. Для них оказалось нужно создать тот же ключ в другой ветке реестра- HKLM\SOFTWARE\Veeam\Veeam Endpoint Backup.
После этого достаточно перезапустить службы Veeam на сервере.

VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f]

При бекапе Veeam агентом физического сервера возникла ошибка:
Error: Failed to create snapshot: Backup job failed.
Cannot create a shadow copy of the volumes containing writer’s data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].
Ошибка стала возникать после увеличение диска и перезагрузки сервера.
Команда vssadmin list writers выдавала ошибки подобные этим

Writer name: ‘WMI Writer’
Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
Writer Instance Id: {7ce8d4ce-3313-4b76-a3c8-254d83320432}
State: [7] Failed
Last error: Timed out

Writer name: ‘MSMQ Writer (MSMQ)’
Writer Id: {7e47b561-971a-46e6-96b9-696eeaa53b2a}
Writer Instance Id: {37a842aa-7da6-4564-af96-e82380de7be4}
State: [7] Failed
Last error: Timed out

Writer name: ‘IIS Config Writer’
Writer Id: {2a40fd15-dfca-4aa8-a654-1f8c654603f6}
Writer Instance Id: {09cbce07-9f96-41fb-9b85-0eed6a1f4432}
State: [7] Failed
Last error: Timed out

Writer name: ‘IIS Metabase Writer’
Writer Id: {59b1f0cf-90ef-465f-9609-6ca8b2938366}
Writer Instance Id: {31eaa04e-0da2-4cde-8dd4-28325a4039d2}
State: [7] Failed
Last error: Timed out

Как вариант, в интернете предлагается перезапустить соответствующие службы, в моем случае это Windows Management Instrumentation, Application Host Helper Service, IIS Admin Service, Message Queuing, но мне это не помогло. Тогда я сделал тестовый снапшот командой vssadmin Create Shadow /FOR=C: иvssadmin Create Shadow /FOR=D:  — они прошли успешно. 
После этого я перезапустил службу Volume Shadow Copy и ошибка при бекапе пропала!
Надеюсь эта статья вам поможет.

Опять проблема с сетевым доступом

Привет! Недавно увидел новую ошибку в Veeam, когда не открыты все необходимые сетевые порты. Ошибка следующего вида:
Could not write file [C:\Program Files (x86)\Veeam\Backup Transport\GuestInteraction\VSS\VeeamGuestHelpers\VeeamVixProxy.exe] of size [944208] to the HTTP server
Could not send HTTP request. System error code: 12002

Такой текст у меня возникал, когда я пытался протестировать доступ к серверам при включенном Application-aware processing.
После такой ошибки Veeam не может подключиться к виртуальному серверу через Vmware VIX.
Оказалось все очень просто — необходимо, чтобы от прокси Veeam были доступны сервера ESXi по 443/TCP порту.

Ошибка в Veeam — Agent failed to process method {DataTransfer.SyncDisk}

Столкнулся с такой ошибкой — Error: Failed to open VDDK disk failed because of the following errors: Failed to open disk for read. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk} в Veeam Backup and Replication 9.5.
Исправилось у меня легко, так как знал какие были до этого изменения — был подключен новый ESXi-сервер в кластер и не были открыты необходимые порты.
Как исправить? открыть порт 902/TCP от Veeam Proxy до VMware ESXi.

Ошибка «Unable to process: host reboot is required» при бекапе агентом Veeam

Привет! Недавно совершил небольшую ошибку, при обновлении агентов Veeam на одном из серверов с Windows Server 2008R2. на нем у меня стоит агент Veeam версии 2.2.0.589 и я попытался обновить его до версии 3.0.2.1170. Все было бы хорошо, да вот только на сервер редко когда ставится обновления из-за его важности 🙂 Поэтому, когда уже процесс обновления пошел -выяснилось, что в систему ставится обновление «KB3045557«. Всё бы ничего, да вот только после него в консоли Veeam пишется, что серверу требуется перезагрузка. В результате, у меня на 2-ой или 3-ий раз бекап завершился с ошибкой «Unable to process: host reboot is required«. И тут вопрос встал ребром: неужели придется перезагружать сервер, ради того, чтобы выполнить бекап? Я зашел на сервер, вижу, что сервер, не пишет о том, что требуется перезагрузка — уже хорошая новость. Далее я запустил небезызвестный «Process Monitor» и через консоль Veeam запустил сканирование хоста. Далее начал изучать собранную информацию в этой утилите. И вот что получилось: сервис «Veeam Installer Service», под которым работает исполяемый файл VeeamDeploymentSvc.exe лезет в реестр и проверяет значение ключа DotNet_RebootNeeded в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Volatile. В моем случае ключ был со значением «1». Поменял это значение на «0» и перезапустил сканирование хоста с консоли Veeam. На этот раз статус хоста стал «Upgrade Required» и уже ночью после очередного бекапа я убедился, что исправление ключа реестра пошло на пользу и бекап снова проходит успешно.
P.S. В моем случае на хосте не стоял драйвер CBT.