-
- Novice
- Posts: 6
- Liked: never
- Joined: Sep 11, 2012 2:58 pm
- Full Name: Joey Leclerc
- Contact:
Time change bug
Noticed a little bug in Veeam.
A year ago, while looking at the B&R job history, we noticed that one job didn't run for one night and that no warnings or errors were triggered. We didn't like that behavior and we've been monitoring for that condition ever since.
This morning, we noticed it happened again. The job did not run, no warnings, errors, or indication of a problem from B&R as before. I did notice that the job is scheduled to run for 2:00a ... co-incidentally that's the date and time where clocks go forward 1 hour. Reminds me of the leap year bug issue from a couple of weeks ago.
What about everybody else, anyone else noticed the same problem for any job scheduled to run at 2a March 13, 2016. I wonder if it's just the 2:00a jobs or the 2:00a to 2:59a jobs.
The bug has been reported to support (Case number 01727635).
Cheers,
Joey
A year ago, while looking at the B&R job history, we noticed that one job didn't run for one night and that no warnings or errors were triggered. We didn't like that behavior and we've been monitoring for that condition ever since.
This morning, we noticed it happened again. The job did not run, no warnings, errors, or indication of a problem from B&R as before. I did notice that the job is scheduled to run for 2:00a ... co-incidentally that's the date and time where clocks go forward 1 hour. Reminds me of the leap year bug issue from a couple of weeks ago.
What about everybody else, anyone else noticed the same problem for any job scheduled to run at 2a March 13, 2016. I wonder if it's just the 2:00a jobs or the 2:00a to 2:59a jobs.
The bug has been reported to support (Case number 01727635).
Cheers,
Joey
-
- VP, Product Management
- Posts: 27375
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Time change bug
Hi Joey,
I believe this is expected behavior, cause the start time hasn't been met due to clocks going forward to 1 hour.
Thanks!
I believe this is expected behavior, cause the start time hasn't been met due to clocks going forward to 1 hour.
Thanks!
-
- Novice
- Posts: 6
- Liked: never
- Joined: Sep 11, 2012 2:58 pm
- Full Name: Joey Leclerc
- Contact:
Re: Time change bug
Support said that they will forward the information to the devs.
I'm sure anyone whose written anything involving schedules and elapse times are due to have this oversight.
I am a little bit concern where backups are expected to happen but yet it gets skipped with no warnings or errors generated.
Thank you Vitaliy.
joey
I'm sure anyone whose written anything involving schedules and elapse times are due to have this oversight.
I am a little bit concern where backups are expected to happen but yet it gets skipped with no warnings or errors generated.
Thank you Vitaliy.
joey
-
- VP, Product Management
- Posts: 27375
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Time change bug
I understand your concern, but imagine if you move a date to 30 days ahead. In this case job should not be triggered 30 times either...
-
- Veteran
- Posts: 387
- Liked: 97 times
- Joined: Mar 24, 2010 5:47 pm
- Full Name: Larry Walker
- Contact:
Re: Time change bug
If you are looking at then case 01729455, SAN snapshots couldn't be used for FLR though the GUI for 24 hours from when DST took affect. I could mount the snapshot manually and get the data so I know the snapshot was ok. When I tried to restore a file in FLR a error popped up about the time was wrong. After that one day all was fine.
Who is online
Users browsing this forum: Bing [Bot], chris.childerhose, massimiliano.rizzi and 139 guests