执行docker-compose down未加-v参数后Postgres数据丢失问题咨询

操作流程与异常现象：

• 配置修改：调整pg_hba.conf，将原配置项host all all all scram-sha-256替换为host all all all md5
• 容器重启：先后执行docker-compose down、docker-compose up -d重启服务，全程未执行带-v参数的down命令
• 异常结果：容器启动后PostgreSQL数据全部丢失，执行docker volume ls返回空结果
• 问题涉及的docker-compose配置片段：

db:
  image: postgres
  container_name: postgres
  restart: always
  environment:
    POSTGRES_DB: postgres
    POSTGRES_USER: polardb
    POSTGRES_PASSWORD: 123456
  ports:
    - 5432:5432
  volumes:
    - /opt/deploy/postgres/data:/var/lib/postgresql/data

首先明确一个基础认知：你配置的是宿主机目录绑定挂载（bind mount），不属于Docker daemon管理的卷范畴，docker volume ls本身就查不到这个挂载点，返回空是正常现象，和数据丢失没有直接关联。
按以下优先级排查：

• 第一步：直接检查宿主机挂载目录状态
  执行ls -la /opt/deploy/postgres/data查看目录下的文件是否存在。正常PostgreSQL数据目录下会有PG_VERSION、base、pg_wal、pg_hba.conf等文件/文件夹，如果目录为空，说明数据是在宿主机层面被清空，和Docker卷操作无关。
• 第二步：查容器启动日志确认触发逻辑
  执行docker logs postgres查看启动输出，重点检索initdb关键字。如果日志中出现initdb执行记录，说明容器启动时判定挂载的/var/lib/postgresql/data目录为空/不可用，自动触发了数据库初始化流程，生成了全新的空数据库，这是这类场景下数据“丢失”的最常见原因。
• 第三步：排查目录权限问题
  PostgreSQL官方镜像内服务进程的运行UID为999，需要对挂载的数据目录有完整读写权限。执行ls -n /opt/deploy/postgres查看目录属主UID，如果不是999，容器启动时会无法读取原有数据，进而触发空目录初始化逻辑，部分版本镜像在权限异常时还会主动清空目录内容。权限异常时执行chown -R 999:999 /opt/deploy/postgres/data修正即可。
• 第四步：回溯配置修改路径
  确认你修改pg_hba.conf时，修改的是宿主机/opt/deploy/postgres/data/pg_hba.conf文件，还是进入运行中容器修改的容器内部路径的文件。如果是后者，docker-compose down会删除容器实例，容器内部未持久化的修改会直接丢失，但不会影响宿主机挂载目录的存量数据，除非你修改配置时误操作删除了数据目录内的文件。
• 第五步：排查宿主机侧清理逻辑
  检查宿主机是否配置了目录清理定时任务、磁盘自动清理策略，或者是否有其他运维操作误删除了/opt/deploy/postgres/data下的文件。

如果检查发现宿主机数据目录下还留存旧的数据库文件，立刻停止当前PostgreSQL容器，先把整个data目录全量备份，再做权限修正、启动尝试，避免新初始化生成的文件覆盖原有数据块，提升后续数据恢复难度。

内容的提问来源于stack exchange，提问作者cw c