【问题标题】:Docker data safetyDocker 数据安全
【发布时间】:2017-06-09 19:47:42
【问题描述】:

我今天有一个悲伤的故事。 我丢失了自星期六以来所做的所有数据库更改。

我们使用 mongodb (3.4.1),在这种特殊情况下,它在带有映射卷的官方 docker 容器中运行。

容器是用 docker-compose 创建的,docker-compose.yml 看起来像这样:

version: "2"
services:
        database:
            image: mongo:3.4.1
            restart: always
            container_name: cvs-db
            volumes:
              - ~/data/db:/data/db
            ports:
              - "27017:27017"

~/data/db 只是一个很久以前创建的普通文件夹。

在我重新启动容器(使用docker-compose up -d)后,数据恢复到两天前的状态。甚至删除也消失了。

我们昨天清理了所有集合并开始用真实数据填充它们,现在它包含我们最近删除的所有测试数据。

所以,我的问题是: 1)如何保护mongodb数据免受此类灾难? 2)有人能说出可能导致这些结果的确切条件吗? 3) 如何恢复数据?

编辑:经过一些研究,我认为这是 docker-compose 错误。 但问题仍然有效:)

【问题讨论】:

  • 您能详细说明“映射卷”这个术语吗?您究竟是如何创建/附加此卷的?在 Docker 中有多种方法可以创建卷,每种方法都有不同的行为/限制/风险。
  • 我使用了 docker-compose: volumes: - ~/data/db:/data/db
  • 这并不能真正告诉我们任何事情,请编辑问题并提供有关如何映射或创建卷的更多详细信息。
  • 你以为不是mongodb? docker 可以将我的卷回滚到以前的状态吗?
  • 我添加了一些细节

标签: mongodb docker docker-compose recovery


【解决方案1】:

查看您的撰写文件,您将源目录引用为相对~/data/db。如果您在系统上有多个用户帐户可以访问该撰写文件(即 root 加上一个命名用户帐户),那么 "~/data/db" 目录会有所不同取决于哪个用户运行 compose启动容器。也许你的环境中发生过类似的事情。

您最好使用主机卷的绝对路径(即/opt/data/db:/data/db),而不是可以根据用户或父目录上下文更改的路径,以避免出现此类问题的可能性。

使用标准主机目录作为数据卷不应导致数据自发回滚。如果不是上面提到的目录上下文的问题,那么它可能涉及其他一些因素,例如有人恢复文件系统快照、恢复备份或直接更改数据库。

【讨论】:

  • 哦,谢谢!你说得对!依赖于用户的路径是我的错……我几乎开始相信魔法……
  • 太棒了。很高兴你把它整理好了!
猜你喜欢
  • 2020-01-30
  • 1970-01-01
  • 1970-01-01
  • 2022-11-07
  • 1970-01-01
  • 2015-05-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多