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

Привет! Недавно увидел новую ошибку в 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.

Veeam backup error Code: 1326

Привет! Если вы поменяете пароль для учетной записи, с помощью которой Veeam подключается к серверам для бекапа, то можете столкнуться с ошибкой  «Failed to connect to Oracle Details: Failed to logon user Win32 error:Logon failure: unknown user name or bad password. Code: 1326«, даже если он реально правильный. Ошибка возникает после смены пароля в бекапных заданиях, где включена функция «Application-aware processing» и где используется Veeam Agent. Конкретно у меня ошибка была только при ночных системных бекапах  серверов SQL, бекапы логов успешно проводились. Для решения проблемы необходимо обновить Veeam Backup and Recovery и Veeam Agent. Их версии должны быть 9.5.4.2866 и 3.0.2 соответственно. В моем случае понадобилось только обновить агенты и даже не пришлось перезагружать сервера.

Зависание процесса «Creating VSS snapshot» в Veeam BR

Недавно возникла проблема с сервером, когда на нем процесс резервного копирования зависала при выполнении задачи «Creating VSS snapshot«. Начал выяснять что с сервером. Оказывается: при выполнении команды vssadmin list writers она зависала и не выводила результаты. Для решение проблемы мне помогло:
1) перезапуск сервиса «COM+ Event System» (в английской версии сервера). За перезапуском тянутся также другие службы (BITS, COM+ System Application, System Event Notification Service)
2) после этого команда vssadmin list writers стала выдавать чистый вывод и помог следующий шаг:
3) перезапуск службы Microsoft Software Shadow Copy Provider

Error Veeam Backup and Replication: «Unable get OIB by id»

Неожиданно на агентском задании бекапа SQL-кластера в Veeam BR 9.5 Update 4 возникла ошибка «Error: Unable get OIB by id ‘f3d18c39-7ff7-4524-b1db-e862719c6230’ «. Ошибка не хотела пропадать даже после создания нового задания. Пришлось обратиться в техническую поддержку Veeam за помощью и вот что они предложили сделать:
1) Выполняем SQL запрос для конфигурационной базы Veeam:
select * FROM [dbo].[Backup.Model.OibsWithAlwaysOnGroups] where oib_id=’f3d18c39-7ff7-4524-b1db-e862719c6230’
должен вывести проблемную точку восстановления
2) Выполняем SQL запрос delete [dbo].[Backup.Model.OibsWithAlwaysOnGroups] where oib_id=’f3d18c39-7ff7-4524-b1db-e862719c6230′ -для удаления проблемной точки восстановления из цепочки.
3) Делаем рескан репозитория, где хранятся резервные копии проблемного задания бекапа и после снова запускаем задание.
После проделанных действий ошибка пропала и бекап снова стал выполняться.

Ошибка «FC initiators list is empty» в Veeam Backup & Replication 9.5 Update 4

После обновления Veeam BR до обновления Update 4 стала появляться периодически ошибка «При бекапе виртуальной машины возникает ошибка «FC initiators list is empty«.

Причина: данная проблема возникает после установки Update 4, если в инфраструктуре используется хранилище Dell EMC Unity и когда в задании резервного копирования используется настройка «Автоматический выбор прокси-сервера».

Решение: на сервере Veeam BR необходимо создать ключ в реестре. В следующем обновлении Veeam данная проблема должна быть решена и ключ в реестре нужно будет удалить.

  1. Запускаем regedit
  2. Открываем ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
  3. Создаем ключ типа REG_DWORD с названием EMCUseUnityApi и со значением 0.


Ошибка «SCP Wrong response: 1scp: ambiguous target » в Veeam BR

