Backup files for source job were changed, retry is required?

[mfinnigan_g]

I'm on V9 U1. Our primary jobs are configured to go to exagrid, incremental, weekly synthetic fulls. My tape job is configured to only backup last full, no incrementals, and it starts after we've performed our weekly incrementals. It takes a few days, and I do notice this message in the actions of the tape job.

5/3/2016 11:46:02 PM :: Backup files for source job CMSINDEX1-EXAGRID were changed, retry is required...

I'm pretty certain our synthetic full didn't change since this tape job started. Is there a reasonable explanation for this message (like perhaps user error or misunderstanding ) or should I open a support ticket?

[Dima P.]

Matt,

Hard to say why you got this message without the debug logs, so I’d recommend to discuss it with our support team.

[mfinnigan_g]

Support says this is a bug, fix slated for 9.5, I've asked them to prioritize fixing the defect if possible.

[Dima P.]

Matt,

Thanks for the heads up. I’ll reach QA team to make sure that the fix is included in the upcoming version. Will follow up once I hear back anything.

[mfinnigan_g]

Thanks!

[Dima P.]

P.S. Can you please post the case ID, so I can refer to your case? Thanks in advance.

[mfinnigan_g]

Certainly - case 01790863

[mfinnigan_g]

Just checking - any update on this feature?

[mfinnigan_g]

Checking in again - any update on this bugfix?

[einhirn]

I don't know if it's the same as mine, but do you have VM Templates in the primary job? Support disabled "exclude templates from incremental run" as a workaround here, now it's better.
post196418.html?hilit=retry#p196418 Case 01815809

[mfinnigan_g]

We don't have templates in our jobs, no.

[veremin]

What support engineer said once the logs had been investigated? Thanks.

[mfinnigan_g]

I explained that the tech said it was a known defect, slated for fix in 9.5. Case 01790863. I asked if this could be expedited, since it's a bug that impacts our data protection, and was told to ask for that here. Which I did, in May, and have not heard back from Veeam . Do you have an update?

[Dima P.]

Hi mfinnigan_g,

Next update should bring an option to set ‘If some linked backup jobs are still running, wait for up to …’ timer in hours. That should solve the issue when your source backup jobs are overlapping the tape schedule.

[mfinnigan_g]

Dima - that just improves the effectiveness of the workaround?

[mfinnigan_g]

Dima - any response? Any timetable for that next update?

[veremin]

The Update 2 is already in pilot stage (it's being distributed only within support tickets at the moment).

However, the enhancement Dmitry was talking about is scheduled to see the light in version 9.5 coming later this year.

Thanks.

[mfinnigan_g]

OK - back in May, Dima said he would see if the U2 could include this fix, per my request. Oh well. I"m disappointed that this bugfix isn't being fixed in U2. Why is Veeam calling it an "enhancement"? The behavior I'm seeing is a defect.

[Dima P.]

Hi Matt,

Option to set 'wait for backup jobs' in hours will be introduced in Update 2 as I promised. Ability to control and modify the tape job's behavior in case its interrupted by running source job will become available in v9.5.

[mfinnigan_g]

Dima - I think we might be misunderstanding each other. What's happening to me should not be triggered. My tape job is configured to only backup last full, no incrementals, and it starts after we've performed our weekly synthetic fulls. Subsequent nightly incrementals to our Exagrid should *not* affect the tape job, because the incrementals aren't changing the recent synthetic full. Mike Popovski, in case 01790863, stated "what you're running into is a known bug that is planned to be fixed when version 9,5" - so my request was to expedite the bugfix. If that's not happening, then oh well.

But, you reference to this as an enhancement, and referrring to configurable featues, makes me worry we're not talking about the same thing. Please let me know.

[Dima P.]

Hi Matt,

Sorry for confusion. Support guys and I were talking about exactly same thing – ability to set the highest priority to tape jobs and avoid interruption by source jobs. Unfortunately, it was impossible to push it into next update due the complicity of required code improvements, so we will introduce this functionality in v9.5.

[mfinnigan_g]

OK, thanks.