Hi Everyone, I was hoping for some advice on an issue I’ve found after upgrading to V6 of Veeam Agent for Windows free edition on Win 10 22H2.
I’m not sure why but until I upgraded from V5 to V6 my backups were running fine every evening and completing without any issues, since the upgrade to V6 the backup starts but either sits at 0% 14% or 18% and regardless of how long the PC is left running it never seems to get past this point. I’ve disabled throttling in the menus in the hope this was slowing the backups down but its had no effect on them.
The total “full backup” size is around 1Tb split across a Sata M.2 boot drive and a regular old 1Tb spinning disk, I’m running Kaspersky AV for reference.
The only change I’ve made is the upgrade from 5-6 is is possible to downgrade back to 5 to test if this is a veeam issue on the PC or will that force a new backup ?
Any advice would be appreciated as I’m at a loss as to why the backups have just started taking so long.
*Edit* I’d also like to mention the backup destination is a 3Tb Qnap, both PC and NAS are connected via a home router and all three devices are wired at 1Gbps
Kris
Have you done all AV exclusions and also check the logs too here C:\ProgramData\Veeam\Backup to see if that helps with troubleshooting.
Have you done all AV exclusions and also check the logs too here C:\ProgramData\Veeam\Backup to see if that helps with troubleshooting.
Hi Chris, looking in the log folder there’s an old driver.veeeamflr.log that hasn’t been touched in about a year, there's only one other file in a subfolder called BackupSearch, that has an entry in it for the current job but doesn’t have anything in it that would indicate a problem to me (the logs posted below).
I have the exclusions in place suggested by this article (https://www.veeam.com/kb2034), if I’m missing any I’m happy to add them to see if that makes a difference.
Log - -
b03.06.2023 16:54:34.184] < 7288> | LOG: Initializing log file for process with PID 5116
t03.06.2023 16:54:34.184] < 7288> dllini | ====================================================================================
=03.06.2023 16:54:34.184] < 7288> dllini | {
;03.06.2023 16:54:34.184] < 7288> dllini | Veeam Backup Search DLL.
B03.06.2023 16:54:34.184] < 7288> dllini | Version: 1.0.0.1050
03.06.2023 16:54:34.184] < 7288> dllini | Process: 8C:\Program Files\Veeam\Endpoint Backup\Veeam.EndPoint.Service.exe]
a03.06.2023 16:54:34.184] < 7288> dllini | PID: 5116
t03.06.2023 16:54:34.184] < 7288> dllini | }
&03.06.2023 16:54:34.184] < 7288> dllini | Library instance has been initialized.
03.06.2023 16:54:34.184] < 7288> vsdll | VeeamSearchSdk_InitLibrary: initializing...
c03.06.2023 16:54:34.184] < 7288> vsdll | VeeamSearchSdk_InitLibrary: initializing... ok.
h03.06.2023 16:54:34.184] < 7288> vsdll | VeeamSearchSdk_StartService: starting search service...
S03.06.2023 16:54:34.184] < 3392> | Thread started. Role: 'Pipe server', thread id: 3392, parent id: 7288.
P03.06.2023 16:54:34.184] < 7288> vsdll | VeeamSearchSdk_StartService: starting search service... ok.
Are you on the latest version of the agent? 6.0.2?
Are you on the latest version of the agent? 6.0.2?
yes, currently using 6.0.2.1090.
Are you on the latest version of the agent? 6.0.2?
yes, currently using 6.0.2.1090.
Only other suggestion I can think of would be to do a full uninstall, reboot and then reinstall the software. You can then direct the backups to the existing chain you have on the backup location.
Are you on the latest version of the agent? 6.0.2?
yes, currently using 6.0.2.1090.
Only other suggestion I can think of would be to do a full uninstall, reboot and then reinstall the software. You can then direct the backups to the existing chain you have on the backup location.
Hi Chris,
So I've uninstalled and re-installed the Veeam software, with a reboot in-between. I’m not sure if this fixed the agent or it was the fact that I opted to-do and Active Full backup when I ran it next, but after 6 hours the backup completed last night and its just finished an incremental that took 5:50.
So it looks like its working again, but I’m not entirely sure what fixed it in the end, just wanted to say thanks for the advice and help.
Kris
Are you on the latest version of the agent? 6.0.2?
yes, currently using 6.0.2.1090.
Only other suggestion I can think of would be to do a full uninstall, reboot and then reinstall the software. You can then direct the backups to the existing chain you have on the backup location.
Hi Chris,
So I've uninstalled and re-installed the Veeam software, with a reboot in-between. I’m not sure if this fixed the agent or it was the fact that I opted to-do and Active Full backup when I ran it next, but after 6 hours the backup completed last night and its just finished an incremental that took 5:50.
So it looks like its working again, but I’m not entirely sure what fixed it in the end, just wanted to say thanks for the advice and help.
Kris
Not a problem at all always here to help as best I can. Glad you were able to get it fixed.
Hello,
we’re using veeam agent 6.1.0.349,
since January we have the Problem that the backup with target network drive is not completing, it stucks at 68%.
I already upgraded to the actual version, because we faced the problem first with 6.0.xx
Any idea ?
I de-installed and re-installed already.
Hello,
we’re using veeam agent 6.1.0.349,
since January we have the Problem that the backup with target network drive is not completing, it stucks at 68%.
I already upgraded to the actual version, because we faced the problem first with 6.0.xx
Any idea ?
I de-installed and re-installed already.
Did you check the logs to see if there are any errors that can lead you to the problem? Also what sort of target is the network drive - NAS, SMB Share, CIFS, etc.?
Logs are here - C:\ProgramData\Veeam\Endpoint\JobName
Hi,
I found in the log:
[12.01.2024 14:06:43] <01> Info AP] Waiting for completion. Id: I0x22f919d], Time: 04:30:00.0655392
r12.01.2024 14:21:28] <52> Info AP] (2531) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
12.01.2024 14:21:28] <61> Info nAP] (044a) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
t12.01.2024 14:21:28] <52> Info tAP] (20dc) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
12.01.2024 14:21:28] <62> Info :AP] (7462) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
i12.01.2024 14:31:24] <42> Info 0AP] (20dc) output: --asyncNtf:--busy: Target backup repository is overloaded.
:12.01.2024 14:31:24] <14> Info
)12.01.2024 14:36:43] <01> Info AP] Waiting for completion. Id: 10x22f919d], Time: 05:00:00.0671513
12.01.2024 14:51:28] <62> Info ,AP] (2531) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
12.01.2024 14:51:28] <57> Info uAP] (7462) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
12.01.2024 14:51:28] <54> Info lAP] (044a) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
f12.01.2024 14:51:28] <61> Info nAP] (20dc) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.
it is Agent.VbkManager.log
it is a windows share on a file server.
actually I’m trying to backup on an local usb stick.
with the same problem: stucked at 68%
There is definitely something with the target repo based on this message -
[12.01.2024 14:31:24] <42> Info AP] (20dc) output: --asyncNtf:--busy: Target backup repository is overloaded.
I would look in this direction otherwise open a Support ticket to get further assistance.
Hi,
what is the target repo ? the vbm file ?
Hi,
what is the target repo ? the vbm file ?
The actual repository you are writing the backups to - Target Repository
Based on the messages Veeam is having to wait to write to the target repository.
so that is the usb drive directory ? or the network drive, when I’m writing to a network drive ?
right ?
so that is the usb drive directory ? or the network drive, when I’m writing to a network drive ?
right ?
Yes, either one of them - where Veeam is writing the backup files to - that is the repository.
ok, thank you Chris.
I guess I have to open a ticket, because especially when writing to the usb drive nothing should disturb that. and there is enough space on the drive.
ok, thank you Chris.
I guess I have to open a ticket, because especially when writing to the usb drive nothing should disturb that. and there is enough space on the drive.
I would recommend that so they can deep dive the logs for you. Let us know how it turns out.
Comment
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.