Forum Discussion

mk128935's avatar
Level 5
6 years ago

How Backup Exec handles changes between standard time and DST

Hi, this is kind of related to a thread I raised before on how Backup Exec handles DST. But I received some further detailed questions on how this is handled (see attachment). Can somebody help me answer these questions? 

Basically, I'm being asked how backup jobs run, how log recording and retention period is handled when the time changes are made under the attached scenario. I know this may be a mouthful to look at but I'd appreciate the feedback. 

Thank you! 

  • You won't be able to test in Skytap unless you can disable the timesynch into the VMs

    But yes BE and NBU will work differently so cannot be compared as the schedulers are completely different development teams with no shared code between the two products in this area.

4 Replies

  • Until you asked your previous question , we had not received any questions about DST handling after we implemented the changes in the 2012 release. This means the changes we implemented over 6 years ago seem to work and as such tech support have not needed to ever know the exact experience of the DST change, and in fact I had to go back and look at some internal training information  provided over 6 years ago to even clarify some of your questions

    The backup job start time is now always based on DST timings  and never based on local time without the DST offset (of course in winter the DST offset is 0)

    Backup jobs set to start in the hour that does not exist (so is invalid)  because of the change at one end of the year will run on the first time instance after that invalid time and then the next job instance after that will start at the expected (DST applied) time - I am sorry but if you set your job start time window to less than 1 hour it is possible you will have a problem but I cannot confirm that. I would however not recommend such a schedule just in case. So Q1 looks like you have the correct answer and Q2 we cannot answer but we recommend not using a short start time window.

    We do also stop the job from starting twice at the other end of the year, where timings occur twice (basically a running job from a single definition blocks any other instance of the same job starting and then next start time is only calculated when that running job ends) So Q3 is yes it won't run twice.

    To be honest we don't have the detail on what happens to console or job log timings during a job if it is running across the time change, but whatever does happen does not cause too much confusion as in over 6 years of Backup Exec since we fixed the handling DST  you are the first person to ask such a question and it was not covered in our original material.  As such only someone who has specifically kept screenshots and jobs logs for such an event will be able to answer this. I suggest you take a look after the next change if your are curious. (unless another forum contributor has some logs that would confirm this and can answer it)

    Equally having media retention potentially being 1 hour out due to the change has also not caused any queries so looks to have not caused any issues (probably as in the general scheme of things most admins keep their media for a lot longer than 1 hour making a 1 hour difference meaningless) - unfortunately support again do not have documented information on the exact effect, If I had to guess though I would suspect we always base the retention on converting the retention periods to hours and adding that to the UTC start time for the period in question and we therefore don't worry about DST  or local time for this calculation. (This guess is based on knowledge of how we store information inside the BEDB and our catalog files)



  • On extra point as you are asking about a planned change in Japan (whuich does not currently have DST) - all of the information provided about Backup Exec handling DST assumes that the Operating System will automatically adjust - which of course will require action by Microsoft etc


    If you manually change the time  on a Backup Exec server by more than a few  of minutes (so by an hour if Microsoft do not patch the operating system), you should really do this with the Backup Exec Services stopped and the console closed   (which would mean you can't have any running jobs anyway)  and any scheduled jobs should then try to start once you bring the services back online



    • mk128935's avatar
      Level 5

      Thanks for the thorough feedback! So we now run backup jobs based on DST timings so DST is taken into account. I didn't realize that. I was reviewing the attached NBU whitepaper on DST and assumed BE works similarly so for Q1, if a job is scheduled to run at 2:00am, when the changeover to DST takes place, because there's no 2-3am, backup job execution would be skipped during this day but would run at 2:00am the next and following days. But according to what you say, the backup job would run even on the day of the changeover so it would run at 3:00am. Correct me if I'm wrong.

      Also, when the changeover back to standard time in October takes place, this would probably have no effect and run at 2:00am on the day of the changeover and 2:00am the next day and beyond. 

      And I guess there's some logic inside which prevents jobs from running twice due to the changeover which is nice to know.

      I'm asking for engineering for some further comments on these and hope to share them once I get them.

      In the end, I think I'm going to have to try this out myself either in my lab or skytap to get a better feel for this. It's a bit of a pain to explain this to them but at least it's nice to know that we haven't had any issues with this. 


      • Colin_Weaver's avatar

        You won't be able to test in Skytap unless you can disable the timesynch into the VMs

        But yes BE and NBU will work differently so cannot be compared as the schedulers are completely different development teams with no shared code between the two products in this area.