Резервная копия Docker volumes: как скачать и проверить восстановление

Docker volume сохраняет данные при замене контейнера, но не защищает их от удаления volume, поломки диска или потери VPS. Резервная копия — отдельный набор данных, который можно скачать с сервера и восстановить без доступа к исходному volume. Для базы данных важна ещё и согласованность: связанные файлы должны описывать один момент времени.

Сначала найдите данные и их владельца

Откройте каталог Compose-проекта на VPS и посмотрите сервисы, volumes и точки подключения. Эти команды ничего не останавливают:

docker compose ps
docker compose config --volumes
docker volume ls
docker inspect "$(docker compose ps -q db)" \
  --format '{{json .Mounts}}'

В последней команде db — имя сервиса базы из compose.yaml; замените его фактическим именем. В выводе Mounts найдите тип volume, его имя и путь Destination внутри контейнера. Не делайте вывод по похожему имени: один сервер может хранить volumes нескольких проектов.

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

Выберите способ, который сохраняет согласованность

Для обычного каталога с изображениями или документами подходит файловый архив, если приложение не меняет файлы во время копирования либо вы заранее остановили запись. Для PostgreSQL, MariaDB и других СУБД используйте штатный логический экспорт. Простое архивирование работающего каталога базы может собрать страницы данных из разных моментов.

Если сервис допускает остановку, выполните её только для конкретного производителя данных, убедитесь, что процесс остановлен, создайте архив и затем сразу запустите сервис. Не применяйте docker compose down -v: параметр -v удаляет данные, которые вы пытаетесь сохранить.

Создайте архив файлового volume

Сначала подготовьте на VPS каталог, доступный только администратору. Команда install создаёт его с правами 0700, если каталога ещё нет:

sudo install -d -m 0700 -o "$USER" -g "$(id -gn)" /srv/backups/manual

Убедитесь, что /srv/backups/manual находится на файловой системе с достаточным свободным местом. Затем подключите volume только для чтения к временному Alpine-контейнеру и запишите архив в каталог хоста:

docker run --rm \
  --mount type=volume,src=app-data,dst=/source,readonly \
  --mount type=bind,src=/srv/backups/manual,dst=/backup \
  alpine:3.22 \
  tar -C /source -czf /backup/app-data-20260905.tar.gz .

Замените app-data точным именем из docker inspect, а дату в имени — фактической датой создания копии. Временный контейнер читает /source, создаёт gzip-архив и удаляется после выхода. Рабочий volume не изменяется.

Проверьте архив на VPS до скачивания. Первая команда тестирует структуру gzip/tar, вторая считает контрольную сумму SHA-256:

tar -tzf /srv/backups/manual/app-data-20260905.tar.gz >/dev/null
sha256sum /srv/backups/manual/app-data-20260905.tar.gz

Сохраните выведенную сумму рядом с локальной копией. Успешное чтение списка ещё не доказывает правильность данных приложения, но обнаруживает повреждённый архив до передачи.

Для базы используйте её команду экспорта

На примере PostgreSQL логический экспорт создаётся утилитой pg_dump внутри контейнера базы. Имя базы и пользователя берутся из конфигурации проекта; пароль не передавайте аргументом командной строки:

docker compose exec -T db \
  pg_dump --format=custom --no-owner --no-privileges \
  --username=app appdb \
  > /srv/backups/manual/appdb-20260905.dump

-T отключает псевдотерминал, чтобы бинарный поток не исказился. Формат custom предназначен для pg_restore, а параметры владельца и привилегий упрощают восстановление в отдельную тестовую базу. Замените db, app и appdb реальными значениями.

Если PostgreSQL требует пароль, используйте механизм проекта: файл .pgpass, Docker secret или временную переменную окружения с ограниченным доступом. Не вставляйте пароль прямо в статью, историю shell или имя файла.

Проверьте, что dump распознаётся и содержит оглавление объектов:

pg_restore --list /srv/backups/manual/appdb-20260905.dump | head -n 30
sha256sum /srv/backups/manual/appdb-20260905.dump

Утилита pg_restore должна быть совместима с форматом созданной копии. Если на хосте её нет, выполните проверку в отдельном контейнере той же основной версии PostgreSQL, не подключая рабочий volume на запись.

Скачайте копию на локальный компьютер

Следующая команда выполняется на вашем компьютере, а не на VPS. Она скачивает конкретный файл по SSH в заранее созданный локальный каталог; замените пользователя, адрес и имя файла:

scp backup-user@SERVER_IP:/srv/backups/manual/appdb-20260905.dump \
  ./server-backups/appdb-20260905.dump

После передачи вычислите SHA-256 локального файла и сравните строку с суммой на VPS. Для PowerShell используйте Get-FileHash, для Linux и macOS — sha256sum или shasum -a 256. Несовпадение означает, что эту копию нельзя считать готовой.

После подтверждения локальной копии серверный архив можно удалить вручную, если он больше не нужен и место ограничено. Удаляйте только точный проверенный путь, а не весь /srv/backups по шаблону.

Восстановите файлы в отдельный volume

Создайте тестовый volume с новым именем и распакуйте в него файловый архив. Рабочий app-data в этих командах не подключается:

docker volume create app-data-restore-test
docker run --rm \
  --mount type=volume,src=app-data-restore-test,dst=/restore \
  --mount type=bind,src=/srv/backups/manual,dst=/backup,readonly \
  alpine:3.22 \
  tar -C /restore -xzf /backup/app-data-20260905.tar.gz

docker run --rm \
  --mount type=volume,src=app-data-restore-test,dst=/data,readonly \
  alpine:3.22 find /data -maxdepth 3 -type f

Проверьте ожидаемые файлы, их владельцев и возможность чтения приложением. Для окончательной проверки запустите отдельный тестовый контейнер, направленный только на app-data-restore-test, и выполните прикладной сценарий без доступа к рабочей сети.

Восстановите базу отдельно от рабочей

Создайте пустую тестовую базу в отдельном экземпляре PostgreSQL и примените к ней pg_restore. Точные команды создания пользователя и базы зависят от проекта. После восстановления проверьте число ключевых записей, ограничения, расширения и вход через тестовую копию приложения.

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

Завершите проверку без потери данных

Когда тест окончен, сначала остановите тестовое приложение и убедитесь, что volume не подключён. Затем удалите только тестовый volume:

docker ps -a --filter volume=app-data-restore-test
docker volume rm app-data-restore-test

Если первая команда показывает контейнер, выясните его назначение и удалите связь до volume rm. Рабочий volume не должен фигурировать ни в одной команде очистки.

В журнал копии запишите дату, источник, имя volume или базы, версию приложения и СУБД, размер, контрольную сумму, место локального хранения и результат восстановления. Такой журнал не содержит пароль, но позволяет выбрать пригодную копию во время сбоя.

Различия между volume и каталогом хоста объяснены в базовом уроке о хранении. Перед миграцией используйте порядок из руководства по обновлению Compose, а состояние VPS проверяйте по ручному плану мониторинга и копирования.

Источники

• Docker volumes
• Docker bind mounts
• PostgreSQL: pg_dump
• PostgreSQL: pg_restore
• OpenSSH scp manual