Veeam.Backup.AgentProvider.AgentClosedException, #01674090

[rreed]

Afternoon, all. Fresh v9 install on a fresh VM. Removed a few existing proxies from our old v8 setup, added to our new v9 server (upgraded agent, installer, etc. successfully). Disable old job on old server, build from scratch on new, map backup to existing backup files on repository. Sees everything fine.

Random jobs fail w/ "Error: Exception of type 'Veeam.Backup.AgentProvider.AgentClosedException' was thrown." Case #01674090 being worked, log files sent, etc. A few things found in logs pointing to Oracle servers and VMware workstation, neither of which do we have here.

CBT has been reset, file locks, temp data, reboots, etc. No change. Anyone else seeing this in a fresh install/migration of v9? Searching shows up some old hits from way back that don't appear relevant to our case.

[rreed]

Having been going on from the get-go, after a handful of days now it seems it happens more frequently w/ some VM's than others, but overall still a bit random.

[rreed]

So far have narrowed this down to a bad proxy. Working w/ support and continuing to investigate.

[Einar]

I am having this problem.

[foggy]

Einar, please contact support for investigation.

[rreed]

Confirmed ours was just a bad proxy. Uninstalled/re-installed all Veeam agent, etc. still no good. I'll be wiping the VM and re-cloning a fresh one.

[rreed]

Afternoon, everyone. This error has come back again, and after opening another case (#01697389), apparently is was mostly just because one of our Data Domains was having another episode of not authenticating any connections.

In v8, we'd see a very clear "bad username/password" in the job status and subsequent report. Easy, just reboot the DD and be on our way in about 5 minutes. In v9, I see "Veeam.Backup.AgentProvider.AgentClosedException" is now its generic error when something fails, leaving me to comb through log files to find what the problem is rather than giving something useful at the console/emails/reports. Errors/issues so far have not been isolated to a single storage device needing a reboot, we've had other misc. issues since v9 that throw "Veeam.Backup.AgentProvider.AgentClosedException" whereas v8 would have given some hint at least. We lost a night or two of backups because I thought this error was somethign more serious than our stupid DD's being themselves; I could have rebooted it had Veeam thrown it's useful error.

Do we have some sort of generic alert turned on in our bone stock v9 install? Is there a switch I can flip somewhere that will replace the AgentClosedException error w/ its previous more useful information when something underneath fails? Hate to complain, but it's costing us more time and lost backups when we have to go chasing around log files, investigate, etc. rather than know right away what I need to go do to fix it.

[foggy]

In our lab, in case of insufficient permissions v9 correctly reports this event in the job log. QA briefly looked into your logs and apparently this does not come down to DD authentication issues only. There are multiple other access issues in the logs where DD is not involved (for example, when source agent connects to VMware). So seems like there are more global authentication issues in your environment and I recommend looking deeper into this with the help of our support engineers.

[rreed]

Thanks foggy. So if I understand correctly, we're getting "Veeam.Backup.AgentProvider.AgentClosedException" in the status/reports because we have a permissions issue, regardless of the underlying cause (naughty DD, proxies actively refusing connections, etc.)? And yes sir, I'll open up a new ticket right away.

[foggy]

Cannot comment on what specific reason is behind this particular message, logs should tell.

[nahuise]

Same problem here. I disabled the proxy on the veeam server and added an extra proxy. Let's see what happens next.

[nahuise]

Just checked all backup jobs from the past weekend. After friday's adjustments all jobs went ok. So next question is how to repair the veeam backup proxy? I had to switch to this server because the old server (2008R2) didn't support the exchange filesystem. I moved all jobs from the old server to the new. Worked fine for one week till this problem occured.

[veremin]

As a first step you try to re-install required components by removing and re-adding the proxy role to the given server. If this doesn't fix the issue, you'd better open a ticket with our support team and let them confirm your environment. Thanks,

[nahuise]

Thanks. Tried the first step. I'll open a ticket this week.

[boyjaew]

Case# 01872048
B&R v 9.0.0.1491
Server 2012 R2

Backup (7TB) and backup Copy (based on same backup). Backup copy was seeded initially and worked for about 2 months.
Randomly fail with:
1) Source WAN accelerator error: Socket recv operation timed out
2) 'Veeam.Backup.AgentProvider.AgentClosedException' was thrown

While backup will complete occasionally I haven't gotten a viable backup copy of it off site in over a month. I have removed proxies as suggested in previous posts and thought that did the trick, but it has returned.

[rhoughton]

Had the same for 2 months - so far my actual support call has been interesting!!

Searched the log file and found the error message myself

Support Ref: 01926820

[Matt.Sharpe]

Hi Guys,

Has anyone seen this error before on the WAN accelerator.

Receiving it on one of our customer jobs:

Error: Target WAN accelerator error: Socket recv operation timed out.

[PTide]

Matt, please contact support for investigation and post your case ID.

Thanks

[rnt-guy]

Anyone had luck with this? A job has been doing this for a while. All the VMs backup just fine, but it's getting this error multiple times per session during the merge process.

Case #02033450

[Mike Resseler]

Hi RNT-Guy,

I have no solution for you unfortunately, but considering this entire post and many people who had the issue, I'm sure our support knows where too look. Please keep working with support and let us know the results
thanks
Mike

[rnt-guy]

Thanks. So eventually a seed job that was also running for a few days straight finished and then the next attempt by this other copy job finished the merge process. I'm not sure how to explain it other than to say they got in one another's way?

[Mike Resseler]

Did that seed job had anything to do with the other job?

[rnt-guy]

They were the same source storage running at the same time to the same destination, but that's about it. Different VMs.