Trying to understand tape job and virtual full

[sasilik]

We have Veeam 9.5 u4 and tape job which has backup jobs as source. VM Backup jobs are forever incremental, tape media pool has virtual full schedule Monday, tape job runs on Tuesday. I looked at the job status on Friday and the job status was Idle. Two backup jobs in list had status pending. When I looked at them then I saw that both of them had already written their full backup file on the tapes. There was "synthetic full backup from... will be placed into the media set", "Source backup files detected. VBK map: 1", then tape loaded into drive, data written, tape full, new tape, etc until "Processing finished at ...". The task for writing file to tape started on Thursday morning about 6:30 and finished on Friday morning about 8:10. And then on Friday evening about 21:45 Veeam started processing backup jobs again and for these two jobs there were messages
"Task is in retry required state. So full run is not required"
"Task ... requires retry or has no fulls or all fulls backed up to Simple mediaset"
"Task ... retry required by the following reason: Backup file has not been created by backup job yet, retry is required"
"Backup file has not been created by backup job yet, retry is required"

There was also third job for what same messages were written but it was not in Pending status but it had green check mark and status Success. But when I clicked on job name and looked at details then there was last message with green arrow like Pending status which said "Backup file has not been created by backup job yet, retry is required"
Difference was that at same time first two jobs were running, health check and compacting, but third one did not do anything. And as these processes took their time then after 3 hours it timed out,"Error: Timed out waiting for running source jobs to complete (180 min)", and entire job was marked failed with error even when the full backup files for these jobs were written on the tape. At the end these two jobs were marked as failed and third one as Succeeded even when it had same messages for it inside log file.
I quite don't understand why there is need to retry backup job inside the tape job when it already has written one full backup on the tape. Or how should I arrange my backup jobs, only one VM backub job per tape job? So that tape job would not start retrying other backup jobs inside tape job which have already been written on the tape?

[soncscy]

Hi Marrko,

I saw this with a bunch of client sites, and as I get it, it works like this; the tape job will requeue the source jobs to check for new points if it detects a change in any of the source jobs added to the tape job. So if you have 10 jobs added, and one of the source jobs run, then all of the jobs will requeue after their first backup to tape to see if new points are made.

I think, from what we tested internally, this has changed in the newest version as I don't see the jobs that wrote to tape getting requeued, so you might just want to consider upgrading.

[sasilik]

Thank you for your explanation. It seems plausible and my thoughts moved kind of in similar direction. But it is kind of annoying, specially if you get back failed tape job even when it really didn't fail. I have observed this kind of behaviour also earlier and dug couple of times a little more if there was really second set written into the tape but it did not seem so. Haven't seen failed job though yet, that was the first. I have plans to upgrade to v10 so I guess I will see how that works.