Feature Request: more granular 'retry' info

[edison5000]

When you see the 'running' status of particular machines in jobs, it will say "Retry ##" - indicating that whatever backup it is currently trying to complete, it has tried ## times. I was under the impression that this solely meant that a machine had attempted to complete a full initial backup but kept failing. And then after completing the initial full, maybe would stop reporting 'retry'. Now that we've backed up a few hundred machines, I see that is not the case. I believe what it is telling you is : whatever last job it has tried to successfully complete, has failed, and it is trying again.

eg, It would be handy to see more info, like -

Retry 3 - job incremental

or

Retry 5 - job first full

or

Retry 2 - job 3rd full

or

Retry 1 - user started incremental

etc


Thanks!

[HannesK]

Hello,
thanks, sounds like a minor improvement that makes life easier.

Question 1: do you ever run full backups after the first? Because most customers go with incremental forever modes, so the question whether it's full or incremental never appears after the first run.

Question 2: what do you do with that information? Is it just "looking nicer", or any technical advantage?

Best regards,
Hannes

[edison5000]

We are using forever incremental right now, but new machines are getting put on the network all the time.

Primarily it's a problem with the mobile users; they're always turning machines off and on, or vpn-ing, or just losing connectivity for reasons, so everything is much slower.

If you are saying 'retry' is *only indicative of an attempt to backup a first full*, I thought that was not true? But if it is, then my suggestion may be unnecessary. : )

At some point presumably, Veeam will have the ability to allow admins to configure B&R to allow an incomplete backup to continue from where it left off when Task Ended Unexpectedly , and that may solve this a bit.

Aside: We thought about turning on caching, if the directors approved it - but - I don't think that solves this problem either, since I don't know if Veeam considers a successful cached backup 'Successful' or not... but even if it did, then, once the remote system reconnects, it would still have to copy all that cached data up to the server before it does a new backup. For remote systems, the cached backups would just pile up... if a cached backup isn't successfully transferred, does that generate similar error? "retry #"? And would that be retry # of uploading cached data, or attempt to get a new backup once the cached data is uploaded? Sorry for the digression.

[HannesK]

Hello,

Primarily it's a problem with the mobile users;

okay... I moved the topic to the servers & workstation forums, because posts in the general forums indicate, that it's about virtual machines in a data center.

"retry" exists for full and incremental. I tried to say, that with incremental forever, the chances for a "full retry" are relatively low (in a datacenter).

I'm still not sure, how much it would really help to change the text of the "retry". The main challenge seem to be standby, lack of bandwidth etc.

Best regards,
Hannes

[edison5000]

Thanks Hannes. Yes, as I said, if Veeam would just let a full continue from where it got cut off in the middle, this might become unnecessary.

So to confirm: the 'retry #' is *only* indicative of a failure to complete (an initial) full? Or does it show 'retry' every time it fails to complete the next backup in a schedule/action?

[HannesK]

hmm, I reword my last answer
1) if a full backup fails, the software will retry
2) if an incremental backup fails, the software will retry

if Veeam would just let a full continue from where it got cut off in the middle

Veeam Agent for Windows has that feature

[edison5000]

Understood. In that case, a more detailed explanation of 'retry' per agent would be useful.