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

Consider deprecating use of docker #196

Open
jayaddison opened this issue Nov 23, 2022 · 3 comments
Open

Consider deprecating use of docker #196

jayaddison opened this issue Nov 23, 2022 · 3 comments

Comments

@jayaddison
Copy link
Contributor

Some (potentially important) operations like backup and restore from volumes currently seem challenging with docker.

It is possible - after stopping an existing container, you can bind-mount a local directory and the previous container's volume into a single-purpose ephemeral container, copy/archive the relevant filesystem contents into the bind-mountpoint, and then keep a copy of that file to perform a backup -- and then at restore-time, use docker volume create to create an empty volume and then follow a similar process to uncompress the archive into the appropriate directory to populate it.

Generally something more like a filesystem copy operation and/or export...import command pair could be easier though: fewer dependencies, more straightforward to explain, less processing and bandwidth overhead, and hopefully more likely to last the test of time.

@RedlineTriad
Copy link
Contributor

To add my own input to this:
On my server I have created a symlink from /var/lib/docker/volumes to a separate partition (actually a detachable volume but whatever)
And so the backup and restore process is trivial.

Backup:

  1. cp/scp/rsync/borg create backup of data partition

Restore:

  1. Stop containers
  2. cp/scp/rsync/borg overwrite host files with backup
  3. Start containers

Most backup systems ignore docker and access volumes directly where they are mounted on the host so it's not difficult.

Many people just avoid volumes completely and manually mount containers to paths of their choosing.

And in Kubernetes volumes are also the best way to do things, since the platform is responsible for backup and restore.

@tylerwmarrs
Copy link

@RedlineTriad I'm not sure that your backups would work very well if you are using the default sqlite3 database that this grocy deploys with. So the backup isn't as trivial as you put it. Regardless, I am interested in how you set up the detachable volume. I've been testing with setting up a bind mount, but I haven't gotten through all of it yet.

@unusualevent
Copy link

... you could just mount the volume in the compose file to a sane directory like /home/grocy/backend.

volumes:
  app_db: /home/grocy/backend

there, sane edits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants