-
-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider restic as a backend? #172
Comments
This is kind of similar to #109 - is it possible to use restic as a Go library instead of using the provided binaries? |
Good question! If it isn't eight now, we could probably adopt it so that it can be? |
The trouble is, if this tool would consume a blob of Go code that is not meant to be used as a library, we don't get any stability guarantees for the API interface, which I'd consider a deal breaker. If restic is meant to be used as a library as well, I would be open to thinking about this for whenever V3 is happening (which is not going to be very soon). |
Judging by the open issues and codebase of restic, I don't see an easy way to use it as a library and it looks like it might not happen. Hmmm 🤔 -- What about abstracting the code here in this project such that one could easily (if they wanted to) integrate the use of |
Theoretically, you could already "bring your own backend" by doing the following:
This should basically give you what you want. The only ugly part here would probably be that you have to figure out the filename of the archive yourself somehow. Maybe it would be nice to make such values (file locations and such) available in the environment so scripts like this could consume them. |
I added this in |
Nice one! I'm going to give this a try! Thank you 🙏 |
Have you considered using restic as a backend directly for storage/backup so this tool can focus on the parts that matter (docker volumes, stopping/restarting containers, etc)? 🤔
The text was updated successfully, but these errors were encountered: