备份 docker 卷 - 很简单 tar- 归档还不够吗?

Backup docker volumes - is simple tar-archiving not sufficient?

我在三台机器上运行几个Docker容器,组成一个Swarm集群。

一些存储持久数据的容器(如 DB、Redis 等)使用数据卷。 (我尽量避免使用 bind-mount)

此类数据卷位于/var/lib/docker/volumes/,每个卷都分配了自定义名称而不是随机序列ID:

# ls /var/lib/docker/volumes/
redis-data   postgres-data   fluentd-data ...

我想定期备份这些卷,例如每天,以便在发生机器故障时恢复并在以后修复。

然而,我在 google 中找到的每个文档都说明了使用新 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

P.S.

使用tar备份可能会出现归档时由于数据变化导致数据不一致的情况。例如,当 DB 仍然是 运行 并且执行 inserts 或 updates 时归档 DB 数据目录......但我认为这个问题以相同的方式应用于两种方法。

其实这是一种模式:Data only container。

想法是让一些 docker 图像仅专用于存储,而其他图像仅用于应用程序。注意数据的物理存储位置是一个陷阱。

您只需要知道您的数据已正确存储在 Docker 化的基础架构中。不是哪里。并使用 Docker 创建数据转储。不是 cp 也不是 tar 直接命令。

编辑

当 Docker 卷不完全正常时,仅数据容器 一种有用的模式。但思路还是一样的(在这种基础设施中,你不应该关心数据存储在哪里)。

查看 Docker Volumes 开头:

Volumes are the preferred mechanism for persisting data ...

只要您意识到后果并愿意根据系统内部结构承担风险,就没有问题。但是,当有记录在案的方法可以以不太复杂的方式实现相同的操作时,您为什么要冒这个风险呢?

如果我是你,随着产品的发展,我会使用记录的方法来逃避维护周期。

如果 Docker 决定更改挂载点位置或将其作为可配置选项提供,那么您未记录的备份数据方法将失败。

命名卷可以存储 /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 应该保持更加一致。如果他们过渡到 containerd 图像管理之类的东西,我需要更改的东西越少越好。