备份 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 仍然是 运行 并且执行 insert
s 或 update
s 时归档 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 图像管理之类的东西,我需要更改的东西越少越好。
我在三台机器上运行几个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 仍然是 运行 并且执行 insert
s 或 update
s 时归档 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 图像管理之类的东西,我需要更改的东西越少越好。