Создание новой роли в Veeam Backup для проверки резервных копий

Veeam backup roles
При необходимости частого восстановления и проверки бекапов серверов в СРК Veeam Backup and Replication, наверняка у вас появятся необходимость создания новой роли, с помощью которой можно проверить развернутую виртуальную машину. В моем случае например мне понадобилось, чтобы на почту приходило сообщение о имени виртуальной машины и ее IP-адресе, по которому можно «достучаться» для её проверки.
Что для этого надо сделать?

  • заходим на сервер Veeam Backup and Replication в папку C:\Program Files\Veeam\Backup and Replication\Backup\SbRoles и копируем и вставляем сюда же один из файлов, тем самым сделав дубль одной из ролей, например у меня так создался файл SendEmailAfterRestore.xml
  • заходим в файл SendEmailAfterRestore.xml и в строке между <SbRole><Id></Id>  меняем идентификатор на какой-либо другой, главное чтобы он не пересекался с уже имеющимся, у меня это 4CDC7CC4-A906-4de2-979B-E5F74C44841F
  • в строке между <SbRole><Name></Name> пишем любое новое имя для роли, у меня это «Send email after restore server»
  • в строке между <TestScript><Name></Name> пишем название производимого действия, например у меня это «Send Email»
  • в строке <TestScriptFilePath> пишем путь до скрипта, через который будет отправляться письмо, у меня это путь C:\Scripts\SendEmail.ps1. Ниже я напишу что в скрипте мы пишем
  • в строке <Arguments> пишем аргументы, которые нам нужны для скрипта, в моем случае это %vm_fqdn% %vm_ip% backup-admins@mail.ru

После этого сохраняем получившийся файл SendEmailAfterRestore.xml
Создаем новый файл C:\Scripts\SendEmail.ps1 и в него вставьте следующие строки:

$arg1 = $args[0]
$arg2 = $args[1]
$recipient = $args[2]
$smtpServer = «relay.mail.ru»
$smtpPort = 25
$smtpUsername = ‘mail\VeeamUser’
$smtpPassword = ‘xxxxxxx’
$sender = ‘Veeam@mail.ru’
$Subject = «Восстановлен из бекапа сервер $arg1»
$messageBody = «Имя сервера: $arg1`nДоступен по IP-адресу: $arg2»
Send-MailMessage -To $recipient -From $sender -SmtpServer $smtpServer -Subject $Subject -Body $messageBody -Encoding UTF8
exit 0
У выделенных «жирным» элементов укажите свои значения и после этого можно перезапускать консоль Veeam, в которой можно будет увидеть новую роль, как на скриншоте в начале статьи.

Бекап логов виртуального MS SQL средствами Veeam Backup

Развитие Veeam Backup не стоит на месте. Уже достаточно давно в нем появилась возможность делать бекап логов MS SQL другим способом, в случае если сервер не физический, а в виде виртуальной машины. Как известно, всегда было это сделать 2 способами:
1) по сети,  подключаясь по протоколам rpc и smb к шаре admin$ для установки временной службы. После завершения сеанса бекапа логов, служба удалялась
2) через API ESXi (VIX). Логика аналогичная первом варианту — копировался exe файл внутрь ВМ, он запускался как служба. После сеанса все удаляется.
Оба эти способа были очень не стабильны (по крайней мере у меня). Могло такое быть, что время самого бекапа удлинялось, бекап логов завершался ошибками или он переставал делаться вовсе, не сообщая о проблемах.
VeeamТеперь же есть новый способ — ставится постоянный агент на сервер, логи которого требуется резервировать.
Каков порядок настройки?
1) ставим на виртуальную машину следующие компоненты
Veeam Guest Agent
Veeam Transaction Log Backup Service
Veeam Installer Service
Все их можно взять с сервера Veeam Backup & Replication в каталоге
C:\Program Files\Veeam\Backup and Replication\Backup\Packages
В результате в установленных программах и в сервисах должна быть такая картина:

2) заходим в настройки задания бекапа логов и ставим галочку у пункта «Use persistent guest agent»

Use persistent guest agent
После всего этого сможете заметить, что время на бекап логов сократится в разы

Ошибка Failed to call RPC function ‘Vss.GetFileFromGADir’: Error code: 0x80070005

Привет! При бекапе виртуальной машины на виртуализации VMware vSphere средствами Veeam Backup возникла неожиданная ошибка:

Failed to prepare VM for processing from storage snapshot, failing over to using VM snapshot. Details: Failed to call RPC function 'Vss.GetFileFromGADir': Error code: 0x80070005. Failed to invoke func [GetFileFromGADir]: Access is denied.. Failed to download the object. RPC function call failed. Function name: [FcGetItemInfo]. Target machine: [имя виртуальной машины]. RPC error:Access is denied. Code: 5.

Данный сервер бекапится у меня не только как виртуальная машина но и как сервер MS SQL.
Решение проблемы оказалось неожиданным: на этой проблемной виртуальной машине установлены пакеты Veeam:
Veeam Transaction LogBackup Service 12.1.0.2131
Veeam Guest agent 12.1.0.2131
Veeam Installer Service 9.5.0.1536

Удалив все их и выключив/включив задачу бекапа (для остановки бекапа логов) проблема устранилась.

Veeam Backup error: Skipping database located on excluded virtual disk

Если в процессе бекапа логов по расписанию с виртуальной машины, на которой крутится  база данных MS SQL средствами Veeam Backup столкнетесь с ошибкой:
Skipping database located on excluded virtual disk
и при этом никаких исключений не создано в задаче бекапа, то в первую очередь проверьте что у вас не включена фича MPIO на проблемном сервере. Она осталась включенной после того, как сервер был виртуализован из физического, а роль не была удалена. После ее удаления и полного бекапа сервера, бекап логов по расписанию заработал.

Ошибка в задаче бекапа Veeam Agent

Veeam агент версии — 6.1.0.349
Veeam сервер версии — 12.1.1.56
При бекапе агентом одного из физических серверов возникла ошибка:
Error: AgentManagerService: Failed to start agent, Host ‘MBX01’. The remote procedure call was cancelled. RPC function call failed. Function name: [DoRpc]. Target machine: [::1]
В логах Veeam ничего дополнительного не нашел. Для устранения этой ошибки помог перезапуск сервиса VeeamEndpointBackupSvc на проблемном сервере. Причем сервис не хотел останавливаться, пришлось останавливать процесс Veeam.EndPoint.Service.exe вручную через Task Manager

Скрипт массового изменения настроек заданий Veeam Backup

Скрипт берет список задач, которые бекапят сервера на виртуализации 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 года 🙂