tonight we had the clock change because of daylight-saving time here in Germany. The clocks were adjusted from 3:00 back to 2:00.
This clock change triggered 7 alerts on TrueNAS SCALE Dragonfish-24.04.2.1 because I have a Periodic Snapshot Task triggering every 10 minutes and keeping the snapshots for 2 hours. The names of the created snapshots are in the format “foobar-minutely-%Y-%m-%d_%H-%M”
TrueNAS reported in the alerts that “Failed to create following snapshots” with the reason “File exists” which makes absolutely sense if a snapshot was created at 2:30 and the time 2:30 appears again after one hour because the clock was adjusted backwards by 1 hour.
However, isn’t this anything TrueNAS could take care about? Either by recognizing a clock change and taking care of it (has to be checked how this could be done the best) or by using another variable in the filenames to avoid filename conflicts. Thinking about a simple counter or using the Epoch (unixtime).
The worst thing is that because of the current behavior TrueNAS was unable to take the 10-minutely snapshots for the duration of one hour. So my data protection strategy by using snapshots was disturbed for a window of 1 hour.
Daylight Savings Time is for humans. Systems should use UTC. So the answer to your question would be to use UTC for naming your snapshots and accepting whatever pain is incurred when you as a human needs to find the right one. Or, of course, accept that you won’t have snapshots for one our a year.
Even when using UTC you might still face issues due to leap-seconds, but creating snapshots every second is likely an anti-pattern.
However looking at the documentation, the formatting keys return values in the system locale, which in your case means they’ll honour DST.
As far as I can se you have three options:
Name the snapshots with Unix Epoch, seconds since 1970 using the %s parameter
Change the system locale to something, that does not use DST. Though I’m not sure what the consequences of that would be for filestamps etc.
Accept that you’ll miss six snapshots a year and live with that.
I hope you find this usefull.
PS. For somewhat related reasons I try to avoid running any scheduled tasks between 02-03 because of DST.
When trying to add %s at the end of my naming string TrueNAS complains about “No other placeholder can be used with %s in naming schema”. Is there a limitation of the strftime command or is this an artificial limitation of TrueNAS?
As %s seems to not be the best solution in my case I thought about using %z and %L which gives the “Time Zone Hour Offset” and the “Milliseconds”.
However, TrueNAS seems to not support %L, so I will go with %z and try how it behaves.
The %Y-%m-%d_%H-%M__%z gave me something like 2024-10-27_14-00__–0100. The --0100 looks a bit strange to me, as the Timezone is set as Europe/Berlin in the Localization Settings. The offset should be positive by 1 to 2 hours and also not having such double minus at the front.
Because of this issue my snapshots are now named with the Epoch %s only which gives me names like “minutely-1730065200”. For the human readable date I have to go with the separate date/time information about the snapshot. Not ideal, but better than a creepy Time Zone Hour Offset and also better than a lot of Alerts once a year.