Привет! Столкнулся сегодня с такой ошибкой в отчете резервного копирования, который Veeam присылает на почту:
Error: SCP Wrong response: 1scp: ambiguous target
В логе с именем файла task.<имя сервера>.log, который находится в директории C:\ProgramData\Veeam\Backup\<имя задачи>\ на сервере Veeam BR я нашел следующую строчку:
Info [LinuxEpBackupManagementService] Uploading local file C:\Scripts\rhel-share_do-backup-catalog — Job ABS_FIO.sh to /var/lib/veeam/scripts/rhel-share_do-backup-catalog — Job ABS_FIO.sh on target machine.
Как видно в строчку в строке с директорией содержатся пробелы. Если посмотреть настройки этой задачи, то в настройках «Application-aware processing» можно обнаружить подключенный скрипт, который в своем имени содержит пробелы.
Чтобы ошибка пропала достаточно в имени скрипта убрать пробелы или заменить их на знак «подчеркивания». Ошибка после этого пропала.

Автоматическое восстановление базы данных SQL из Veeam Backup

Понадобилось автоматически восстанавливать MS SQL базу данных из Veeam Backup & Replication 9.5. Задание должно было запускаться сразу после того, как заканчивалось резервное копирование и восстановление должно было происходить на другой сервер. Вот какой скрипт у меня получился:

Add-PSSnapin VeeamPSSnapIn

$source_host        = "SQL_Original"
$source_db1         = "DB1"
$source_db2         = "DB2"
$source_db3         = "DB3"
$source_db4         = "DB4"
$target_host        = "SQL_Target"
$target_cred        = Get-VBRCredentials -Name "onix\onix_backup"
$target_instance    = "test"

$target_db1    = $source_db1
$target_db2    = $source_db2
$target_db3    = $source_db3
$target_db4    = $source_db4

$(
$restorepoint = Get-VBRApplicationRestorePoint -SQL -Name $source_host| Sort-Object creationtime -Descending | Select-Object -First 1
$database1 = Get-VBRSQLDatabase -ApplicationRestorePoint $restorepoint -Name $source_db1
$database2 = Get-VBRSQLDatabase -ApplicationRestorePoint $restorepoint -Name $source_db2
$database3 = Get-VBRSQLDatabase -ApplicationRestorePoint $restorepoint -Name $source_db3
$database4 = Get-VBRSQLDatabase -ApplicationRestorePoint $restorepoint -Name $source_db4
$restore_session = Start-VBRSQLDatabaseRestore -Database $database1 -ServerName $target_host -InstanceName $target_instance -DatabaseName $target_db1 -GuestCredentials $target_cred -SqlCredentials $target_cred -Force -Wait
$restore_session = Start-VBRSQLDatabaseRestore -Database $database2 -ServerName $target_host -InstanceName $target_instance -DatabaseName $target_db2 -GuestCredentials $target_cred -SqlCredentials $target_cred -Force -Wait
$restore_session = Start-VBRSQLDatabaseRestore -Database $database3 -ServerName $target_host -InstanceName $target_instance -DatabaseName $target_db3 -GuestCredentials $target_cred -SqlCredentials $target_cred -Force -Wait
$restore_session = Start-VBRSQLDatabaseRestore -Database $database4 -ServerName $target_host -InstanceName $target_instance -DatabaseName $target_db4 -GuestCredentials $target_cred -SqlCredentials $target_cred -Force -Wait
) *>&1 >> "C:\SQLRestore_errors.log"

Все достаточно просто: берется оригинальный хост с базами данных, список баз для восстановления, хост на который надо восстановить, учетная запись от имени которой будет восстановление (должна быть сохранена в «Manage Credentials» и целевой инстанс SQL если требуется). Находится последняя точка резервного копирования базы (на точку восстановления с проигрыванием логов восстановиться можно, но не получится это сделать автоматически) и восстанавливается. Если происходят ошибки, то они выводятся в текстовый файл (в консоли Veeam ошибки работы скрипта показаны не будут).

Остается в задаче, которая бекапит SQL-сервер, настроить запуск скрипта, делаем это в «Advanced Settings». Задаем так строку C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noninteractive -file «C:\Scripts\SQLRestore.ps1»