Правильный способ остановки docker контейнеров для бэкапа и последующий запуск

Гарантирует ли последующая команда старта докер сервиса запуск именно тех контейнеров, которые были остановлены ранее?

Если там restart: always или unless-stopped то по идее запустятся, но я бы особо не полагался, если у тебя композы с зависимостями между контейнерами, то что-то может и не стартануть. Зависит от приложения и композов.

В общем виде надо дергать отдельные скрипты под каждое приложение.

Когда контейнеров уже более 10, то пора б задуматься об оркестрации этого чуда.

Правильно ли будет перед началом бэкапа остановить сервис докера для обеспечение целостности и точности файлов в бэкапе?

Сам сервис в смысле системного демона останавливать не вижу смысла, достаточно просто остановить контейнеры, которым это необходимо.

Это уже зависит от самого сервиса, работающего в контейнере. Например, если у тебя postgres, то лучше снять дампы с самого postgres’а (и останавливать не нужно). Или сервис, который ничего не пишет, а только читает (nginx, раздающий статику, например) - тоже стопать не нужно. Если же что-то явно пишет (например, свой репозиторий типа nexus’а), то лучше, конечно, остановить, забэкапить и запустить снова.

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

а чем это можно оркестрировать? знаю, что в ansible есть модули докера и композы

Все данные у меня не в вольюмах, а в забинденых директориях. Мне так проще и понятнее.

Но почему? Можешь подробнее рассказать?

В данном случае именно compose выступает в качестве оркестратора. Для одного хоста писать плейбук смысла особого нет. Достаточно бекапить конфиги и данные.

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

btrfs начни использовать - решит многие проблемы… можно в raid-1

Kubernetes

ZFS с COW

Почти к каждому сервису есть какая-то БД. mariadb, postgre, couchdb и т. д. Я понимаю, что ваш способ правильный, но он, скажем так, для меня и в моей ситуации нежелательный. Не прод все же, обычный домашний сервер. А так, у меня все контейнеры на docker compose. Им и управляю.

Во-первых, доп. уровень абстракции. Усложнение. Не знаю, насколько с тех. точки зрения сильное, но все же. Во-вторых, я периодически бэкапы проверяю и мне куда проще сходу запустить, скажем, проверку хешей файлов, которые используются в контейнерах и которыми я дорожу, чем поднимать на другом сервере или с другого диска еще один докер контейнер, чтобы задействовать вольюм, разбираться, как проверять там, как это все автоматизировать. В целом, избегаю ненужной для меня работы.

Это для того, чтобы гарантированно остановить все контейнеры разом. Моя собственная идея. Советуюсь, насколько имеет смысл, чтобы не связываться с каждым контейнером по отдельности, особенно в условиях, когда в один день у меня активных контейнеров 10, а в другой 15.

Для меня непрактично.

Это для того, чтобы гарантированно остановить все контейнеры разом.

docker compose stop — ваш друг!

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

Нужно ещё убедиться что live restore выключен, иначе контейнеры продолжат работать.

И как-то противоречиво звучит, то мне нужно 10 бэкапов, то 15, я и сам не знаю. И я хочу сэкономить усилия и грохать целиком демон чтобы не заморачиваться. Качество бэкапов будет соответствующее. Не так сложно дать требующим бэкап контейнерам имя, и проходить только по ним.