Skip to content
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

Install Restic Service #144

Open
EnigmaCurry opened this issue Nov 1, 2023 · 0 comments
Open

Install Restic Service #144

EnigmaCurry opened this issue Nov 1, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@EnigmaCurry
Copy link
Owner

EnigmaCurry commented Nov 1, 2023

One of the best ways of backing up a Docker server is to use a filesystem that supports snapshots (eg. zfs), and just backup those snapshots. Or simply choose a hosting provider that does this for you (usually for an extra monthly fee; but Proxmox also has good support for this if you want to stick to self-hosting.) This approach is easy because it centralizes everything into one backup task. There's only one thing to worry about backing up: everything.

It might be nice though to have separate backups for each volume, selecting only those volumes you really care about, and having different configurations for each of these. Instead of backing up the files in the native filesystem, you connect a backup container to each volume you have configured, and backup the files through the volume mount. This has the advantage that it does not require control of, nor coordination with, the host filesystem. It can all be done through connecting regular docker containers to volumes and performing the backup directly from the container.

I imagine this could be done with a new top level service that runs restic and you would configure all of the volumes that you want it to mount and to backup to S3. These volumes would be the data volumes of all the other containers you wish to backup. The sftp container is an example of a service that connects to several volumes through SFTP_VOLUMES, so RESTIC_VOLUMES could be a similar thing.

There is concern of backing up files that are not flushed to disk, ideally the services would be shutdown before the backup, and turned back on afterward. Other mitigations include blocking the network access during backups (but not shutting down the service), or sending a signal to the service to tell it to flush. For the purpose of this service, I'm not too concerned about it. You should not rely on this for databases. That is why the postgres service implements pgbackrest, because it is a backup strategy that is specially made for that database. So use that for postgres, not this. For a lot of files though, they never (or hardly ever) change, or do so in a predictable way. For these I think it doesn't matter that these services are shutdown or not, and just let restic backup what has been flushed regardless.

@EnigmaCurry EnigmaCurry added the enhancement New feature or request label Jan 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant