Idiotmatic way to backup and restore for hourly backups

Looking at needing to do hourly backups for all our production hosts.

I know I can use for forget --prune --keep-policy ... to have restic choose how to prune backups.

But is there some built in method to make hourly snapshots easier? Or am I just going to have a wrapper script run on a cron and just error out if there’s already a restic instance running?

Using cron would be the recommended way to do this. Restic doesn’t implement cron functionality; that would be a waste of effort given that cron already exists.

You can run multiple restic instances in parallel. If you want to limit to one running instance then you can use something like flock -n /var/run/restic.lock restic .... If there is already a flock-managed restic instance running, then this command would immediately fail without invoking restic.

2 Likes

Yeah that might work, currently just doing this in the start of my script :

if pidof restic > /dev/null; then
   echo "restic is already running"
   exit 1
fi

So either run every hour or bail out if the older job is still running.

The advantage to using a lock file is that you can lock specific restic operations/repositories semantically instead of just looking for a restic process. Consider that a malicious process could run while :; do restic --help; end and have a pretty good shot of getting your script to skip its backup; however if you lock on a file that only root has access to, you can ensure that only root is able to cause a backup to be skipped.

It also allows you to run restic against other repositories if you need to (for e.g. inspection or maintenance) without accidentally causing a backup to be skipped.

1 Like

I believe a systemd timer can be set not to start if the previous instance is still running.

You are right: https://stackoverflow.com/questions/35387345/what-is-stalling-my-systemd-user-timer

1 Like

Hmm, several good points. Thank you.

Yeah that would probably work. Need to move more of my cron jobs over to systemd timers.

Just as an aside, be sure to backup your Crontab and timers that you have set as part of production. A place that I knew had to do a restore of a server and no-one knew what exactly was in the crontab so it took a while to get things running smoothly again.
crontab -l > filewithdateand24hourtime

1 Like