我在三台机器上运行了几个Docker容器，组成了一个Swarm集群。
一些存储持久数据的容器(如DB，Redis等(使用数据卷。(我尽量避免使用绑定挂载(
此类数据卷位于/var/lib/docker/volumes/中，并且为每个卷分配自定义名称而不是随机序列 ID：
# ls /var/lib/docker/volumes/
redis-data postgres-data fluentd-data ...
我想定期备份这些卷，例如每天备份，以便在发生计算机故障时可以恢复并在以后修复。
但是，我在谷歌中找到的每个文档都说明了使用新Linux容器和tar的方法：
https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes
$ docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
为什么？如果我只是存档/var/lib/docker/volumes/VOLUME目录并将其复制到其他机器，是否有任何问题？例如，权限、uid、gid 等？
$ tar -zcvf redis.tgz /var/lib/docker/volumes/redis-data
附言
在某些情况下，使用tar的备份可能会由于存档期间的数据更改而导致数据不一致。例如，在数据库仍在运行并执行insert或update时归档数据库数据目录...但我认为这个问题以同样的方式应用于这两种方法。
命名卷可以在/var/lib/docker 之外存储数据。 例如，您可以使用以下方法创建命名绑定挂载：
$ docker volume create --driver local
--opt type=none
--opt device=/home/user/test
--opt o=bind
test_vol
或者这是 NFS 挂载的一个：
$ docker volume create --driver local
--opt type=nfs
--opt o=nfsvers=4,addr=nfs.example.com,rw
--opt device=:/path/to/dir
foo
在这些情况下，tar 备份以与容器相同的方式访问数据，因此无论命名卷的创建方式如何，都会执行备份。它还有效地将数据导出为通用格式，该格式不仅可以由其他容器使用，还可以由您碰巧移动应用程序的任何地方使用。
如果您发现自己需要对卷内容进行更多控制，以便进行更直接的备份，则命名绑定装载是命名卷和主机装载之间的中间点。您可以将目录视为容器的命名卷，但包含的数据只是主机上要备份的另一个目录。
就个人而言，我倾向于将/var/lib/docker 视为一个黑匣子。虽然内容非常可读，但 docker 可以在版本之间自由迁移和更改内容，而用户使用的 API 应该保持一致。如果它们过渡到容器映像管理之类的东西，我需要更改的内容越少越好。
实际上，这是一种模式：仅数据容器。
这个想法是让一些 docker 镜像只专用于存储，而其他只用于应用程序。注意数据的物理存储位置是一个陷阱。
您只需要知道您的数据是否正确存储在 Docker 化的基础架构中。不在哪里。并使用 Docker 创建数据的转储。不直接cp也不tar命令。
编辑
当 Docker 卷不完全正常时，仅数据容器是一种有用的模式。但是这个想法保持不变(在这种基础设施中，你不应该注意数据的存储位置(。
请参阅以以下内容开头的 Docker 卷：
卷是持久保存数据的首选机制...
只要您意识到后果并愿意通过依赖系统内部来承担风险，就没问题。但是，当有一种记录在案的方法来实现不那么复杂的相同操作时，您为什么要冒这个风险呢？
如果我是你，我会使用记录在案的方法随着产品的发展来逃避维护周期。
如果 Docker 决定更改挂载点位置或将其作为可配置选项提供，则未记录的备份数据方法将失败。