Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Fix how BackupExec handles Daylight Saving Time

Created: 12 Mar 2012 • Updated: 14 Mar 2012 | 15 comments
MitchR's picture
7 Agree
0 Disagree
+7 7 Votes
Login to vote

Every time Daylight Saving Time (DST) rolls around, all queued Backup Exec jobs suddenly report "missed". Every year Symantec comes out and says either "we already fixed this", or "the next release will fix this".

I'm on the latest BE 2010 SP3, latest patches.  I've been having this problem since at least v9.
(I don't know if this affects 2012)

Come on guys, fix this already.

Comments 15 CommentsJump to latest comment

Steve Kratz's picture

I'll second this one... Twice a year you can count on everything failing unless you restart services manually (and I'm having a hell of a time with services stalling on 2010r3 and 2012 when you try to restart them. A full server reboot ends up being required.)

+1
Login to vote
Maver's picture

Ridiculous...absolutely ridiculous.

0
Login to vote
Mark Ragnar's picture

We are all waiting for the "ScrewUpAfterDST" =0 Registry Key

+1
Login to vote
Steve Kratz's picture

That one really made me laugh... In a sort of cynical, pessimistic sort of way :)

0
Login to vote
Richard Gurley's picture

Yep,  I really like this one.

0
Login to vote
Taber Keith's picture

I have clients that have experienced this problem over multiple versions of BE.  They are ready to move to another solution.  The logic is very simple...  If you can't fix this after all this time what else are you screwing up that I just haven't found yet.  Symantec's response to this problem, Go submit a complaint, is unsatisfactory and extremely disappointing.  This is an urgent issue.  Without a credible solution it is likely some will want to change backup solutions when their support renewal comes due.

0
Login to vote
chickenIT's picture

Come on, how can this be acceptable? Get it sorted!

btw love the ScrewUpAfterDST" =0 Registry Key!

0
Login to vote
Colin Weaver's picture

Backup Exec 2012 does not have the DST issues - as such this issue is resolved in the latest version.

We cannot fix the issue in older versions as it required a complete rewrite of the scheduler code (which happened in the 2012 version.)

0
Login to vote
Steve Kratz's picture

The only thing I'm worried about is that BE2012 isn't going to be a good fit for many of the customers I support. From doing one small deployment (<10 servers) and one larger one (>20), I can see where managing a server-centric batch of jobs could quickly get out of control. (Now, take those 20 servers, and have backups that run a full & differentials to removable HD media, but they want another job that dumps a full copy of their data to tape each night for off-site purposes...  You suddenly have 60 jobs to try to juggle. (Unless there's something in there I'm missing that allows "merging" of jobs.)

0
Login to vote
Richard Gurley's picture

I wish symantec would work on the issues as they come up and not when it will be an inconvience for them.  This DST issue has been around since BE 8.5.  I've just been dealing with it over the years.   But in the last couple of years it has become a serious pain.  I have 8 remote site and 1 main site.  Each remote site has min of 3 jobs but some have 5.  My main site now has over 30 jobs.  They should have just changed the code back then and not now.  It will be little issues like these that will drive users from symantec as a backup software to the other that done have these little issues.

0
Login to vote
Colin Weaver's picture

For customers not on 2012 the most common issue regarding missed jobs relates to mismatches between availability windows and job start times, which is covered by

http://www.symantec.com/business/support/index?page=content&id=TECH61668

http://www.symantec.com/business/support/index?page=content&id=TECH87528

For customers on 2012 we have worked to address the identified DST issues as part of the complete overhaul of the scheduler itself.

We could not fix this prior to the major changes that occured within Backup Exec 2012 itself as the complete scheduler re-write more or less touches every part of the core code on the media server itself, so was a major undertaking not something with a quick fix possible. This did of course result in a number of scheduler related defacts from multipel BE versions queueing up pending a permanant fix and then all being resolved at the same time against the BE 2012

0
Login to vote
nPc's picture

As a newer BE admin, and having just run across this bug for the first time, I would like to suggest to Symantec that it would do us a great service to update http://www.symantec.com/business/support/index?page=content&id=TECH61668 to state that you Must Restart BE Services, or reboot the server to clear the bug.   Merely waiting for "the next scheduled backup to run and confirm that the job was successful" did not --in my case at least-- work, and all my jobs failed ("missed") again last night. Technically now three nights in a row.

Also, the Workaround is somewhat ambiguous:  Must I do both steps?

  1. Re-run the 'missed' backup job.
  2. Await the next scheduled backup to run and confirm that the job was successful.

Can I hold the job queue and re-run jobs, and then cancel them so they do not run during the workday and impact my users?  Will that satisfy step 1. above?  Do I in fact need to do step 1. above?

When the subsequent scheduled jobs did not run successfully, I gleaned from the forums that a services restart or server reboot is the functional solution.  I hope that is true because 3 nights of no backups is negatively impacting our database servers and I cannot test this except to wait until tonight.

Regards,

 .

 nPC

 BE 2010 R3

0
Login to vote
Peterhr's picture

Guys, run your backup server in time zone UTC or GMT (or another time zone that doesn't use DST) ... the client PC's will work fine with this.

0
Login to vote
Grissom's picture

nPc,

if the jobs were scheduled before the time change, they will fail for the first time they try and run after the change. You can do either method to re-run the jobs (don't have to do both).

You can re-run the job after it fails -> Workaround 1, or let it run on it's next slotted time -> Workaround 2.

I am going to look at the options in http://www.symantec.com/business/support/index?page=content&id=TECH87528 to see if this can be avoided for the next time.

Grissom angry

+1
Login to vote
nPc's picture

My solution was to prepare a Scheduled Task in the Windows OS to trigger a system Reboot right after the time change.

This works well, with some acceptable losses: Some tape jobs need to be re-run, and one disk job is irreparably lost, but it's not a critical one, and a couple tapes are rendered "End Marker Unreadable".

Of course, you have to set the reboot for 3:05 am in Spring, and 2:05 am in Fall, for what should be obvious reasons.  This reboot seems to avoid the "fail first time" issue for most, but not quite all, jobs. (All mine were scheduled before the time change).  A second manual reboot cleared the issue for the remaining 2-4 jobs that did fail later on.

FWIW.

 .

 N

0
Login to vote