Sorry for the ignorant question, but why would you let a script that prunes start before you finished your initial backup? That makes no sense to me.
Simply because there’s no way to know when the backup script will finish. How long does it take to back up 3TB? The time taken may vary depending on whether it’s the initial full (3 TB) backup, a subsequent snapshot where only a couple of files have changed, or a major subsequent backup where a multi-GB 4K video file has been added to the backup selection. If I need to be absolutely sure that the backup has finished before running the prune then I would basically have to do it all manually and babysit it until it finishes, and then run the prune manually as well sometime later. It all defeats the object of automation and scripting. That’s why I want the prune script to run on its schedule, but exit gracefully when it realises there’s an active lock caused by the running backup.
I’d assume that your internet connection got interrupted at some point or something else went wrong which interrupted the backup after restic uploaded some packs but before it could update the index. Running
restic rebuild-index will probably clear the warnings.
You are using systemd ro run your backups which provides some neat ways to define dependencies. Using Conflicts should disable
restic prune as long as
restic backup is running.
PS: Looks like ericw already wrote some scripts to deal with this.
That’s entirely possible. It has been known for my ISP to perform maintenance overnight and for it to be back up again by morning so I don’t usually know whether it’s been off or not.
Do I need to stop the (still running) backup before doing that? And then afterwards if I restart the backup will it pick up where it left off?
If an interrupted connection can cause these issues then I’m wondering how I can script around this to make my automated system reliable and failsafe under most circumstances.
Thanks - I hadn’t considered conflicts; I’ll definitely look at that. I have a basic understanding of systemd but I can’t take credit for the systemd scripts - I followed Rolf’s tutorial here: https://gist.github.com/rolfn/5637ba74fdc152ea38eaa99fa3fa1bda which seems to be exactly what I wanted. I’ll check out Eric’s as well, thanks.
If a backup gets interrupted and is restarted, restic will just continue to upload data. restic might need some minutes to recognize which parts have already been uploaded but it will roughly continue were it stopped.
That said, I’d personally let the backup finish and
restic rebuild-index; restic prune; restic check afterwards.
You could simply schedule more backups. Having more snapshots usually doen’t hurt as the data is deduplicated. systemd should prevent a 2nd backup run if the 1st hasn’t finished yet.