#Что означает ошибка и при каких условиях возникает
Пошаговая проверка, куда приложение пишет файлы, какой том подключён и почему после docker compose up отображается пустая база или каталог. Именованный том обычно сохраняется при пересоздании контейнера, но не при удалении тома; новая папка проекта, смена имени тома или неверный путь внутри контейнера создают ощущение потери данных.
#Как различить причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Данные записывались не в смонтированный путьПриложение пишет в /app/data, а том указан как /data. | После пересоздания новый контейнер пуст, хотя именованный том существует. | Сопоставить каталог сохранения приложения и назначение Mounts. |
| Изменилось имя Compose-проектаCompose добавляет префикс проекта к имени обычного именованного тома. | Появился новый том с похожим именем после переименования папки проекта. | Определить проект и сопоставить прежний и новый том. |
| Использовали down -v или удаление томаОперация явно удалила именованный том и его данные. | Том отсутствует в docker volume ls; старые данные не находятся обычным просмотром. | Не создавать ложную надежду: искать отдельную резервную копию. |
| Привязана папка хоста, а не Docker volumeЗапись вида ./data:/data означает bind mount; относительная папка зависит от каталога Compose-файла. | Данные находятся в другой директории хоста; в docker volume ls соответствующего тома нет. | Проверить фактический Source в Mounts. |
#Пошаговая диагностика и исправление
- Остановите изменения до выяснения местоположения данныхЕсли это настоящая база или важные пользовательские файлы, не запускайте
down -v,volume prune,system prune --volumesи не создавайте пустую базу на месте возможных данных. Сделайте резервные копии compose.yaml, файлов настроек и доступных файлов базы штатным способом самой СУБД. Откройте терминал в каталоге проекта; в Windows/macOS он доступен через поиск «Терминал», в Linux — через меню приложений. - Найдите название сервиса и текущий контейнерВ папке compose.yaml запустите
docker compose ps -aиdocker compose config --volumes. Первое выводит существующие контейнеры проекта, второе — логические имена томов. Найдите сервис, который сохраняет данные, и запишите его имя. Если проект в другой директории, перейдите к нужному compose.yaml; иначе будете исследовать не тот набор контейнеров. - Проверьте реальный путь монтированияВыполните
docker compose ps -q app, где app — имя сервиса, и возьмите идентификатор. Затем выполнитеdocker inspect --format "{{json .Mounts}}" ИДЕНТИФИКАТОР; замените слово ИДЕНТИФИКАТОР. В выводе проверьте Type (volumeилиbind), Name/Source и Destination. Если программа пишет не в Destination, пересоздание не сохранит такие записи. При невозможности прочитать вывод передайте специалисту обезличенные имена и пути. - Уточните каталог, где приложение фактически хранит данныеОткройте конфигурацию конкретной программы и найдите её путь для данных; для PostgreSQL это обычно PGDATA, для других сервисов каталог отличается. Не считайте, что наличие volumes в YAML автоматически защищает базу. Сопоставьте путь из программы и Destination. Если не совпадают, сначала остановите запись по плану обслуживания, сделайте логическую резервную копию БД, а уже после переносите данные согласованной процедурой.
- Проверьте, не сменилось ли имя проектаВыполните
docker volume lsи сравните похожие имена видастарыйпроект_app-dataиновыйпроект_app-data. Для Compose имя проекта меняется при смене имени рабочей папки, флага-p, COMPOSE_PROJECT_NAME или параметраname:. Если старый том существует, не удаляйте его. Укажите постоянное имя проекта либо явное имя тома только после проверки назначения и сохранения данных. - Исправьте конфигурацию без удаления существующего томаДля простого локального приложения используйте один том с постоянным логическим именем и правильным каталогом внутри контейнера (пример ниже). Проверьте
docker compose config -q. Перед применением к реальному проекту сохраните оригинальный YAML; при ошибке восстановления верните исходный вариант. Изменения привязки в работающей базе требуют согласованной остановки и штатного копирования, а не ручного перемещения файлов БД на ходу. - Проверьте сохранение на безопасном тестовом сервисеВ отдельной пустой папке создайте compose.yaml из примера. Откройте терминал в этой папке, выполните
docker compose up -d, затемdocker compose exec demo cat /state/check.txt. Запомните дату в файле. Выполнитеdocker compose up -d --force-recreate, снова прочтите файл: дата должна остаться прежней. Если она изменилась, сравните имена проектов и монтирования;down -vдля этого теста не требуется. - Когда старый том исчез, ищите резервные копииЕсли
docker volume lsне показывает прежний том, а вы ранее выполнялиdocker compose down -v, сначала проверьте отдельные резервные копии и снимки хранилища с администратором. Docker не предоставляет штатной команды «отменить удаление тома». Не запускайте восстановление с записью поверх доступных данных до проверки целостности копии. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Минимальный пример для отдельного тестового проекта
Текст
Создайте в пустой тестовой папке файл compose.yaml. /state — путь записи теста; app-state — именованный том Compose. Для реального приложения путь должен совпадать с его настройками.
services:
demo:
image: alpine:3.20
command: ["sh", "-c", "test -f /state/check.txt || date > /state/check.txt; sleep 3600"]
volumes:
- app-state:/state
volumes:
app-state:#Как проверить результат и что делать, если проблема осталась
Проверка пройдена, если тестовый файл сохраняет содержимое после пересоздания и в docker inspect виден нужный том у правильного пути. Если реальное приложение по-прежнему пустое, не переключайте том наугад: сопоставьте имя проекта, конфигурацию приложения, Mounts и резервные копии.