Support to stop and start other docker containers before and after backing up
Opened this issue · 12 comments
Is your feature request related to a problem? Please describe.
Backrest is awesome - especially that it provides a very nice web UI and an is intuitive to set up the backups. I have most of the services running as Docker containers, and to make Backrest safely backup their data, I'd prefer if the service containers are stopped before the backup process starts, and are restarted afterwards. Something that https://github.com/djmaze/resticker?tab=readme-ov-file#execute-commands-prior-to-backup does, but it doesn't have Backrest's UI goodness and sophistication (yet!).
Describe the solution you'd like
If we could provide a list of docker containers to stop in a Backrest 'Plan' (or a docker container label we can specify, which Backrest can use to query all the applicable containers), and Backrest can stop them before backup runs and start them afterwards, it would be great!
Additional context
Pretty much what's described above.
Backrest supports this through hooks :) https://garethgeorge.github.io/backrest/docs/hooks
You're looking for a command hook on CONDITION_SNAPSHOT_START. Bearing in mind, Backrest's docker image does not include the docker cli etc, you will need to build a custom container for this OR to install backrest bare-metal on your system.
That's a record-breaking fast response! 😄
Yeah it looks like hooks can pretty-much do it. Is there any remote possibility that docker cli is added to backrest's docker image? Something like this? I guess that's all that would be needed, because if /var/run/docker.sock is mounted, adding a hook like docker stop mycontainer would just work? 🙇🏽♂️
I'm trying to avoid the overhead of maintaining a custom image and having to keep it updated with this upstream Backrest image, when the net diff is going to be the docker-cli package of ~25 MBs
I know and respect if it's an opinionated decision to not include anything else other than restic binary in Backrest. But since the 'Platform Support' in the Readme lists Docker as the first one, it'll be awesome if a first-class support for Docker is added in the form of docker-cli availability 🙏🏽
Hmm, my hesitance here in the past has been that this adds ~8MB to the image size compressed and, as you say, close to 25MB unpacked and deployed on a user's system.
Philosophically I've felt in the past that Backrest should take up minimal storage and runtime overhead since at the end of the day, it's backup daemon. It should be as lightweight as possible so that backups can blend into the background and a user can use that storage for actual data.
Not quite sure what the right balance is here, I'd be interested to leave this open for a bit to see if there's a strong community desire to see this included.
Makes sense, appreciate your thoughts!
Meanwhile, I have locally created a docker image (I haven't published it to Docker hub yet) which simply adds RUN apk --no-cache add docker-cli on top of garethgeorge/backrest:latest image and I'm using it. But to keep the latest image sync with backrest's latest tag, I'll set up a GitHub repository and an action that periodically publishes this image to docker hub.
Not immediately on my radar, as I'm currently busy setting up backups for my services, but I'll post here once I have the image published.
Thanks again!
Is docker-cli a single binary without dependencies? If so, one could simply bind-mount it into the backrest container. I initially did so with rclone until I noticed backrest has its own.
I haven't verified it yet, but it's unlikely to work, as backrest image is alpine-based, the docker-cli package, even if it is a single binary, would depend on musl. So a glibc-based binary on host, even if mounted to the container can't be executed from inside the container.
One option is to add an INCLUDE_CLI env/arg to signal whether to include it in the image on build time. That or including a GitHub action for publishing the backrest-cli image.
Either way I would like to see this included 👍
Hi shaaraddalvi did you have released your edition with docker-cli. I would also be happy if there was docker added because of possibility of stopping immich container for backup so I don't have a corrupted backup. And I think more people would enjoy it. Can you make it official with docker-cli added?
Thanks all for the feedback, based on what I'm seeing here and some more thinking on my end I'm going to aim to add docker to the image in the next minor version release (probably a few weeks out).
I think it's a good FR and discussing with more users I think it's a very common want for dockerized deployments.
Hi shaaraddalvi did you have released your edition with docker-cli. I would also be happy if there was docker added because of possibility of stopping immich container for backup so I don't have a corrupted backup. And I think more people would enjoy it. Can you make it official with docker-cli added?
No, I haven't gotten a chance to publish the image yet, but now with the possibility of backrest officially supporting it, I won't need to 😄
@garethgeorge is there a plan to add docker-cli in any upcoming release? I was actually looking forward to having it in 1.3.0 😅