VMware Cloud Community
Grime121
Contributor
Contributor
Jump to solution

VDP Cannot Set Start Time on Backup Jobs

Is there some restriction to the time you can set a backup job to start, even within the backup window? I have two jobs on one VDP. The daily job I set for 5PM (maint. window is 6AM-5PM), and I am trying to set the other (a weekly job) to 6PM, but every time I do that it changes the time on it back to 10PM! VERY frustrating... I had the same problem when trying to set the job for 5PM (the time I REALLY would prefer), but I figured that wasn't working because it just didn't like both jobs being set to the same time.

Also, why is there not a way to set a job to be performed on certain days of the week? For instance, I do not want my daily job to run on Saturdays, but with VDP it's all or nothing with the daily, weekly, and monthly options. The reason I need it to not perform the daily backup job on Saturdays is because I have to back up an SQL DB VM on Saturday, and for some reason backing up SQL VMs seems to take a MUCH longer time than normal ones, especially if other backups are running at the same time.

Which leads me to ANOTHER problem.... My backups simply are not completing in time. It seems to usually only be the SQL ones that run MUCH slower as I mentioned, but occasionally that causes one of the other backups to not complete either. Are you telling me that if a backup cannot be completed within the backup window then it cannot be completed at all?? That's ludicrous. The backup system just simply isn't available during the maintenance window? That effectively makes it useless 50% of the day (if maint. windows set to 12 hours, which it seems like it needs to be in order to complete it's tasks).

0 Kudos
1 Solution

Accepted Solutions
cdomanski
Enthusiast
Enthusiast
Jump to solution

I think this is a bug. I had the same problem today with a 10PM scheduled time, and it was driving me crazy.


What I did first was clone the 10PM job to a new job with the new time and it stayed fine at 5PM. So that is workaround #1. For another job with the same problem, I just edited the job, followed the wizard through the steps, then changed the time to 5PM, and chose a NEW name for the job, then the 5PM also stayed.

Definitely a bug somewhere.

View solution in original post

0 Kudos
8 Replies
RyanJMN
Enthusiast
Enthusiast
Jump to solution

What VDP version are you using?

First off it looks like the main issue is performance related.  Have you run a performance test on the data store?  If so did it pass?  See KB about VDP performance requirements.  If your backups run fast enough than you can probably simplify everything into one job that runs every day.  You might be running into a limitation of duplication in general.  Is the SQL VM creating .bak files that are compressed?  Data that is already compressed doesn't deduplicate well.  Data Domain storage is a lot faster than VDP storage for SQL and high change rate VMs although they are not cheap.

I have not run into the time switching on jobs.  I've had no issues having 2 jobs start at the same time.  Also I don't believe I've added a client into more than 1 group.  I know that a client can't have 2 backups run at the same time so possibly your issue is related to that.

I haven't tested but I'm pretty sure VDP can run backups during maintenance although with limited performance.  I believe jobs will run for 24 hours before they automatically get canceled.

0 Kudos
Grime121
Contributor
Contributor
Jump to solution

While I have figured out some things to improve performance I am still having issues scheduling the backup jobs. Well, at least on one of our VDPs... It is set to 10PM, and if I change it to 6PM it just changes it back. It was previously set to 5 or 6AM, but we moved our backup Window to 6PM-6AM. Please see attached screenshots.

I SUPPOSE it could have to do with having the same VM in both backup jobs.... I removed a server from the 4xWeekly one, and put it in the 7xDaily-2xWeekly one instead. I just deleted all of the previous backups of the VM to see if that helped, but it did not. I also just kicked off the 7xDaily-2xWeekly job so that it will reconfigure the VM if that is what needs to happen. If this is the case it is kind of strange that it automatically increases the scheduled time by 4 hours without even saying anything about why....

Thanks,

-Evan

0 Kudos
cdomanski
Enthusiast
Enthusiast
Jump to solution

I think this is a bug. I had the same problem today with a 10PM scheduled time, and it was driving me crazy.


What I did first was clone the 10PM job to a new job with the new time and it stayed fine at 5PM. So that is workaround #1. For another job with the same problem, I just edited the job, followed the wizard through the steps, then changed the time to 5PM, and chose a NEW name for the job, then the 5PM also stayed.

Definitely a bug somewhere.

0 Kudos
Grime121
Contributor
Contributor
Jump to solution

Unfortunately renaming the job did not fix the time for me. I ended up cloning the other job, and changing the VM selections, schedule, and job name. What's funny is even though the cloned job starts at 6PM it STILL initially had 10PM in the start time field. However, I changed it to 6PM during the initial job creation, and it stuck.

I'm surprised more people aren't running into this....

Thanks,

-Evan

0 Kudos
cdomanski
Enthusiast
Enthusiast
Jump to solution

Very strange indeed... I'm glad you got your start times to stick.

0 Kudos
Grime121
Contributor
Contributor
Jump to solution

Well, I take it back... The new time did NOT stick. I just went in to make a change, and noticed it is once again showing as 10PM. Any ideas? Screenshot attached.

0 Kudos
cdomanski
Enthusiast
Enthusiast
Jump to solution

The only other thing I did in my situation was modify my maintenance window from 5pm to 7am from the default. Not sure if that had anything to do with the affect on job start time?

Good luck!

0 Kudos
Grime121
Contributor
Contributor
Jump to solution

I Modified that earlier without any change. I was told that some fixes to the scheduling are included in the new 6.0.1 update. I am installing that now. Hopefully they finally fixed an issue that I actually have, instead of only ones that I've never heard of or experienced before....

0 Kudos