Task was not processed in the current session

[vky]

Case #05037055

I did not receive a timely reply with severity 2.

The "Talk to a manager" page is in an endless loading loop. Tried from multiple browsers and on my phone over cellular data to rule out a network issue.

This is a copy job. What the last messages on the statistics:
9/22/2021 10:58:16 PM :: Source backup file has different block size. Expected block size: 1024, actual: ([backup name: LEX-FS1, block size: 256])
9/22/2021 10:58:16 PM :: Task was not processed in the current session
9/22/2021 10:58:16 PM :: Network traffic verification detected no corrupted blocks
9/22/2021 10:58:16 PM :: Processing finished with errors at 9/22/2021 10:58:16 PM

A recent change I made, approximately a week ago, was to turn off synthetic full backups and turn on active full. The copy job seemed to start failing after the active full took place. I read several forum posts giving that recommendation when synthetic fulls were slow but in this case the active full seemed to be even slower. I'd be happy to dive into the performance issues there if anyone would like to assist but in this case I specifically need to get the copy job working again to get our off-site backups up to date.

[foggy]

Any chance you've also changed the storage optimization settings on some of the source jobs? Looks like you are mixing source backup jobs with different block size in a single backup copy job, which is not allowed.

[vky]

It's a single source job for 1 VM. I did in fact change the optimization from local to WAN target but that was several weeks ago and it had been working well until now.

[foggy]

Storage optimization settings change requires active full to take effect - so seems it just didn't happen before now. You need an active full on the backup copy job as well to start a new chain as it cannot put blocks of a different size into the existing chain.

[vky]

I see. I started the active full on the copy job. I am curious why this is necessary for a copy job though? Why is it not simply copying the backup file that was created by the backup job?

[PetrM]

Hello,

The periodic backup copy does not simply copy source backup files but transfers the actual state of data to a secondary location in order to create restore point. This actual state of data is represented by the array of blocks retrieved from source backup files. These blocks must have identical size within a single chain of produced backups, otherwise synthetic operations will not be possible: for example there is no way to inject incremental point consisting of 256 Kb blocks to the full point having 1 Mb blocks to respect the short-term retention settings. By the way, a similar issue is described in this KB.

Thanks!

[vky]

Ok, doesn't look like I can re-open the case but I'm a bit confused about what is happening with this job now. The Active Full ran for nearly a week but was interrupted by a server restart. We got a failed notification and all that. When I checked on it last night it was doing a backup files health check which took until this morning. It completed that and then proceeded to run the job and start creating a VIB. That did not fail as it had been doing and why I opened the case for this in the first place. When I look at it under Disk (Copy), there's a VBK listed saying 0 B size. Looking directly at the share that the VBK is stored on there's a 3.6 TB VBK for that restore point. Obviously incomplete. So I guess several questions. Why is it not getting caught up on the block size now? What's the deal with the orphaned VBK? Can the incomplete VBK be used to finish the Active Full?

If I need to open a new case and upload logs again please let me know and I'll be happy to do that.

Thank you

[PetrM]

Hello,

Yes, I believe it's worth opening a support request. It's quite difficult to understand what's going on without having a look at your environment and analysis of debug logs. Please share a support case ID with us.

Thanks!