How to start backup only for one VM from job?

[MAA]

Hello,
I have backup job with multiple VM's.
One VM backup fail, and i need restart backup only for this VM.

[Regnor]

Either Rightclick the Job and select Retry, or go to Inventory and start a Quick Backup of the VM.

[MAA]

>>Rightclick the Job and select Retry
Job is running, and "Retry" is grayed out

>>or go to Inventory and start a Quick Backup of the VM
"Unable to perform quick backup. Reason: required backup job is running"

[Natalia Lupacheva]

Hi,

yes, quick backup can help you to back up on of the VMs in the backup job.
Do you need to back it up before the backup job is finished?

Thanks!

[MAA]

>>Do you need to back it up before the backup job is finished?
Yes. (job will end only after a few days, due to this issue: vmware-vsphere-f24/b-r-is-not-smart-enough-t69787.html)

[foggy]

You cannot start the job while it is running. But you can create another job to backup the same VM or use VeeamZIP. The backup will be full though.

[Regnor]

>>Rightclick the Job and select Retry
Job is running, and "Retry" is grayed out

I'm sorry I didn't get that from your initial post.
Like Alex said, as long as the job is running you won't be able to start another session.

[MAA]

>>You cannot start the job while it is running.
>>as long as the job is running you won't be able to start another session.

This is a very strange and annoying limitation. I hope this will be fixed in future versions.

[wishr]

If one process is already running you cannot initiatee it again until it finishes. Isn't it logical?

Also, do you have automated job retries enabled?

To get rid of the log-running job you should follow the recommendation to perform the migration using vCenter capabilities as mentioned in the thread you linked or take care of the MoRef ID changes cause by the action you performed on your own. This might have prevented all the issues you are currently facing.

[MAA]

>>If one process is already running you cannot initiatee it again until it finishes. Isn't it logical?
No. Job have multiple VM's(processes). Failed VM process is not running.

>>Also, do you have automated job retries enabled?
"Automatic retry-Retry failed items processing: 3 times" is enabled by default, but i also need "Manual retry failed item"

>>follow the recommendation to perform the migration using vCenter capabilities
I always migrate VM via vSphere web-client

[wishr]

A job session is a process here. So in your particular situation, you should wait for the current session to finish, and then, if the job session has failed to back up a certain VM during the initial attempt and further retry attempts it will be backed up during the next job session (if the root cause of the failure is resolved, ofc.), as the backup file for the current session will have been already created at the end of the current session.

[MAA]

As I already wrote - I really would not want to wait for the backup job to finish.
It is a very unpleasant situation that the backup of one VM blocks the backup of all the others.

[veremin]

But it doesn't block anything - other VMs get backed up within the same process. Then, the process gets retried for failed VMs. Thanks!

[MAA]

It is very sad that you do not know your own product well and do not understand what I am talking about.
One very long-running VM backup process prevents the scheduled backup of the rest of the VM's.
At the moment I have just such a situation - backup job with multiple VM's, but only one VM is being backed up at a time. And this will continue for several days. The rest of the VM's have to wait, as their backup cannot start due to B&R limitation.

[Regnor]

There's no way around waiting for all VMs to finish before Veeam schedules the next run/retry.
If you know that this VM will take several days to backup why don't you create a new job for that VM?

[foggy]

It was not expected as the observed behavior was caused by a CBT issue discussed in the mentioned thread, so I'd say it is a coincidence of several factors plus some environmental specifics.

Btw, @MAA, you didn't mention the bottleneck stats for this job - even an active full shouldn't normally take that long, so maybe we can give some advices regarding your setup optimization.

[YouGotServered]

@MAA it's a fairly logical process - VMs are grouped into a job, and a job runs on schedule. You can't really run individual parts of a job If you need the flexibility to backup individual VMs at a time due to environmental circumstances, you should split up your jobs so that you have the flexibility to do what you want. For example - when you start a car, you typically start the whole powertrain at once. Why? BEecause it's logical. It usually isn't necessary to run the engine, but not the transmission, alternator, etc.

It's a good idea to look at your environment as a whole and determine risks and ways to mitigate them. In your case, you have a large VM that you are backing up offsite. There's a chance you may be stuck having to re-send that VM at some point in time (loss of backup repository, corruption, a change made by IT that causes the VM to be re-backed up). Given that chance and risk, you should design appropriately. Since you may be stuck with a days-long job, maybe it makes sense to not put all of your VMs in one job, but split them up in multiple jobs for easier management and greater flexibility. This is why most cars have an option to just start the electronics (air, radio, lights, etc) - someone thought it would be necessary and useful to split them into their own, separate function (like a dedicated backup job) so that they didn't have to start the engine if they just wanted to listen to the radio.

As others have suggested in your previous forum, you may want to redesign your overall backup strategy, as it seems to open itself up to risks as is. Veeam is a very complex product and is only as good as your backup infrastructure design and implementation.