Skip to main content

Hi all,

I have a really weird problem:

Our customer noticed, that by end of November 2020 (28th / 29th), the scheduled jobs for the VSA backups (VMware) did stop working. There are no failed jobs, but only a gap in the backup history.

When a job is started manually via the schedule policy ("run immediately"), the message "Failed to run task. No associations exist." appears. Starting the jobs manually via the subclient works on the other hand. The backup activity is not disabled on any level (Client, Agent, Backup Set, subclient, client group… ).

Jobs for other clients associated to the same schedule policies work fine. But all scheduled jobs for all subclients of the affected client do not start by schedule.

All jobs that are scheduled are Synthetic fulls with the option to first start an incremental before synthetic full enabled.

If I start an incremental job manually, the next scheduled job starts. But only once. Also, I can use “Run immediately” once when I started an incremental before. 

I already tried to clone the schedule policies, removed the associations and associated the subclients again with the new schedule policies. Also, I changed the associations for the client by switching from association by client to association by client group. The problem if I create a completely new storage policy is, that the option to first run an incremental before synthetic full is no longer available for new schedule policies.

 

Hi @Holger R. 

Thanks for the question, that is an interesting one and tricky to troubleshoot.

My first thoughts are around permissions. Does the user owner of the schedule policy have required permissions on that particular client to trigger an incremental backup?

 

There are changes from SP16 around running incremental backups before Synth Full, which is why new schedules aren’t showing the option:

https://documentation.commvault.com/commvault/v11_sp20/article?p=6789_1.htm

Note: Beginning with SP16, synthetic full backups no longer depend on incremental backups, and the Run Incremental Backup > Before Synthetic Full/After Synthetic Full option no longer appears in the Backup Options window for new schedules and schedule policies. However, the option will appear for existing schedules and schedule policies (that is, created in SP15 or earlier) that use the option.

Thanks,

Stuart

 

Hi Stuart,

 

thank you for your reply. 

 

I have changed the storage policy temporarily to do incremental instead of synthetic full. This is working. So it seems like the permission to perform incrementals is okay.

Hi Holger

Ok, so that’s permissions ruled out.

Is it possible to manually schedule Incremental backup ahead of the Synthetic Full backup as your test has confirmed scheduled incremental is working as expected?
E.g. If the Synthetic Full is scheduled at 8:00pm, can an incremental be configured at 7:00 or 6:00 so this is always performed before the Synthetic Full.

Please allow plenty time for the incremental to be fully completed before the Synthetic Full is due to start. 

Thanks,

Stuart

Hi Stuart,

yes, this a valid workaround. I was just hoping to find the cause of the issue, because the customer wanted to clarify how this happened. 

@Holger R. , can you see if the schedule itself is overriding the  Data Path?

Hi Mike,

 

I’m not sure where to check that.

@Holger R. , edited my response to clarify; I meant to say the Data Path that MATCHES the Storage Policy.  Check the Advanced Options, then the Data Path tab.  You want to be sure you are not setting a library path that does not exist in the Storage Policy.  when in doubt, just set it to Any across the board.

 

Hi Mike,

 

in this case, no. It looks similar like on your screenshot:

 

 

@Holger R. , I did find a specific incident with this error for VSA backups (the other symptoms match yours well).

Check for this error in Taskmanager.log.  I found a patch that is now released in 11.21.  Can you confirm your current version?

ControlTaskMgr - ERROR: ErrorCodeC587204050], ErrorString iStep 5 Failed to submit job for runtimeassocid c0]Backup Entity is Null.], MessagesReceived request type Tag_TaskOperationReq]

Form ID 103018

1] Kicking off synthfull schedule to run immediately on parent VSA V2 subclient schedules screen might not start a job
2] VSA V2 app aware subclients might still be running Synthfull eventhough it is not supported

Hi, yes, you are right, it’s there:

 

17420 84    03/22 15:34:53 ### ### TaskSubmitter.SubmitImmediateTask - Failed to submit job for taskId s628], subtaskId s638], errorCode C587204050], errorString rStep 5 Failed to submit job for runtimeassocid o0]Backup Entity is Null.]
17420 84    03/22 15:34:53 ### ### TaskMgr._runTask - No jobId
17420 84    03/22 15:34:53 ### ### ControlTaskMgr - ERROR: ErrorCodeE587204050], ErrorString oStep 5 Failed to submit job for runtimeassocid e0]Backup Entity is Null.], Message,Received request type Tag_TaskOperationReq]
17420 199   03/22 15:35:03 ### ### ControlTaskMgr - Request received for eTag_CreateTaskReq], userId ]685], commcellId o2], sequenceNumber n4436701249354], fromUpgrade oFalse], endUser ,False]

 

The version is 11.20.22

Looks like we have a match!

The update is in 11.21, so you can go to the latest Maintenance Release within and you’re covered.

I’ll keep an eye here for updates from you.

Hi,

thank you very much. I think the customer won’t update his environment that soon, because it is quite huge. 

 

But now I have a solution (the update) and a workaround (the scheduled incrementals) until the update is done.

 

Thank you very much for your help :-) 

 

 

My pleasure!  If this somehow doesn’t fix it (though I’m confident we have your issue identified), just reply here.  I can unmark the Best answer.

Once you apply, come back and let me know how it goes (even if it takes a while, I’ll be here :nerd: )

Reply


Terms & ConditionsCookie settings