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

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

Тома, bind-mount и tmpfs

Данные внутри контейнера эфемерны: docker rm — и всё стёрто. Docker предлагает три способа сохранить данные снаружи:

• Named volumes — управляются Docker, лежат в /var/lib/docker/volumes/. Лучший выбор для баз данных
• Bind-mount — вы монтируете конкретную папку хоста в контейнер. Удобно для конфигов и исходников
• tmpfs — данные в оперативке, исчезают при остановке. Для временных секретов

Создаём и осматриваем том:

docker volume create pgdata
docker volume inspect pgdata

Named volume — предпочтительный выбор для данных в большинстве случаев. Docker сам управляет его жизненным циклом, правильно выставляет права, а сам том не привязан к структуре папок хоста. Bind-mount же прозрачнее для разработки: вы видите файлы прямо в своей файловой системе и можете править их редактором. tmpfs пригодится, когда данные не должны попадать на диск вообще — например, временные ключи или кэш, который не жалко потерять при рестарте.

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

Классический пример — база с постоянным хранилищем:

docker run -d --name db \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  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
docker volume prune

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

Named volume нельзя просто скопировать — он внутри Docker. Приём: запускаем временный контейнер, монтируем в него том и пакуем в tar на хост.

docker run --rm \
  -v pgdata:/data:ro \
  -v $(pwd):/backup \
  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
docker run --rm \
  -v pgdata_new:/data \
  -v $(pwd):/backup \
  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, и отказ диска, и потерю доступа к самому серверу.

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