Had an idea and thought I’d run it by the forum before cluttering up GitHub.
What if we had a
RESTIC_ALT_REPO switch that would give an alternative means to reaching the same repo (or just a backup secondary repo).
A few use cases…
- You primarily backup at work, at rest:http://backup-server, but the Rest service goes down. SFTP is still available. So if you had
RESTIC_ALT_REPO=sftp://backup-server defined, it would still work. (I run into this myself because of JAMF policies messing with the firewall and occasionally blocking the service at my office.)
- You primarily backup to a local server, but the address is different outside of your network. With an --alt-server you could have your scripts work off-site as well.
Just a thought! We’d have to make sure to differentiate it from “RESTIC_REPOSITORY2” but other than that I think it could be helpful.
Also I see no reason why this couldn’t be specified multiple times for extra redundancy!
Are you talking about multiple copies of a repository or just multiple addresses in which to reach the same repository? With multiple copies its pretty easy to run into situations where the repositories diverge and then it will be a challenge to clean things up.
If restic is to be focused on backup then this type of problem should be dealt with else where. My preference would be for you to place checks in the script before calling restic, to determine the method of connecting to the repository. This would also allow you to put in notifications to send to yourself when the alternate method has to be used.
This assumes that the connection to the repository does not need to change while the backup is talking place. If that needs to happen a whole bunch of complexity about checking that no writes were lost at the end of one connection before trying to do more writes with the new connection.
Just my two cents.
I’m mostly talking about a fallback address for the same repository, because yeah, two separate repos would diverge.
I handle this already with an if statement, so it’s not a big deal. Just thought I’d float the idea to see if others would think it was useful.
This would also help with a shared fallback Repo for multi-client-own-Repo usecases as described by me here.