Feature Request - User control over automatic retries

[kchan]

Allow the same control over automatic retry as in Backup & Recover. The user can select the number of times to retry a failed backup and the time to wait between each retry attempt.

[Vitaliy S.]

Thanks for the feedback! Can you please elaborate a bit more on why such granularity is required? It would help us in prioritizing features for the next updates.

[Dima P.]

kchan,
Also interested in your request, because Veeam Endpoint Backup has 23 hours automatic retry cycle which is always on - it restarts the backup job every 10 minutes unless the backup is completed.

[Beheer]

I also would like to see more (let's say any) control on the amount of retries, just like in B & R.
So the amount of retries allowed and eventually the time interval between retries.

As we know, Endpoint Backup is free, and can be used by any private person who knows that the word "Backup" makes sense to care about.
But, all the Backup & Replication users at companies, who take care of all the VM backups, have welcomed Endpoint Backup as an opportunity to backup those physical servers that cannot be virtualized right now or in the near future. Especially if they have chosen to use just one backup solution, like we did.
So the outside world actually sees Endpoint Backup as an enhancement on Backup & Replication. Look at it as special client software that comes with the package.
I'm very happy that Veeam decided to relase Endpoint Backup!

So therefor we would like some control. In our company, it is allowed for a backup to not run occasionally. I don't have to call in during weekends or holidays to check backups every few hours. So now for instance, a backup didn't run for almost two days (it should run once a day), and I have a few hundred log entries polluting my History and making it that I would have to increase the "Show only last 500 sessions" in B&R to be able to look back for more than a week.

It is like the Application awareness that can now be switched off with a registry key, just a few things to make it easier to use for professionals would be nice.

Thanks in advance for looking into it,
Han

[Gostev]

Are you talking about B&R history? And your issue is not with actual retries happening every 10 minutes, but rather with B&R log pollution they are causing? Thanks.

[Dima P.]

QA will check it - thanks for the heads up!

Meanwhile, may I recommend using the global email notification option as a proper tracking solution for VEB jobs?

[Beheer]

@Gostev,
Actually I was talking about both. In a production environment it can be seen as pointless to retry every 10 minutes for a long time when the conditions don't change because there is no one around, like during the weekend. And of course log pollution is what I would call "pitty", the entries can't be deleted and it causes a lot of scrolling once something happened. So, a retry interval and time period would be very much appreciated!

@Dima,
I know about the email notification options, but decisions about when we have to act outside office hours are made within our company. In this case where I had the issue, it concerned a test application VM. When the backup fails once we are not requested to take care of it during the night or weekends...

Thanks and regards,
Han

[Dima P.]

Beheer,

Thanks – good catch. We will discuss with the team how it can be enhanced in the upcoming releases.

[Gostev]

Actually I was talking about both. In a production environment it can be seen as pointless to retry every 10 minutes for a long time when the conditions don't change because there is no one around, like during the weekend.

Well, you have to remember though that this tool is designed for endpoint backup, as opposed to servers sitting in the data center. And for the former, condition do change very quickly. For example, when I swing by the office and get connected to the office network for a short period of time - if those retries do not fire often enough, the window of opportunity to perform a daily backup will be missed. This was the thinking behind the current retry schedule.

[beretta]

I received ~50 email notification from veeam endpoint backup for a failed backup job.

50 Retries is ridiculous, I don't want that many emails in my inbox on the holidays or when there are problems. Even a registry hack would be great to give us control on this setting.

I actually use it for one server and one IT computer that are in my server room that are physical and not virtualized.

Gostev, if you wanted to backup when the VEB client is connected, why not put something on the client that says backup when access to Veeam registered storage is available rather than blindly try every ten minutes for 50-100 times.

[Dima P.]

Hi Brett,

I received ~50 email notification from veeam endpoint backup for a failed backup job.

Is that happening during one job run? If backup job fails and then gets retried, you should get one email report regarding first fail and one email report after last retry.

if you wanted to backup when the VEB client is connected, why not put something on the client that says backup when access to Veeam registered storage is available rather than blindly try every ten minutes for 50-100 times.

There is a schedule option to backup only when backup target is connected. When it is the only backup event - it works exactly like explained.

[flash79]

Hi

We've the same problem. Veeam Endpoint Backup or Veeam Agent Backup is designed for private use, but you can also use it with Veeam Backup & Replication. So why we shouldn't use it? And if you have some physical servers you logicaly use VEB. Better than another SW isn't it? You can enable in the E-Mail options "suppress notifications until the last retry", which is a nice feature that you won't get spamed. But if the VEB doesn't success you'll never get E-Mail for 24 hours...thats stupid. So it's important that we can decide how many retries veeam should do. my opinion.

Greetings
flash79

[Dima P.]

Hi Roger,

Thanks for your feedback! VAW 2.0 server edition has customizable retry counter and delay between retry cycles. Beta version is publicly available, so you can test it now