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.

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

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

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.

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.......

"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.

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!

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).

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.......

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!

Yup, I've got the same problem in 12.5 and so have a lot of other people judging by the number of individual threads that have been opened on the subject. And it'll happen again in six months time when the clocks go back once more...

Surely after a problem has affected over five versions of the same software, you'd think someone at Symantec would be able to come up with a fix (or even a workaround) so that we don't all come in the next morning to a screen full of "Missed" backups?

 I'm curious how many of the people here have done upgrades through their versions (10->11->12->12.5)?

I'm wondering if anyone who has done a fresh install (ex.: fresh installed 11d and stayed at 11d) is not having the problem.

I like how this Symantec article says there's no known issues with DST in versions 12.0 and 12.5 ;-)
http://seer.entsupport.symantec.com/docs/301124.htm

Restarting all Backup Exec services worked for me, but only on jobs that went into Missed status.

I found an article once for a previous version of BE that had a cure for the time change issue. Too bad the "patch" didn't carry through to BE 12.5.

Why not run your Backup server in a GMT only time zone, like CUT?

I'm running v12.5, all the latest patches.  And once again, like clockwork, BackupExec is unable to handle Daylight Savings.  I fully expect a number of Symantec support folks to reply that this problem has been fixed long ago - just like every other time we're seen this.

For those new to this issue- when the clock changes at 2:00am, all queued jobs immediately fail as "missed".  The start and end times are exactly the same.  Sometimes the next scheduled run is OK, sometimes not.

Here's a small sample of that I saw when I came into work this morning:

Well, I guess I'm not the only one. Helpfully BE (12.5) doesn't tell me about missed jobs either. As last year I expect I will have to delete and recreate every job since I have tape duplicate jobs attached that are still waiting to run. Each version change the interface gets slower and more bloated with "features" but the most basic problems continue ... FIX THIS

Hi,
If you have already tried restarting the service 

can you provide the error code which helps a bit more . if possible copy paste the error code and the discription from the Job log.

Thanks
Jay

Hi,

I use Symantec Backup Exec 11D. The support solution I got from Symantec was pathetic - put job on hold, run now, modify job, put back the real schedule

This solution is time consuming and a total. You would think this issue would be fixed by now.

However, I tried stopping and restarting all Backup Exec services and now my backups are running as scheduled.

I wonder if Symantec is aware or even cares of their customer dissatisfaction.

Thanks,

Mark
 

I wonder if Symantec is aware or even cares of their customer dissatisfaction.

They have to be at least aware.  This forum erupts into flame twice a year, and has since v9 (v8?) That is almost 10 year now

As to caring, that's a whole 'nother can of worms

The first night after the DST shift was like most in the post.  The first time a job runs after the time change it gets missed, all subsequent jobs work normally. 
As a work around, we started and immediately canceled every job which had not run for the first time after the time shift and did not get the error where it was missed.  This has worked with version 11D, 12, and now 12.5.