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

Ridiculous...absolutely ridiculous.

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

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.

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

btw love the ScrewUpAfterDST" =0 Registry Key!

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

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

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.

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

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