Scheduled Jobs Don't Run

[tsightler]

OK, I must be doing something wrong. I have Veeam 3.1 installed and am using VCB SAN mode which seems to be working great, and can manually run jobs without issues and performance is OK, although not great. However, my scheduled jobs never run. They show the "next scheduled time" but then that time comes and goes without anything happening. Does the Veeam application have to be up and running for scheduled jobs to actually take place? That certainly doesn't appear to be the case based on the fact that there is a service which appears to handle this function. What else could I be doing wrong? Any logs I should look at?

Thanks,
Tom

[Gostev]

Hi Tom, please send all logs from Help | Support information to support@veeam.com, as well as screenshot of the job's schedule, and we will be able to tell from this the reason why your jobs are not starting. No, the Veeam Backup console does not need to be open. Thank you.

[Gostev]

By the way, what you are comparing to when saying that "performance is not great"?
How much are you getting, and how much would you expect to get?

Performance really depends, on storage infrastructure as well as target storage, you can check out couple of stickied "How To" topics for more information, unless you did that already.

[tsightler]

I didn't mean to imply that performance was not great was somehow caused by Veeam. Our backup server is and older piece of hardware, a Dell 2650, and we're backing up from Dell Equallogic iSCSI storage. We see about 25-30MB/s, which is about the same as what we get from our current product (vRanger). The only real difference is that vRanger allows us to choose how many jobs we want to run in parallel. With vRanger each job gives us roughly 20-30MB/s so by running 4 jobs simultaneously we can get 80-120MB/s.

When backing up 18 VM's we can get the task done in about 90 minutes with vRanger, but the same task is taking almost 5 hours with Veeam, mostly because of the jobs running sequentially. We could probably choose to run multiple Veeam backups in parallel but that seems to go against your recommendations and we think that would also negatively impact the dedupe since dedupe seems to happen only within a single backup file (correct?).

I'm hoping to get the opportunity to do some testing with some hardware that has a little more horsepower because it appears the Veeam is much more CPU intensive than vRanger, probably due to the dedupe overhead. Still, Veeam is an excellent product, between dedupe, and the synthetic backup approach the potential for disk savings within our backup solution is tremendous. Add to that the ability to quickly restore files from Windows and Linux and it's almost too goo to be true. The performance issue compared to our current solution is the only thing we've even found to put in the "con" column, and we think we can work with that.

Thanks,
Tom

[Gostev]

Correct, the dedupe is within a single backup file. Keep in mind though that dedupe gives most noticeable results when backing up VMs made from the same template. So you will not get too many benefits by just putting all your VMs in the same job (unless they are all from the same template). You would also get huge backup file that is harder to manage, copy around, etc.

So try organizing your jobs based on VM origin, and running them in parallel. Reliability will not be worse than with vRanger since all issues with parallel processing I was talking about happen on storage level anyway, and are not related to specific product. But Veeam Backup also has retries, both on job level, and within backup engine (for most low level operations, these type of retries are unnoticeable for the end user).

Also, after you upgrade your hardware to more powerful, try using Best compression. While Best complression will make backups really slow when running Veeam Backup on weak servers or within VM, it could really speed up backup speed in case of powerful multi-processor Backup server, while signigificantly reducing the backup size. Veeam Backup 3.0 engine multi-threads very well, and takes full advantage of multi-processor machines.

[tsightler]

I think we understand. The difference between vRanger and Veeam regarding backup scheduling is pretty significant. We decided to try simply grouping "similar" systems together. Most of our system have a production and development environments with the two systems being virtually identical, in many cases cloned from each other, except for minor changes being developed. These systems dedupe exceptionally well and can easily be grouped together so our current plan is to make jobs for each groups of "similar" systems and pick reasonable scheduled where not too many jobs will run simultaneously. We suspect this will get us similar results to vRanger, but with far more space efficiency of the backups.

Grouping Linux systems also seems to provide excellent dedupe and result is very good compression.

