MAATRIX / Блог / Docker Volumes и бэкап данных контейнеров

Docker Volumes и бэкап данных контейнеров

Блог MAATRIX · 2026-07-07

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

Содержание

  1. Тома, bind-mount и tmpfs
  2. Подключение тома к контейнеру
  3. Бэкап тома в архив
  4. Восстановление из бэкапа
  5. Автоматизация и два уровня защиты

Тома, bind-mount и tmpfs

['Данные внутри контейнера эфемерны: docker rm — и всё стёрто. Docker предлагает три способа сохранить данные снаружи:', '
  • Named volumes — управляются Docker, лежат в /var/lib/docker/volumes/. Лучший выбор для баз данных
  • Bind-mount — вы монтируете конкретную папку хоста в контейнер. Удобно для конфигов и исходников
  • tmpfs — данные в оперативке, исчезают при остановке. Для временных секретов
', 'Создаём и осматриваем том:', '
docker volume create pgdata\ndocker volume inspect pgdata
', 'Named volume — предпочтительный выбор для данных в большинстве случаев. Docker сам управляет его жизненным циклом, правильно выставляет права, а сам том не привязан к структуре папок хоста. Bind-mount же прозрачнее для разработки: вы видите файлы прямо в своей файловой системе и можете править их редактором. tmpfs пригодится, когда данные не должны попадать на диск вообще — например, временные ключи или кэш, который не жалко потерять при рестарте.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS с бэкапами

Подключение тома к контейнеру

['Классический пример — база с постоянным хранилищем:', '
docker run -d --name db \\\n  -e POSTGRES_PASSWORD=secret \\\n  -v pgdata:/var/lib/postgresql/data \\\n  postgres:16-alpine
', 'Теперь контейнер можно смело удалять и пересоздавать — том pgdata с данными остаётся. Bind-mount для конфига пишется через путь хоста:', '
docker run -d -v /etc/myapp/config.yml:/app/config.yml:ro myapp
', 'Суффикс :ro монтирует только для чтения — контейнер не сможет изменить ваш конфиг.', 'Полезно уметь заглянуть в том, не запуская основное приложение. Временный контейнер с alpine покажет содержимое:', '
docker run --rm -v pgdata:/data alpine ls -la /data
', 'А список всех томов и очистка неиспользуемых (осторожно, удаляет данные без привязок):', '
docker volume ls\ndocker volume prune
']

Бэкап тома в архив

['Named volume нельзя просто скопировать — он внутри Docker. Приём: запускаем временный контейнер, монтируем в него том и пакуем в tar на хост.', '
docker run --rm \\\n  -v pgdata:/data:ro \\\n  -v $(pwd):/backup \\\n  alpine tar czf /backup/pgdata-$(date +%F).tar.gz -C /data .
', 'В текущей папке появится архив с датой. Для баз данных надёжнее делать логический дамп на живой БД:', '
docker exec db pg_dump -U postgres app | gzip > app-$(date +%F).sql.gz
', 'Дамп через pg_dump гарантирует согласованность, тогда как копирование файлов работающей базы может поймать её в промежуточном состоянии.']

Восстановление из бэкапа

['Разворачиваем архив тома обратно — создаём пустой том и распаковываем в него:', '
docker volume create pgdata_new\ndocker run --rm \\\n  -v pgdata_new:/data \\\n  -v $(pwd):/backup \\\n  alpine sh -c "tar xzf /backup/pgdata-2026-07-09.tar.gz -C /data"
', 'Восстановление SQL-дампа в чистую базу:', '
gunzip -c app-2026-07-09.sql.gz | docker exec -i db psql -U postgres app
', 'Золотое правило: бэкап, который вы ни разу не восстанавливали, — это не бэкап, а надежда. Проверяйте восстановление на тестовом контейнере.']

Автоматизация и два уровня защиты

['Простой cron-бэкап тома раз в сутки в 3 ночи:', '
0 3 * * * cd /opt/backups && docker run --rm -v pgdata:/data:ro -v /opt/backups:/backup alpine tar czf /backup/pgdata-$(date +\\%F).tar.gz -C /data .
', 'Держите два уровня: логические дампы своих данных + резервные копии всего сервера. VPS MAATRIX делает ежедневные бэкапы на стороне провайдера — это ваша страховка на случай, если что-то случится с самим сервером, а не только с одним томом.', 'Не забывайте увозить архивы за пределы VPS: копия на том же диске не спасёт при отказе диска. Отправляйте tar на объектное хранилище или второй сервер.', 'Полезно соблюдать правило 3-2-1: три копии данных, на двух разных носителях, одна из них — вне сервера. На практике это означает: живой том на VPS, локальный дамп по cron и выгрузка архива на удалённое хранилище или второй VPS в другой локации MAATRIX. Такая схема переживает и случайное docker compose down -v, и отказ диска, и потерю доступа к самому серверу.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS с бэкапами

Частые вопросы

Named volume или bind-mount для базы данных?

Для БД — named volume: Docker управляет им, права настраиваются корректно. Bind-mount лучше для конфигов и кода, которые вы правите с хоста.

Можно ли бэкапить том без остановки контейнера?

Для файлов — да, но для баз надёжнее логический дамп (pg_dump, mysqldump) на живой БД либо короткая остановка перед tar.

Зачем бэкап, если у MAATRIX ежедневные бэкапы?

Бэкапы провайдера спасают весь сервер, а свои дампы дают точечное восстановление конкретной таблицы или базы. Держите оба уровня.

Читайте также