Just as the message states it is waiting on resources like a Proxy server to complete the backup copy process.  Usually, if servers don’t have the resources to process the number of disks in a VM then it has to wait.

Thank you for responding!

In this situation, I am guessing concurrent tasks are the bottleneck. This error does not usually occur. Does the copyjob not do a retry in this situation? What I don’t understand is this copyjob is set to mirror on a continuous schedule, so I wouldn’t think there’d be a reason for it to error out or give a warning, and that the job would just run until it finished.

Remember you have concurrent tasks at both a repository and proxy level to help find your bottleneck  Just speculation but this could also be related to your issue if the VM you’re copying is from a separate job that’s targeted at a separate repository it could be being kept waiting as a result.

This should be no problem.

As Chris and Paul already said it is just waiting for the neccessary ressources.

In this pictures you see that this VM has waited for 22 minutes and then was processed without any issue…

In this environment I see this every day, just don’t have so many cores here...

I apologize for my lack of knowledge on this.

I received an alert in our ticketing system that the copyjob finished with a warning, and it pointed to this one particular VM. I checked the copyjob and it looked like it wasn’t running, and that particular vm was sitting in a warning status. I was confused because the job is set to run continuously, so I didn’t see a reason for the job to stop and say “Hey. Not enough resources. Better luck next copy interval!”

All of the copies are going to the same location.

If I am understanding correctly, the job should run until all current restore points are offsite, correct? If that is the case, why would a warning be thrown, rather than the VM just be put in a pending status until resources become available?

I am still a novice with Veeam and backups. I appreciate all of your help!

Fully off-topic:

@MicoolPaul, I used to think that your name is Paul too, because of your nickname   @Rick Vanover used to think you’re from France (while I was sure you’re from UK!)

Just saw that Joe called you Paul and it made me smile   (don’t even ask how many times I was called different names too LOL)

Sorry Michael, it was a mistake

It is difficult every time when a person has an often used given name as a family name.

You are welcome @bp4JC , the community is for asking questions.

Mhh… a warning did not appear in my job…

If there are further problems please post some pictures of these messages.

it’s nothing to worry about, Joe! I just found it a bit funny and shared my story!  

The paranoia of being talked about behind my back it’s been a life long issue of people calling me Paul, but I wonder if I changed my name to Paul Michael if people would start calling me Michael… 

Oh, I bet they would, @MicoolPaul! Not much we can do

Just one thing though if this is a backup copy job then I don’t think it would be leveraging proxies since those would be only for backup and replication tasks. Repository though is always a prime suspect as everyone mentioned, concurrent tasks and resources. 

cheers

Yes, just wanted to add that actually, backup copy involves repository-to-repository processing, so no proxies are involved. Furthermore, backup copy jobs have lower priority than restores and primary backups in our resource scheduling algorithm. Hope this may help in identifying the cause of the waiting. Also, in the logs (usually C:\ProgramData\Veeam\Backup\<Name_of_job>) normally you can find the resource VB&R is waiting on.

Is there anyway to avoid these warning if the waiting is expected? In my case this is a copy job that is waiting for the primary backups to complete and is waiting as expected. I didn’t have this issue until I upgraded to version 12.

In general, if a job / specific task is waiting for resources, it does not raise a warning - eventually the resources will be available and it will run. If no failures are encountered, the end result will be “success” (green). See an example in this post from this very thread.

The scenario of the original poster here involved a Backup Copy job that was waiting for resources for a long time, exceeding the configured sync interval (thus failing to achieve the desired RPO for the Backup Copy). That of course raises a warning.

Please give us more details of your specific scenario, so we can better assist you in identifying potential issues. Thanks!