i.e. prestic run [COMMAND1] [COMMAND2] ...

Add integration tests using bats or the like.

Things to test:

1. restic commands run successfully
2. restic failures cause non-zero exit
3. AutoParent feature
4. Stdin command
5. Stdin command failure

Ideally it would execute the commands in order as defined in the config file, but right now it's arbitrary (maybe because go maps aren't insertion ordered). This means prune and forgets could run before backups.

Suggestions:

1. Order commands as defined in config file
2. Order backups first, then forgets and prunes

The idea is to run prestic install-launchd on macOS to install prestic as a launchd task that runs on a recurring schedule. Similar to anacron launchd can handle computer sleeps better than cron.

It might be useful to maintain pieces of the prestic configuration in separate files in /etc/prestic.d, for example on systems where applications may install their own config.

Add a command like the following:

prestic shell my_backup

...that spawns a sub-shell with env vars pre-loaded from the specified command. It could also populate special env vars with command flags and arguments. The idea is to make it easy to poke around a repo with restic commands. This of course requires the config use environment variables in preference to CLI flags, although it could try to be fancy and convert flags to env vars where possible.

# In the shell, can maybe use special env vars to re-create the command
restic "${PRESTIC_FLAGS}" "${PRESTIC_ARGS}"

# or perhaps create an aliased command that includes the flags
restic_with_flags "${PRESTIC_ARGS}"

Ideas:

• Add log levels
• Restic output goes to DEBUG
• Restic commands go to DEBUG (may show passwords)
• Log command name and execution time to INFO
• Log to prestic.log?
• Log to syslog?

Take a look at logrus

Some potential downsides to the state file for tracking snapshot IDs:

1. prestic doesn't currently manage locking/concurrency for updating this file
2. adds complexity

So far it's only used for the autoparent option. Could we lookup the snapshot ID by tag instead?