Undocumented feature

[simeonh]

Hi there,
I had some issues with a backup job in Veeam version 5.0.2 (latest version currently as of 15th June 2011)
Basically when the backup job ran it failed on a critical VM, because of issues with snapshots not removing properly.
I Disabled the Veeam Backup job once it finished, and once i started working on resolving the issues with the snapshots that couldn't be removed the annoying Undocumented Feature of the Retry function Veeam Backup Jobs have, kicked into action and started trying to backup the vm while i'm troubleshooting the issues with the snapshots, so as normal it creates another snapshot, and i get all these errors with trying to remove them at the same time veeam is trying to create them!

Is my logic not right, for me to assume if a Veeam Backup Job is Disabled the Retry function should also be disabled!

Is there a way of disabling the retry function temporarily just while you are working on a vm? or do you actually have to edit the backup job to disable the retrys, then re-add it once you have finished working with it?

[Vitaliy S.]

Hello Simeon,

Please be aware that the retry function is considered to be a part of the "main" job, that is why your job was still "running" when it finished processing the VMs.

Besides, "Disable job" option doesn't stop the job itself. It only disables it for the future passes. If you want to disable retries you should use stop job functionality and then disable this job. This should allow you to troubleshoot the VMs you need without job's interference.

Hope this makes sense.

[simeonh]

ok, thank you.

[brupnick]

The retry feature has also caused me problems in the past, to the point where I can't use it. My VBR jobs have a post command that triggers my tape backups (yes, I still have to write to tape). However, the post command is called before the retries finish. This causes my tape backup software (Backup Exec) to have a lock on the file, so VBR fails when it retires. I would think that the retries are part of the original job and that any post commands that are configured will not be executed until all VMs, including retries, have completed. I would love to be able to use retries, but the current implementation just doesn't allow it.

Also, it would be great to have the ability to run (or not run) post commands based on the outcome of the job. That is, only on success or warning, but not on failure.

[Gostev]

How would you suggest to change implementation of retries to make them more usable for you? Aside of obvious glitch explained by OP of course.

Also, it would be great to have the ability to run (or not run) post commands based on the outcome of the job. That is, only on success or warning, but not on failure.

Please note that it is possible to query job status from PowerShell and continue (or not continue) post script logic accordingly, if this helps. There are some script samples lying around here on this forum that use this approach. In fact, at least one script is intended specifically for dumping backups to tapes (I posted it a few months ago). Thanks!