Привет! При бекапе большой базы данных на хранилище, располагающееся на 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 (порядок произвольный) на серверах, откройте консоль, включите задания резервного копирования
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.
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) Делаем рескан репозитория, где хранятся резервные копии проблемного задания бекапа и после снова запускаем задание.
После проделанных действий ошибка пропала и бекап снова стал выполняться.
Системная служба заняла всю свободную оперативную память
Возникла проблема: на двух серверах Windows Server 2008R2 SP1, на которых давно не ставили обновления и которые не перезагружались больше года, кончилась свободная оперативная память на сервере. При беглом взгляде было обнаружено, что проблема вроде бы как в системных службах, в частности в службе «Установщик модулей Windows» (aka TrustedInstaller). После ее перезапуска проблема не устранилась, тут же другая системная служба заняла всю доступную оперативную память. И тут пришла идея проверить количество дескрипторов, занятых процессами..
Сразу стало понятно в чем источник проблемы. Перезапуск службы «Digi Anywhere» инициировал активную работу служб, которые заняли оперативную память и через 20-30 секунд вместо 4 ГБ занятой памяти осталось только 1 ГБ. Проблема бесследно исчезла. Так что почаще проверяйте количество дескрипторов, использующимися вашими процессами, возможно проблема в них.
Ошибка «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» можно обнаружить подключенный скрипт, который в своем имени содержит пробелы.
Чтобы ошибка пропала достаточно в имени скрипта убрать пробелы или заменить их на знак «подчеркивания». Ошибка после этого пропала.