Time Change

[ESabo]

Once Again, the time change has screwed up every single job.     Why can't Symantec fix this problem?  So this morning we will have to adjust all jobs.

[rams7519]

My jobs that were normally set to start at 1AM were somehow changed to 12AM, is this the same thing you are referring to? I'm new at this.

[Nikki_Davis]

I'm hopeing that mine is the same issue.

All my jobs after 2:00 am failed.

I have a job that is scheduled to run at 8:00 am.

The server time is 8:00 am.

The job failed saying that it missed the time window.

In the job history it says:
Original start time : Monday, March 10, 2008 9:00:00 AM
Job started         : Monday, March 10, 2008 8:00:03 AM

The Job Monitor says:

      Job Name                 Start Time                   End Time                 Elapsed Time 
Full - Tbackup2k     3/10/2008 8:00 AM       3/10/2008 10:00 AM          0:00:00 0

It is only 8:40!!!!!

Can anyone help me with this?

[T_C_2]

I noticed the same thing happening to my schedules here in HQ.  Does anyone know if systems not affected by Daylight savings time are affected?  Also, as it seems like this is a known issue is Symmantec working to resolve the problem?

[Ken_Putnam]

They may be working on it, but it has been a known "gotcha" since v8.0  at least

[MitchR]

Same problem here. I've got a screen full of red in the job history.  All jobs that hadn't started by 2am reported as "missed".

[ESabo]

Spend most of the day rescheduling jobs to run again tonight.    This is just a big pain and had been a known issue since version 8.x.     I guess Symantec isn't or cannot fix this problem for us.

I just changed the date to today's date so the jobs would once again run.

[jmark]

Thank you for reporting this.  I thought it was just my system.  I have not been happy with BE 11D since I've owned it.  Everytime something changes in the enviroment (such as DST) BE fails.  This software is the worst I've ever worked with....  If you have a chance to replace BE go with CommVault.  I had my chance and I went cheap.  Never again! 

[dbaish]

Well, I'm glad I'm not the only one that is having this issue.  All of my scheduled jobs last night were missed.  The only conclusion that I could come to was that it had something to do with DST.  I figured I'd come on the boards here to see if anyone else was having problems.  Does anyone know if Symantec is patching this or what?  I have all of the latest updates for 11d.

I don't know if the one guy on here was right when he said that this has been a problem since version 8.0, but if that's the case, that's definitely unacceptable.

So I guess the resolution is to go in and recreate all of the jobs?  Or can I just go in and change the time to something obscure and then change it back to it's original time?  Thanks for all the help guys.

[Imsoaks]

I'm also wondering the same thing?  I changed the Effective date on a weekly Friday backup and now it says it will run on March 21st.  It should say March 14 and I've tried everything to get it to start on that date to no avail.......

Anyone have any ideas???


Message Edited by Imsoaks on 03-11-2008 11:10 AM

[dbaish]

I'm on the phone with tech support right now.  I will let you guys know what I find out.

[MitchR]

---

dbaish wrote:
So I guess the resolution is to go in and recreate all of the jobs?  Or can I just go in and change the time to something obscure and then change it back to it's original time?  Thanks for all the help guys.

---

For most jobs, you don't have to do anything. It will run again the next time it's scheduled. 

If one of the "missed" jobs was a special job (monthly, special on-time job, etc.), you'll need to manually re-run that job.  Normal daily jobs should be fine the next day without doing anything.

Of course, until Symantec provides a fix, things will run normal until the next Daylight Savings change. Then it's another screen full of missed jobs...

[T_C_2]

Is Symmantec going to comment on this issue ?????????????????????????????????

[MitchR]

---

Imsoaks wrote:
I'm also wondering the same thing?  I changed the Effective date on a weekly Friday backup and now it says it will run on March 21st.  It should say March 14 and I've tried everything to get it to start on that date to no avail.......

---

If you've checked the schedule and verified that it looks OK, it could be that you've got corrupt schedules for that job.  (That seems to happen a lot with v11....)  Delete the job, and re-create it from scratch.  You should be OK re-using the existing selection list though.

It wouldn't hurt to try running "BEUtil" to check your BackupExec database while you're at it.

http://seer.entsupport.symantec.com/docs/265180.htm

[Jack_Dorsey]

"Is Symmantec going to comment on this issue ?"

Don't count on it.  It's a "known issue" that has been prevalent for nearly a decade.  What would be the point on Symantec commenting?

What would be nice if they would tell all of you new users what to expect upon purchasing this product so that you're not left in the dark freaking out when DST happens.  Of course, the current US government making changes to DST this year didn't make it any easier on Symantec, either.

It's a known issue, peeps.  Your backups will run fine tonight.

[Francisco]

YES, it is that time of the season...

Just hang up on the phone with Symantec. The solution is to change the time in every single profile job you have.

But, don't worry, the tech told me that he will escalate the ticket...

This is an embarrassment for Symantec.. since version 8.

Just create a script that registers the time of each job, adds a second to them, run them once on schedule and turn them back. We won't notice.

[dbaish]

Just got off the phone with Symantec.  Apparently this is a known issue, and they're looking into a hotfix.  The ETA on that hotfix is unknown.

Symantec's workaround is to go in the next day and modify the schedule.  Set the job to "Run Now" and "Submit Job on Hold."  Submit the job.  Then, modify the schedule again and set it back to the original date and time.  The job should then run normally.

Of course this doesn't actually help the jobs that were missed.  I would assume that you could modify the jobs right after DST hits, and that would make the jobs run fine.  Not sure though??

I agree with Jack Dorsey on this one.  I'm okay with Symantec not having a resolution on this issue (as long as they're actively researching it), but I feel that Symantec, at the very least, should notify their customers of this issue.  A simple email notification would be fine.  Not making their customers aware of such a troublesome bug is simply not acceptable.  Very disappointed with Symantec on this one!

[cmc]

I don't understand why this is a problem.  It should be an easy fix.  To me, it looks like Backup Exec is scheduling jobs according to GMT, not local time.  For example, my first backup job is scheduled to run at 10:30pm local time (Eastern US).  The job was "missed" last night, and BE says:

Original start time : Monday, March 10, 2008 11:30:00 PM
Job started         : Monday, March 10, 2008 10:30:01 PM

When I created that job, daylight savings was not active, so it was scheduled to run at 10:30pm EST (GMT-5) = 3:30am GMT.  Now daylight savings *IS* active, so now it's 10:30pm DST (GMT-4) = 2:30am GMT.  BE says the job's original start time is 11:30pm (11:30pm DST = 3:30am GMT).  So even though the job started at the correct time (10:30pm DST, 2:30am GMT), BE thinks it should not be started until 11:30pm (3:30am GMT).

So it looks like the whole problem is that Backup Exec's scheduler component is scheduling jobs according to GMT, not according to your local time.  As such, when your GMT offset changes, the scheduler thinks they're not running at the correct time (even though they are).

[Imsoaks]

ok, I'll try that. 

I did run the Repair last month when I kept getting "the backup exec service has stopped.....".  It hasnt come back, yet.  Knock on wood.......

[DR0701]

Has anyone else still got this problem with 12.5?  Our backups all came up as missed when the time change came in just the other week - luckily, I noticed and was able to kick them off manually, but it's still a right royal pain in the proverbial!