undefined | Better HN

0 pointsc0balt1mo ago0 comments

The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling.

Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (like PostgreSQL) might also have other online backup tooling.

0 comments

2 comments · 1 top-level

mrighele1mo ago· 1 in thread

AFAIK volumes are nothing more than a bind mount on a private docker folder, e.g. the files for volume my-volume are stored in /var/lib/docker/volumes/my-volume/_data, so backup strategies (an problems) for bind mounts apply also to volumes

c0baltOP1mo ago

Yep, that is accurate. There is also a command/API route to find the path on disk iirc.

In my setups it just was easier to use fixed paths (or relative to project dir) from a permissions management perspective. Backup tools did not always have to/should run as root which is helpful on machines providing multiple distinct services.

Putting borg or a similar tool in a container that is part of the compose manifest file can also help. I haven't seen this used in practice though yet.

j / k navigate · click thread line to collapse