Hourly backups

[shawwn]

It might make sense to let certain jobs be scheduled hourly rather than daily, especially if a directory is being replicated to some other machine. I could add this, if it'd be useful.

[shinnok]

The reason I didn't add this from the start, was the limited scheduling options I had cross-platform.

On Linux and *BSDs we're stuck with CRON for non-superuser scheduling. The biggest caveat with using CRON for scheduling backups is that CRON won't defer missed scheduled invocations if your system was powered off, sleeping or hibernating at the time when the timer should have fired. That also implies that if your system is always powered off when the backups should fire, say 10AM, then your system will never be backed up. In order to get around this issue we have to use a schedule cadence that will fire often and many times during the day. In my testing the best bet is to schedule tarsnap-gui --jobs at every 30 minutes. This is the biggest time increment that ensures backups will fire for 99% of use cases and that is easy to do via a single line CRONTAB.

Launchd is indeed more flexible and programmable; unlike Cron. Adding hourly is not impossible, especially since the cron version is already probing hourly for the reasons quoted above, but going any granular than that, say every other day, specific day or hour, etc.. should stay out of scope for the GUI and best left for the command line version. Going hourly though, would imply that the Launchd service has to be fired hourly too just like cron, which is not the case now. It only fires once a day at 10AM and is aware if an invocation has been skipped due to system down-time, sleep, etc for the designated hour and will be launched retro-actively in a coalescing manner of course. Thus the daily granularity. :)

Quote above is from:
https://github.com/Tarsnap/tarsnap-gui/wiki/Scheduling

[shawwn]

Yeah, but nobody uses Linux or FreeBSD anymore.

More seriously, tarsnap-gui could install a service (daemon) instead of a daily launchd task, then run in a daemon mode. Then the daemon can spawn tarsnap-gui --jobs as often as it wants.

[shawwn]

Sorry, I'll stop joking around. I just realized I misread your reply completely. It's 2:40am and I was distracted. (I have a dumb sense of humor anyway.)

That's good news. A 30min interval sounds reasonable. I think it'd be easy to change the .plist so that it fires that fast. I was also thinking that Tarsnap.app could just copy the plist to ~/Library/LaunchAgents every time it starts up. That way newer versions should "just work".

[gperciva]

I agree that it would be nice to support much more flexible backups (not only hourly, but also every other day, etc.).

I'm taking a cautious approach, though. Here's a few questions I'm considering and will be looking into before I'm comfortable progressing further:

• How can we minimize the platform-specific code? Ideally the GUI should be easy to adapt to any platform that Qt supports (including Windows). Code specific to cron or launchd probably won't work on Windows.

• How can we minimize the platform-specific UI and docs? It would be nice if we didn't have any significant difference between OSes as far as users are concerned.

• Is it worth compiling a reduced command-line version of the GUI in order to handle scheduled jobs? Or could we simply use the command-line tarsnap for those tasks, and get relevant info into the GUI somehow (without a --fsck)?

• If we used the current cron method for launchd (trigger every 30 minutes, then our program checks if it should make a backup or not), would that be a significant drain on system resources? If so, could we avoid that with a shell script? Would the shell script need to understand SQL, or could we move the relevant info to a plaintext file?

These questions aren't impossible to answer, of course, but right now I give the test suite higher priority than scheduling.