Discussion: New Trigger Semantics

[seoester]

In many cases, restic is used to backup to remote locations. This might be a network location (sftp or s3) or an external drive. In all cases, this location might be unavailable at times, e.g. not in home network, external drive is not connected, bad internet connectivity.

New trigger semantics could help to start backups at the right time and prevent failed runs and aborted jobs:

• The current time-based trigger system is interpreted as a schedule: A job should be run once a day.
  • What about cron style specification? Often there is a particular time of day which is convenient for running backups (https://github.com/robfig/cron).
• Conditions are introduced which have to be met before starting the job:
  • Folder available / non-empty
  • Device connected (udev)
  • Network available
    • IP routable
    • Host reachable (ICMP or TCP Port)

[KillingSpark]

The first suggestion should be easy enough and seems reasonable. The second one should be doable by introducing preconditions into jobs. Something like:

type preconds struct {
    pathesMust []string
    hostsMustRoute []string
    hostsMustPing []string
    udevDeviceMust []string
    .... (whatever other preconditions might come up later)
} 

Those would be checked at a 'every x seconds' basis and at most y times before the job actually tries to run restic.

[KillingSpark]

After changing the timer to use cron style format, I have to say that should've been the original design. It makes way more sense.

I implemented some of your suggestions for the preconditions. I will look into how udev could be integrated.