Hi Sekaraj,

Are you running VADP backups or client based backups for the VM's?

What is the configuration you set?

What is the error message you are getting when running the backup from the server?

Thank you.

Carlos.

What kind of backup are you doing?  VM backup or guest level backup?  Since manually initiated one is guest level so if from server you are trying to do VM snapshot, then it is not the same.  Did you verify if, while queued, there is no pending message on server side?

I am running client based backups for the VM's.I have just created a client configuration how we do normally for a physical host.?It seems to be running fine and suddenly we have this issue as I said client initiated backup from VM seems to be running fine and server initiated backup when kicked off it is queued status and I don't see any alerts on NMC.It looks wired as  ping,nslookup and probe,rpcinfo everything seems to be fine.

From the backup server I have run the below command and it could connect to the client successfully.

nsradmin -s -p 390113

we have rebooted the server twice but the still same issue.

On the client properties I have also selected virtual client box and updated the ESX server name on the physical host box but still the same.

Any suggestion?

Hi,

Run the group from the command line on the NetWorker server and check the output file.  This should tell you where this stops in the backup process and maybe even why:

savegrp -vvvv -D9 [group_name_here] > test_backup.log 2>&1

-Bobby

Bobby,

I have run the backup in D9 mode and below is the last few lines and it is not doing anything,

gbmlvimqap05:C:\ (1497721) Received job state change message from UNKNOWN to CREATED gbmlvimqap05:C:\ (1497721) Processing job state change from CREATED to CREATED sg_pick_next_job(): Entry... Received job state change message gbmlvimqap05:C:\ (1497721) Received job state change message from CREATED to QUEUED gbmlvimqap05:C:\ (1497721) Processing job state change from CREATED to QUEUED sg_pick_next_job(): Entry... lg_open(): Calling open64().

4690:savegrp: Adhoc1M_4 waiting for 4 job(s) to complete

sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry... sg_pick_next_job(): Entry...

Hi,

Check which storage node you are sending this data to.  Make sure there are volumes available in the pool and that it is going to the correct pool.  If you are not sure, create a new pool and label a volume in there using the group name as the only selection criterion.

-Bobby

AbelC wrote: I have same error but with oracle RMAN -> nmda. That solution didn't help, in fact, if launching the rman script client side, it works, and uses same pool and same storage node as launching backup server side. Even filesystem backups of this client, scheduled or manually launched server side, don't work. :

If FS backup doesn't work, I doubt Oracle will.  In your case most likely you have network issue (either port restriction or naming convention or NSR auth model) which usually causes results as you have.

I never had this issue and I backup on regular basis 400+ Oracle databases for past dozen years. I don't think what you have is typical issue, but rather something specific.