Output of restic version

restic 0.15.2 compiled with go1.20.3 on darwin/arm64

What should restic do differently? Which functionality do you think we should add?

Restic does not only do a good job as a backup utility, but is also written in Go just as many cloud-native and Kubernetes-based tools / operators are. Allowing restic to be used as part of another application instead of spawning a Go binary from another Go binary would not only be more resource-efficient, but would also allow to have a better control about the state and behavior.

Restic has most of its logic as an internal package, which prevents other libraries from importing.

Please be less restrictive when it comes to declaring parts of restic internal to allow other projects to use restic as a library.

What are you trying to do? What problem would this solve?

I'd like to use restic as part of a larger construct (Kubernetes Operator) to automate different DR scenarios. I'd like to provide detailed information about the status, which could be easily achieved by a custom StatusReporter if this wasn't internal.

Other use-cases exist (see for example restic-robot), where a Go application spawns restic as another process, introducing overhead and the binary as additional dependency.

Adding more flexibility and use-cases would increase the potential for people to contribute back to restic and increase its overall popularity.

Did restic help you today? Did it make you happy in any way?

The flexibility to use restic even on Windows due to its Go nature is just perfect and makes a big difference when comparing it with other utilities like borg.