Time Change
Updated: 20 Sep 2010 | 34 comments
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.
discussion Filed Under:
Comments
Original start time : Monday, March 10, 2008 9:00:00 AM
Job started : Monday, March 10, 2008 8:00:03 AM
Full - Tbackup2k 3/10/2008 8:00 AM 3/10/2008 10:00 AM 0:00:00 0
If this response answers your concern, please mark it as a "solution"
Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
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.
Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
"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.......
Still not fixed in 12.5
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
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
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.
On my fully patched builds of
On my fully patched builds of 11D 7170 fresh install the issue happened last year. I did do an upgrade to 12.5 from 11d 7170 and had the issue as well.
The server I had the problem
The server I had the problem on last month was brand new and had a fresh install of v12.5 on it. But the previous times I've experienced the time change problems was on my old server, which was upgraded from v8.5 through most intermediate versions up to 11d. So I don't think that is the cause of the problem.
running 11d rev 7170
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.
Was fixed then broke again
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
Why not run your Backup server in a GMT only time zone, like CUT?
Lots of little problems
If you did that, the backup server would have the wrong time for half of the year - when all other servers/workstations observe daylight savings. You also run into problems of the time a job was run. Does the backup job's start time reflect DST or not? You'll also have to watch the files you select for backup or restore - since you're in a different time zone, the server may show files with a different time than the clients see them.
We have many issues along a simmilar vein (not BackupExec, something else), caused by business partners that don't observe DST. Trust me - the cure is worse than the disease.
Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
Another year. Another screen full of failed jobs.
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:

Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
Well, I guess I'm not the
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, MitchR whats the error code in the job logs
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
Thanks
Jay
Error Code
Here's my error code information. I'm happy to provide anything else you need!
This year, all jobs that were queued, and even ones that were scheduled to happen after the DST switch all showed this error. I think it was at 2:00am/3:00am that these all happened, but I'm guessing from the details I can see from then I came in the next day. The next day everything ran fine (i.e. nothing got corrupted in the schedule this year)
Job name : SERVERNAME
Job type : Backup
Job status : Missed
Job log :
Server name :
Selection list name : SERVERNAME
Device name :
Target name :
Media set name :
Error category :
Error : e000e020 - The job was scheduled to run, but the availability window closed before the job could start. There may not have been any destination devices available during the window, or the job may have been submitted to run when the window was closed.
Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
Hi, I use Symantec Backup
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
RE: I wonder
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
If this response answers your concern, please mark it as a "solution"
DST - what worked in our environment
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.
Would you like to reply?
Login or Register to post your comment.