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?
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.
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!
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.......
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...
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.
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).
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?
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 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.
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"
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.
"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.
Would you like to reply?
Login or Register to post your comment.