I have this small issue with Veeam v. 8.0.0.817
I have a chain of backup jobs (a job starts when the previus one finish) and a tape job.
All the backup jobs are linked to the tape job.
Tape job is configuerd to start at 2:30 AM and I checked "Wait for backup jobs - If some linked backup jobs are still running, wait for up to 60 minutes" on job schedule configuration.
The issue is that tape job starts at 2:30 AM even if the last backup job is still running and the .vbk of the runnig job is not backed up to tape. No errors are reported, backup to tape job status is "Success" but the size of file is 0 (this means no files of the job went to the tape).
I know I could link the tape job to the last backup job (so it should start only when all backup jobs are finished), but doing so I couldn't choose on which week days the tape job must start.
You can schedule a script starting a tape job as a post job activity for the last backup job. In the job settings you can select specific days a post job activity should be executed on. Thanks.
Hmmm, I must have missed this part. Can you tell me how many backup jobs are selected as a source for backup to tape job? Is that the specific job that doesn't get counted by the backup to tape job or the backup to tape jobs starts at 2:30 despite of how many backup jobs are running at that time? Thanks.
FYI - I appear to have the same issue. 8 backup jobs are linked to a tape backup job with the option to wait for the linked backups to complete selected. At the scheduled time the tape backup job starts and immediately begins backing up any file(s) that have already completed their backup. It does not try to backup the other files that are still being created. There is a message on those files that the server is locked by a running job, postponing processing. Once the tape backup job finishes, it does not include any of the files that were not yet complete nor does it appear to retry.
Mory wrote:FYI - I appear to have the same issue. 8 backup jobs are linked to a tape backup job with the option to wait for the linked backups to complete selected. At the scheduled time the tape backup job starts and immediately begins backing up any file(s) that have already completed their backup. It does not try to backup the other files that are still being created. There is a message on those files that the server is locked by a running job, postponing processing. Once the tape backup job finishes, it does not include any of the files that were not yet complete nor does it appear to retry.
Thanks
Ok, this is exactly what happens to me, too. Tape job starts at the scheduled time even if there are some linked backup jobs still running. But tape backup, once finished, does not include backup files of jobs that were running when tape job started. I have a tape job with 8 backup job linked.
We haven't been aware of that issue. So, anyone experiencing that problem, please, open a support ticket and provide its' number here, as QA will be interested to take a look at it.
Tape job seems to be unaware and, thus, starts to copy data as soon as the first job in chain ends. May be you can specify tape job as the last job in chain or switch its schedule to "as a new files appear" option. Thanks.
I've been informed that this is by design and the intended behavior. That very well may be the case, and if it is, then I think the documentation and the syntax of the option in the Veeam interface should be written differently (but that's just my opinion).
Reply from tech support:
Since you have several backup jobs linked to this tape job it will wait for each individual backup job to be finished. So if one finishes it will still copy over. It will not wait for every linked job to finish with that timeout.
My response:
I guess I don't understand the use of this function then. I've read through the documentation on this and don't see anything in there that would lead me to believe that to be the case. From your response, it seems like this is the intended behavior. However, based on my interpretation of the feature, it sounds like this is a bug and not by design. If it is by design, then my personal opinion is that this is documented in a manner that is not very accurate and confusing.
The Veeam interface and documentation state this:
If 'some' linked backup 'jobs' are still running, wait for up to: XXX
Please note the emphasized 'some' and 'jobs'. I read this to mean literally, that if SOME (or any?) linked job is still running when this tape backup job starts, wait for the specified time. The fact that jobs (more than one job) is specifically used along with the use of SOME as related to linked backup jobs, suggests to me at least, that this should be waiting for all the jobs to complete and not just starting when any one of them is done.
Is this something that can be run past the development team to validate?
Reply from tech support
I checked with our other engineers to validate that it is currently working as designed.
I'm open to other suggestions and can look at the as new files appear option. Ideally, I'd like to NOT start backing up to tape until all the backups are complete as to avoid the load on the Veeam servers local disk. And I wasn't really sure how that option handled the tape media sets. I recently changed my media sets to create the tape daily instead of the original create new media every backup session. I did this because of two reasons:
1. being that my understanding of the wait on linked jobs was apparently incorrect and thus when I ran the job again to get the missed files it would create another media set and not use the existing media. The 2nd run would put the files on an 'incremental' media set instead of our 'full' media set. It also didn't maximize the use of the tapes and generally required another tape than if it had put everything together.
2. another reason was some weird failures I was getting when backing up to tape. When I would run the job again to get the missed files, I would run into the same situation as above. So as long as I ran the job again in a timely manner, the single incremental tape would have all the data on it and not require another tape.
I'm open to other suggestions on how to handle this situation - yes, I could do powershell but don't really like that as an option. In a nutshell, what i was hoping to do with the wait for linked jobs option, is.. well.. wait for the backup to disk jobs to complete before starting to backup to tape. The incrementals are always complete by the time the job kicks off, but the full backups take awhile and the time it takes to backup varies quite a bit, which is why the wait for linked backup jobs seemed like a perfect option for my use case (and apparently the OP of this thread).
If 'some' linked backup 'jobs' are still running, wait for up to: XXX
The option is related to the situation when there are several backup jobs running simultaneously that are selected as a source for a backup to tape job, the backup to tape job will wait for a predefined period of time, rather than copy the files created by first finished job immediately.
In your case specifying the backup to tape job as the last job in the chain should answer your requirements.
I have the same issue and do believe there is a bug in the way Veeam handles waiting for linked jobs. Specifically, I have a backup to tape job with two linked backup to disk jobs which is configured to "Wait for backup jobs". The backup to tape job starts as soon as one of the backup to disk jobs completes and logs that it is not able to backup the other backup to disk job:
"This server is locked by a running job, postponing processing."
Postponing until when?
The associated backup job is then reported as "Successful" in spite of not having been backed up to tape.
I believe there are two sensible logics to follow:
1. The backup to tape will wait for ALL linked jobs to complete and then run unless the “wait for up to” value is reached first (in which case a failure will be reported).
2. The backup to tape will backup linked jobs as they become available up until the “wait for up to” value is reached. Any linked jobs which had not been completed before the “wait for up to” value is reached will not run and report as failures.
The current logic seems to be:
The backup to tape job waits until one (of multiple) linked backup to disk jobs completes and then backs up *only* that job whilst reporting success for all jobs.
This does not seem sensible. Certainly the Help page needs to be updated to better explain the behaviour if this is "by design".
I'm having the same problem. One of the source jobs was locked, it said postponing processing, and then reported the one that was in use as "success" yet never backed anything up and didn't retry later. the wait for linked jobs does indeed seem broken.
Hi, Steven, may I ask you to answer the question provided above? Is one of the source backup job using "after this" job schedule, meaning, source jobs are somehow linked?
In my case, i'm running it monthly on the 1'st wednesday. i'm also trying it daily. just got off the phone with support. He says it works for everyone else, he's going to look at logs.. case # if you're interested. 00823687
I could imagine that the issue might occur when multiple backup jobs are selected as a source for a backup to tape job and those jobs are running one by one, using chained schedule ("After this" job).
However, that doesn't appear to be the case in your situation. So, let's wait and see what support will find out after log review.
This is happening to me since I upgraded to Veeam 8. In Veeam 7 the 'If some linked backup jobs are still running, wait for up to:' used to actually cause the job to wait until all backup jobs have completed then start.
I can't use the option start 'After this job' as we are not running the backup to tape job every day whereas the main job is running daily.
The same issue since upgrade to v8. In v7 was like this, here an example:
Backup job named "X" starting at 8:00 pm has completed within 1h or 1,5h. At 10:00 pm followed the backup job to tape named "Y". Its source was backup job X. In the case of adding a new vm to backup job X it finished after 10:00 pm usually 'cause entire new vm had to be written to the VBK-File (by the way --> reversed incremental). Beacause of usinig the option 'If some linked backup jobs are still running, wait for up to:' with 180 Minutes set the Y job started only after X was done. In v8 the Y-Job doesn't wait and starts by the schedule at 10:00 pm. The next day Veeam B&R shows "success" but in the action pane "0 of 0 files processed" and backup job to tape has to be restarted. That's stressful....sometimes
In Veeam 7 the 'If some linked backup jobs are still running, wait for up to:' used to actually cause the job to wait until all backup jobs have completed then start.
Can I ask whether or not those jobs are linked between each other? What I mean here is whether or not some of jobs use "After this job" type of schedule?
Backup job named "X" starting at 8:00 pm has completed within 1h or 1,5h. At 10:00 pm followed the backup job to tape named "Y". Its source was backup job X. In the case of adding a new vm to backup job X it finished after 10:00 pm usually 'cause entire new vm had to be written to the VBK-File (by the way --> reversed incremental). Beacause of usinig the option 'If some linked backup jobs are still running, wait for up to:' with 180 Minutes set the Y job started only after X was done. In v8 the Y-Job doesn't wait and starts by the schedule at 10:00 pm. The next day Veeam B&R shows "success" but in the action pane "0 of 0 files processed" and backup job to tape has to be restarted. That's stressful....sometimes
Linked jobs option makes sense only when multiple jobs are selected as source for a backup to tape job, which doesn't seem to be the case in your situation. Either "as new backup file appears" or "after this job" looks like a better option.
In Veeam 7 the 'If some linked backup jobs are still running, wait for up to:' used to actually cause the job to wait until all backup jobs have completed then start.
Can I ask whether or not those jobs are linked between each other? What I mean here is whether or not some of jobs use "After this job" type of schedule?
No backup jobs are linked. The last backup job of the 4 that run at various times during the night, now takes longer to run than it used to as there are now more VMs in the job so the hour i used to allow before starting the tape job is not enough. under Veeam 7 the tape job used to just wait for that last job to complete before starting. this is no longer the case in veeam 8. (To get around the problem I have changed the start time of the tape job to half an hour later gving me about 10 mins leeway.
According to the QA team, waiting timeout doesn't currently works as expected. When a tape job gets executed, it checks whether the first source job in the list is still running, and applies waiting timeout in case of positive answer. In other words, it cares only about first job, not paying attention to other ones.
The existing behaviour is planned to be revised in the next product version.
i ran into the same problem after recently implemented veeam. it was impossible for me to interpret this option any differently than "wait until all backup jobs are done"
if the behavior of this option is by design, it' seams completely useless if there are more than one backup job as a source.
Hello Stephan,
As it was stated above we are working on a resolution and it will be provided as soon as possible. As for the timer limit it looks like a UI glitch for me, will check with the DEVs. Thank you.
One customer has a very straight forward environment, one B2D Job with rev incr + one linked Tape Job.
Does the problem v.Eremin describes also apply to this setup?
Like, the B2D job isn't really finished, tape job starts and aborts right away because the B2D is still "there" somehow?
//Edit
Also this behavior really shouldn't generate a "success" report...
