Скрипт берет список задач, которые бекапят сервера на виртуализации VMware и у которых параметр Enable VMware Tools quiescence не включен и меняет эту настройку на «Включено»
Import-Module Veeam.Backup.PowerShell
$jobs = Get-VBRJob | where {($_.Options.ViSourceOptions.VMToolsQuiesce -like 'False') -and ($_.TypeToString -like "VMware Backup")}
Foreach ($job in $jobs)
{
$options = Get-VBRJobOptions $job
$Options.ViSourceOptions.VMToolsQuiesce = $True
Set-VBRJobOptions -job $job -options $options
}
Veeam. Проблема с бекапом на ленту
В случае если у вас Veeam Backup выдает ошибку «Failed to start new tape backup session: Failed to get last session number, sessions map is empty» или «Failed to get last session number, sessions map is empty. Failed to get last session number, sessions map is empty.«, знайте, что нужно найти последнюю использованную кассету и очистить ее. После этого можно запускать бекап на ленту вновь и он должен успешно начаться.
У меня эта ошибка началась после того как база Veeam Backup перестала быть доступной в момент бекапа на ленту. Бекап аварийно завершился и больше не запускался, выпадая с ошибкой, указанной выше.
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 Backup
Привет! К несчастью, столкнулся с такой особенностью, что когда делаешь бекап не оригинальной виртуальной машины, а ее копии (реплики), то тогда итоговый результат в бекапе будет не вполне тем, что хочешь получить. Бекап будет или частично или полностью недоступен при восстановлении. А все это из-за технологии CBT, которая включена по-умолчанию в заданиях бекапа Veeam и ускоряет процесс создания инкрементного бекапа. В случае бекапа реплики, нужно CBT отключать в настройках задания! А правильнее вариант — сначала делать бекап с боевой виртуальной машины и только после делать реплику, источником которой будут файлы резервной копии, в настройках задания репликации это можно указать в Veeam BR. Информация эта от поддержки Veeam, которая, в свою очередь, ссылается на форум Veeam, где есть об этом информация в виде сообщения от 2010 года 🙂
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 0x800401fd. Failed to invoke func [ExploreInstances]
В версии 9.5.4.2866 сервера для резервного копирования Veeam Backup & Replication похоже есть небольшая проблема при бекапе логов MS SQL. В процессе их копирования можно столкнуться иногда с ошибкой Ошибка при бекапе SQL 0x800401fd. Failed to invoke func [ExploreInstances].
Для решения этой проблемы есть фикс, который можно скачать по ссылке. А вот инструкция по его установке от сотрудника поддержки Veeam:
1. Остановите все задания, в том числе бекап логов (для этого придется перевести исходные задания в статус Disabled, см. https://helpcenter.veeam.com/docs/backup/hyperv/starting_transaction_log_jobs.html?ver=95u4#parent).
2. Закройте консоль Veeam, остановите все службы Veeam на всех серверах, которые могут использоваться в качестве Guest Interaction Proxy (в вашем случае, судя по всему, используется только admin-srv, но, пожалуйста, проделайте эту операцию на всех возможных узлах)
3. На сервере Veeam и всех используемых Guest Interaction Proxy перейдите в каталог C:\Program Files (x86)\Veeam\Backup Transport\GuestInteraction и переименуйте файл Veeam.Guest.Interaction.Proxy.exe в Veeam.Guest.Interaction.Proxy.exe_orig
4. Замените файл на новую версию из загруженного архива.
5. Запустите все службы Veeam (порядок произвольный) на серверах, откройте консоль, включите задания резервного копирования
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 на сервере.