Problem or use case
Right now scheduling is cron only, so a plan fires at one fixed time. That's
fine for servers, but kind of painful for clients that aren't guaranteed to be
online at that exact moment. If mine is offline when the cron fires, I just get
a failed run + error in the UI, even though nothing's actually broken — it was
just asleep. And there's no catch-up, the slot is just gone until tomorrow.
There's also the inverse problem: if you'd try to work around this by running
the schedule more often, you either get a bunch of archives per day, or you hit
the dumb edge case where one run fires at 23:55 and another at 00:05.
I had a look through existing issues first so this hopefully isn't a dupe:
Setup for context: SSH remote, not a managed agent — so the availability signal
here would be an active reachability probe (TCP/SSH check) before dispatch,
rather than relying on an agent presence state. Same desired behaviour either
way though.
Proposed solution
Something closer to a systemd timer with Persistent=true: "make sure there's
about one backup a day, run it whenever the client is actually reachable, and
don't spam it." So a frequency target instead of a fixed timestamp — the
scheduler checks every so often whether the source is up, and runs at the first
opportunity it's reachable.
On top of that, a minimum interval between two successful backups (say 20h,
configurable). That's what prevents the many-archives-per-day problem and the
23:55 + 00:05 edge case — a run only happens if enough time has passed since the
last successful one.
One important detail: when a check decides not to run (client unreachable, or
the min interval hasn't elapsed yet), that should be a neutral "skipped" status,
not a failure. The whole point is to stop the false-alarm errors I get now, so
those skips shouldn't trigger failure notifications. Bonus if the log says why
it skipped (unreachable vs. min-interval), but that's a detail.
For now I'm faking it with a high-frequency cron plan plus a pre-backup gate
script (reachability check + last-backup timestamp, set to skip on pre-backup
failure) and a post-backup script that writes the success timestamp. Works, but
it's a pile of glue around something that feels like it should be a real option.
Alternatives considered
No response
Area
None
Additional context
No response
Problem or use case
Right now scheduling is cron only, so a plan fires at one fixed time. That's
fine for servers, but kind of painful for clients that aren't guaranteed to be
online at that exact moment. If mine is offline when the cron fires, I just get
a failed run + error in the UI, even though nothing's actually broken — it was
just asleep. And there's no catch-up, the slot is just gone until tomorrow.
There's also the inverse problem: if you'd try to work around this by running
the schedule more often, you either get a bunch of archives per day, or you hit
the dumb edge case where one run fires at 23:55 and another at 00:05.
I had a look through existing issues first so this hopefully isn't a dupe:
covers the "I plug in an external drive and trigger it myself" case, but it's
still manual — there's no unattended trigger. This is specifically about
automatic runs gated by availability.
after the fact, it doesn't change when a backup actually runs.
honestly feels like the perfect availability signal for this — "agent is
connected" basically means "now's a good time" — but the scheduling itself is
still cron-based and there's no catch-up/debounce on top.
Setup for context: SSH remote, not a managed agent — so the availability signal
here would be an active reachability probe (TCP/SSH check) before dispatch,
rather than relying on an agent presence state. Same desired behaviour either
way though.
Proposed solution
Something closer to a systemd timer with Persistent=true: "make sure there's
about one backup a day, run it whenever the client is actually reachable, and
don't spam it." So a frequency target instead of a fixed timestamp — the
scheduler checks every so often whether the source is up, and runs at the first
opportunity it's reachable.
On top of that, a minimum interval between two successful backups (say 20h,
configurable). That's what prevents the many-archives-per-day problem and the
23:55 + 00:05 edge case — a run only happens if enough time has passed since the
last successful one.
One important detail: when a check decides not to run (client unreachable, or
the min interval hasn't elapsed yet), that should be a neutral "skipped" status,
not a failure. The whole point is to stop the false-alarm errors I get now, so
those skips shouldn't trigger failure notifications. Bonus if the log says why
it skipped (unreachable vs. min-interval), but that's a detail.
For now I'm faking it with a high-frequency cron plan plus a pre-backup gate
script (reachability check + last-backup timestamp, set to skip on pre-backup
failure) and a post-backup script that writes the success timestamp. Works, but
it's a pile of glue around something that feels like it should be a real option.
Alternatives considered
No response
Area
None
Additional context
No response