Безопасность данных докеров

Question

У меня сегодня печальная история. Я потерял все мои изменения в базе данных, которые я сделал с субботы.

Мы используем mongodb (3.4.1), и в этом конкретном случае он работал внутри своего официального контейнера докеров с отображаемым объемом.

Контейнер был создан с Докером-композом, 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) как восстановить данные?

EDIT: после некоторых исследований, я думаю, что это была ошибка, связанная с докером. Но все вопросы по-прежнему актуальны :)

Answer 1

Глядя на ваш файл компоновки, вы ссылаетесь на исходный каталог как относительный ~/data/db. Если у вас есть несколько учетных записей пользователей в системе, которые могут получить доступ к этому составному файлу (то есть root плюс именованная учетная запись пользователя), то каталог "~/data/db" будет отличаться от , в зависимости от того, какой пользователь выполнил команду, чтобы запустить контейнер. Возможно, что-то подобное произошло в вашей среде.

Вам лучше использовать абсолютный путь к тому хоста (то есть /opt/data/db:/data/db), а не что-то, что может измениться в зависимости от контекста пользователя или родительского каталога, чтобы избежать возможности такого типа проблем.

Использование стандартного каталога хоста в качестве тома данных не должно приводить к самопроизвольному откату данных. Если это не проблема с контекстом каталога, о котором говорилось выше, то, возможно, существует и другой фактор, связанный с отказом от моментального снимка файловой системы, непосредственным восстановлением резервной копии или изменением базы данных.