Full backups missed due to schedule bumping - any ideas?

[asckey]

Hi,

We're nearing the end of a marathon VBR evaluation period, and have come across an issue with Full Backups.

We're currently running weekly Full Backups on 7 jobs, spread over Saturday night and Sunday night. The jobs are scheduled in two parallel streams, so that in each stream, one job is given a scheduled start time, and the other jobs are scheduled to follow the previous job. One stream performs its full backups on Saturday; the other on Sunday. Both are roughly the same size.

One of the jobs isn't running as a Full Backup due to the fact that it is the last in the Saturday night stream and has been bumped from Saturday night to Sunday morning due to the time required to run the earlier full backups. Is there any way to make it run the full backup on Sunday morning anyway, other than manually changing its full backup day to Sunday instead?

The reason for not wanting to have to manually tweak jobs is this may happen to other backup jobs as the earlier ones grow in size, and we don't want to be in the situation where the first time we find out about it is on Monday morning when we discover that we have no full backups over the weekend for a job (like we did today).

[tsightler]

These are the kinds of problems you get when you chain jobs and is why I generally recommend against doing this unless you have a really strong reason. If you only want to run one job at a time why not simply limit the proxy or repository concurrency and let all the jobs start together. That way the start time would still be on Saturday, although the resources to run the job may not become available until after the clock passes midnight.

[asckey]

Thanks for that. I completely missed the obvious solution there, didn't I?

I guess the reason we chained the jobs is no longer valid (we were having problems running concurrent jobs after upgrading to 6.5), so I'll change them back to the way they were. (They were all given particular start times before as some of the jobs couldn't be run before a given time of day for operational reasons, whereas others could.)

[tsightler]

Ideally you'd run at least a couple of jobs concurrently (this is how you get the best performance), however, if you are having problems with that, or simply want to limit the load on the infrastructure, you can certainly simply limit the concurrency available within the infrastructure by limiting concurrent tasks on the proxy or the repository. This will effectively give you the same result as chaining, without the side effects of having jobs start too late and messing with your full backup policy. You still may want to slightly stagger the start time of the jobs, just so there isn't a huge burst of "startup" activity and load on your vCenter, but it should make you life easier. Good luck!!

[asckey]

Thanks. The start times were staggered in order to avoid the huge burst of startup activity, and they're now working fine (apart from the fact that a couple of them overran their operational windows over the weekend, but that's just fine-tuning).