There is no action lease with same id

[dellock6]

I'm receiving this error for the first time this evening on several jobs, and we have not changed any configuration on the environment.

There is no action lease with same id. LeaseId [471a9635-302e-4b86-a01e-ef7c67c089b4]

I found this article as the only one stating the same error:

http://www.veeam.com/kb_articles.html/KB1237

but I have some differences between the article and my environment:
- mine are backup jobs
- I'm using iscsi storage and hotadd mode, no NFS around
- I'm using version 6.0 (fully patched) and not 5

Any idea? Or I need to open a ticket?

[Gostev]

Looks like that KB article is completely irrelevant then... yes, please open a ticket.

[dellock6]

Opened ticket ID#5189883, let's see how it goes.

[dellock6]

I got a reply from Support, the problem is the slowness of the target storage, causing some timeouts to the jobs; this is one of the many possible errors that can come out in such a situation.
We need a faster storage, I cannot afford to slow down any more the backup jobs since we are almost hitting the backup windows. As always, at the end it's all about the target storage.

[Gostev]

Hi Luca, I checked with the support lead and looks like target storage is not an issue? They said the issue was SQL Server lacking memory, and that the error went away once you added more memory. Can you confirm? Thanks.

[dellock6]

Hi Anton, I've been fooled by the fact the Veeam Server has proxy disabled (I know, unsupported...), and it acts as a central console BUT also as the only backup repository, and is then connected to the physical target storage.
When we were using proxies with 3 cuncurrent jobs each, target was the bottleneck. I then got the error I quoted, and I decided also to reduce the cuncurrent jobs to 2 but we still got errors. To be sure it was only a matter of RAM, I'm waiting to have some days with 0 errors in jobs (today was the first) and then I will try to use again 3 cuncurrent jobs. In this way I think I will find out if RAM was the only issue, or the target storage is also a problem (as I'm already telling to my boss from months...)
Another step would be to create a secondary Veeam Repository server to distribute the load created by proxies, but running in a VMware VSPP license means we are charged by the RAM we used, so it's not easy to get authorization to deploy other servers

Anyway, I'm getting fun in fine tuning Veeam, one setting at a time, cause it's really responsibe to any change I made and I can quickly evaluate pro/cons of any setting I try

[mcvosi]

I had this error come up today on my 6.5 install. I simply recycled all the Veeam services and re-ran the job. All went peachy.

[dellock6]

Yep, seems sometimes a Veeam server with a long uptime degrades its performances especially on RAM and it involves first of all the SQL server, if it's an embedded one it even more frequent. I doubt is Veeam fault and more about how Windows manages ram inside the OS.
Our solution was, at a certain point, to move the SQL database to a separated server and most of all to a SQL standard instead of a express one. 6.5 export/import was a great help!

Luca.