We have one system which is some concern. This system currently has a 1TB volume and a 500GB volume. Does Veeam cope with volumes of this size? Can we run a parallel backup of the two volumes on the VM at the same time?

[Gostev]

The virtual disk sizes no longer matter (we had 2GB limit for source data size in previous version, but this is no longer the case). However, unfortunately all disks for the same VM are processed sequentually. What you can do however, is to create to separate jobs for this VM, and backup 1st disk with one job, and 2nd disk with another job (use disk exclusion functionality to exclude the other one). Don't know if this is acceptable workaround for you or not.

[tsightler]

That's pretty much what I meant, schedule two jobs, one to backup each disk, but run this simultaneously. I wasn't sure if Veeam/VCB supported simultaneous backups on two different disks of the same virtual machine.

[Gostev]

Tom, now when you said that I realized I totally messed up with my previous suggestion. This will probably not work because of snapshot requirement for hot backup, and snapshot is done on VM level (for all disk at once), not on disk level. Separate parallel jobs will attempt to create separate snapshots, not even sure what will happen next in this scenario. Sorry about that...

You would probably need to dedicate separate job to this VM still, full backup of 1.5 TB should complete in under 8 hours with VCB SAN mode, incremental backup will be even faster than that (especially after (if) you upgrade to vSphere).

[tsightler]

OK, well back to the original problem, I've forwarded my logs. I've also installed Veeam backup 64-bit on a completely different machine and have the exact same problem, scheduled jobs just don't run. Obviously people are running jobs so it must be something unique to my circumstance but I can't for the life of me figure out what would be unique in my environment. Still, the installs were on completely different hardware, one a 64-bit WIndows 2003 virtual machine, and the other a Windows 2003 32-bit on a Dell 2650. Both work perfectly well for manually scheduled jobs, but simply don't run any scheduled jobs.

If I watch the "Jobs" screen through the GUI it shows the "Next Run Time" correctly, I can watch the system as it passes that time and absolutely nothing happens. If I refresh the "Jobs" screen the "Next Run Time" will have changed to 24 hours later. Seems straigtforward but just doesn't work. Hopefully support will get back to me with something to try.

[mixja]

I have the same issue - scheduled jobs do not run. You can manually run a job, but scheduled jobs don't ever kick in...

[tsightler]

I emailed support and they suggested checking the account that the Veeam servive was running under. It didn't make much sense to me, I'm using the same account to login to the machine and it has "Logon as a service" privilege, but sure enough, when we created another user and changed the Veeam service to use this new account, the service stated up and worked fine and jobs are running as scheduled now. I have no idea why the other account does not work, it's an administrator account with full access.

Don't know if yours is the same but it's worth a try.

[schaffeb]

I am currently having the same issue. I will try using another account. I find this to be quite odd. I am using the local administrator account which has "log on as a service" enabled.

Would it be a good idea to try running the Veeam service as "system"?

[Gostev]

I think this should work. But I would love if support could do a webex with you, and invite our devs to take a look at the issue in live, so that we could get to the bottom of this, and find the exact account setting that prevents scheduled jobs from running.

[ssimakov]

Ben, are there any errors registered in logs (found in Help->Support Information) or job session statistics in the product UI?

[mdionnh]

dito, same issue... scheduled backups don't run on schedule but will run if manually started. The schedule time updates to 24hrs later but no backup is run.

[schaffeb]

So I checked the Support Information log for a job I believe I had scheduled and there doesn't appear to even be an entry regarding the missed scheduled job. I'll try to verify this a little bit later.

Should I open a support ticket for this? Unfortunately I have a few jobs which will be running all day so I don't think I can change the Veeam user account until tomorrow.

edit:

I can confirm that the log file for my test scheduled job did not contain any errors relating to the missed scheduled job

[Gostev]

Sure, please open the support case. We recommend to always open the support case in case of any issues because forums are not constantly monitored.

[schaffeb]

I have resolved this issue. I simply changed the Veeam service to run as the system account instead of local administrator and everything works great.

[Gostev]

OK, thanks very much for updating the topic with resolution Ben!