Читать полный материал
Том Docker хранит данные независимо от записываемого слоя контейнера, а bind mount подключает путь файловой системы хоста. Ни один из этих способов сам по себе не создаёт резервную копию: сохранность после пересоздания контейнера и восстановление после потери данных — разные задачи.
Где могут находиться данные приложения
Прежде чем переносить сервис, перечислите базы, загруженные файлы и конфигурацию. Для каждого пути установите, находится ли он в слое контейнера, в томе либо в подключённом каталоге хоста. Название образа не отвечает на этот вопрос. docker container inspect показывает подробную конфигурацию контейнера; результаты проверки следует сопоставлять с путями, которые реально использует приложение.
Когда выбирать том, а когда bind mount
Тома создаёт и обслуживает Docker. Они удобны, когда приложению нужно постоянное хранилище без привязки к вручную выбранному каталогу хоста. Bind mount полезен, если контейнер должен работать с определёнными файлами на хосте, например конфигурацией или результатами сборки.
При bind mount права контейнера затрагивают подключённые файлы хоста. Если запись не требуется, предусмотрите подключение только для чтения. Этот режим ограничивает конкретное подключение, но не заменяет общую настройку прав приложения.
Почему сохранённый том — ещё не backup
Том может пережить удаление контейнера, но ошибка приложения способна повредить данные в нём. Нужна отдельная копия и понятный порядок возврата сервиса. Состав копии должен соответствовать приложению: одного архива файлов может оказаться недостаточно для работающей базы.
Например, документация PostgreSQL объясняет, почему обычное копирование файлов запущенной БД не даёт надёжной файловой копии. Для своей версии СУБД выбирают поддерживаемый метод резервирования и условия согласованности. Универсальную команду архивирования тома нельзя выдавать за проверенный backup любой базы.
Как проверить восстановление
В изолированной среде восстановите данные, запустите приложение с совместимой конфигурацией и проверьте его содержательное действие: чтение нужной записи или открытие загруженного файла. Один успешный старт контейнера не доказывает, что восстановлены именно требуемые данные.
Запишите, какие файлы и конфигурация использовались, какую версию приложения проверяли и какой результат получили. Учётные данные в такой отчёт не включают. Общая методика приведена в материале о резервных копиях по правилу 3–2–1.
Когда не нужен отдельный сервер хранения
Тестовому сервису с воспроизводимыми данными может быть достаточно существующей инфраструктуры. Отдельную систему хранения выбирают, когда есть подтверждённые требования к объёму, доступности или размещению копий. Сначала опишите эти требования, затем сравнивайте системы хранения данных. Новый диск без процедуры восстановления не решает задачу backup.
Частые вопросы
Можно ли хранить данные только внутри контейнера?
Это возможно технически, но записываемый слой связан с жизненным циклом контейнера. Для важных изменяемых данных заранее определяют постоянное хранилище и резервирование.
Том удаляется вместе с контейнером?
Поведение зависит от типа тома и операции удаления. Документация Docker отдельно описывает именованные и анонимные тома; перед удалением проверяют конкретную конфигурацию.
Достаточно скопировать каталог работающей базы?
Не всегда. У СУБД есть собственные требования к согласованности; используйте метод из документации её версии и проверяйте восстановление.
Источники
Материал подготовлен при участии ИИ по официальной документации. Собственные испытания не заявлены. Факты сверены 29 октября 2026 года.