Detect Backups Skipped by Daylight Saving Time
Sources and verification
- Source dates
- Oldest source check: 12 September 2026.
- Technical verification
- Separate technical verification has not been recorded.
Publication approval and technical verification are recorded separately. Automated link checks establish reachability, not accuracy. A checked example verifies only its stated test cases, not the whole article or your production setup.
In short
Treat daylight-saving transitions as scheduling test cases, and monitor the age of the last completed backup independently of the scheduler. A local wall-clock time can be skipped or repeated. Confirm the actual scheduler version, time zone, and missed-run behavior, then define one safe catch-up policy with overlap protection. A next-run timestamp is not proof a backup occurred.
Key takeaways
- A local clock schedule and a fixed elapsed interval are different contracts.
- An independent maximum-age check catches a missing job.
- Catch-up behavior must be tested for the specific scheduler and release.
Write the backup deadline independently of the clock expression
A job configured for 02:30 local time may encounter a spring transition where that local time does not exist. An autumn transition can repeat a local hour. Scheduler implementations differ in how they interpret these events. Do not transfer cron behavior to Proxmox, a cloud scheduler, or systemd simply because the schedule looks similar.
Record the intended contract: once per elapsed interval, once per local business date, or complete before a particular recovery deadline. These produce different acceptable behavior around a clock change. Include scheduler version, node time zone, configured job time zone if separate, and the timestamp format used in logs.
Check the real scheduler and its catch-up option
For current Proxmox backup scheduling, the project documentation (opens in a new tab) describes pvescheduler and a repeat-missed option. Check whether that option exists and is enabled in your installed version. It is a feature to evaluate, not proof that every daylight-saving edge case is handled the way your recovery policy requires.
Inspect the configured job and actual task history together. A UI that advances “next run” can do so even when the previous expected run produced no usable backup. Keep evidence of the backup artifact and its completion time as a separate source of truth.
UTC scheduling avoids a local daylight-saving transition in the scheduled clock, but changes the corresponding local time during the year. Use it when elapsed cadence matters; confirm the effect on business deadlines and maintenance windows before changing an established schedule.
Add a last-success age detector
Track the most recent successfully stored recovery point, not the latest task start or file modification on an old archive. An outside checker should alert when its age exceeds the agreed limit. Heartbeat receivers (opens in a new tab) can express schedule and grace expectations; ensure their time zone and deadline match the backup requirement.
For example, a daily backup policy might allow a maximum age of 27 hours, provided that meets the accepted data-loss limit. This is an example, not a universal grace period. A business requiring much fresher data needs a different backup cadence and alert threshold.
Simulate transitions without changing the production clock
Use a disposable scheduler instance or its supported schedule-preview mechanism with the same version and time zone. Do not jump the clock on a production cluster to test this.
| Scenario | Required observation |
|---|---|
| Spring skipped local hour | Recorded run behavior and independent late alert |
| Autumn repeated hour | Number of runs and unique run identities |
| Node offline at schedule time | Documented catch-up behavior after return |
| Previous backup still running | Overlap prevented or safely coordinated |
| Catch-up fails | No false success; deadline remains overdue |
Make catch-up safe and visible
Use the backup system's supported concurrency control or a job lock. Give every run a unique artifact identity, so a duplicate run cannot overwrite the only recoverable copy. Bound retries and capture their result. After a missed run, confirm a new stored backup and perform the appropriate restore validation; merely clicking “run now” does not close the monitoring gap.
Did this help?
Your answer helps us improve this guide. We save only the page and your choice for 30 days.
No name, email, or incident details are requested.
Sources
Vendor facts change. Each source below shows the date this page last checked it.
- Proxmox backup scheduling documentation — Proxmox. Checked 12 September 2026.
- Configuring deadline and heartbeat checks — Healthchecks. Checked 12 September 2026.
Related
One practical idea, occasionally
The On-Call Brief: short field notes, templates, and operational lessons.
Follow the field guide
Email subscriptions are not open yet. Read new guides in your feed reader — no email address needed.
Subscribe with RSS