Резервное копирование томов док-станции - простого tar-архивирования недостаточно? - PullRequest
Новая
       6

Резервное копирование томов док-станции - простого tar-архивирования недостаточно?

0 голосов
/ 29 мая 2018

Я использую несколько контейнеров Docker на трех машинах, составляющих кластер Swarm.

Некоторые контейнеры, в которых хранятся постоянные данные (например, DB, Redis и т. Д.), Используют тома данных.(Я старался по возможности избегать использования bind-mount)

Такие тома данных находятся в / var / lib / docker / volume /, и каждому тому присваивается индивидуальное имя, а не случайная последовательность.Идентификатор: 

# 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

PS

В некоторых случаях резервное копирование с использованием tar может привести к несогласованности данных из-за изменений данных во время архивирования.,Например, архивирование каталога данных БД, когда БД еще работает и выполняется insert с или update с ... Но я думаю, что эта проблема применяется к обоим подходам одинаково.

Ответы [ 3 ]

0 голосов
/ 12 марта 2019

Нет проблем, если вы осведомлены о последствиях и готовы рисковать, полагаясь на внутренние компоненты системы.Но почему вы хотите пойти на такой риск, когда есть документированный подход к выполнению той же операции без особых сложностей?

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

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

0 голосов
/ 12 марта 2019

Именованный том может хранить данные вне / 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 обращается к данным так же, как вашКонтейнер делает, и, следовательно, выполняет резервное копирование независимо от того, как был назван том.Он также эффективно экспортирует данные в общий формат, который может использоваться не только другими контейнерами, но и в любом месте, куда вы перемещаете свое приложение.

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

Лично я склонен рассматривать / var / lib / docker как черный ящик,Несмотря на то, что содержимое легко читаемо, Docker может свободно перемещаться и изменять информацию между версиями, в то время как API, используемый пользователями, должен оставаться более согласованным.Чем меньше вещей мне нужно изменить, если они перейдут к чему-то вроде управления контейнерами изображений, тем лучше.

0 голосов
/ 05 июля 2018

На самом деле это шаблон: контейнер только для данных.

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

Вы просто должны знать, что ваши данные правильно хранятся в Dockerized инфраструктуре.Не где.И используйте Docker для создания дампа ваших данных.Команды не cp и tar напрямую.

РЕДАКТИРОВАТЬ

Контейнер только для данных был полезным шаблоном, когда тома Docker не былиполностью ок.Но идея остается той же (в такой инфраструктуре вам не нужно заботиться о том, где хранятся данные).

см. тома Docker начиная с:

Тома являются предпочтительным механизмом для сохранения данных ...

...