腾讯云Ubuntu 24.04上用Docker部署PostgreSQL实战指南-育师

腾讯云上买了一台 Ubuntu 24.04 的服务器，头一件事就是把数据库环境给安排了。这次我毫不犹豫选了 Docker 方案部署 PostgreSQL，整个流程跑下来比直接在系统里手动 apt 安装省心太多，而且后续维护、升级、迁移都方便。这篇文章就把我这次在腾讯云 Ubuntu 24.04 上通过 Docker 部署 PostgreSQL 的完整过程写出来，包括从服务器初始化、Docker 安装、容器启动、数据持久化、日常备份到问题排查，每一步都附上我当时实际操作时的思考，希望能给正要干同样事情的朋友一些参考。

1. 为什么我坚持用 Docker 跑 PostgreSQL

1.1 不直接 apt 安装的理由

很多人刚接触云服务器，习惯性apt install postgresql，装完再用pg_ctl或者systemctl去管服务。这条路不是不行，而且 Ubuntu 官方仓库里的 PostgreSQL 版本也挺稳，但它有几个问题在云服务器场景下特别明显。

第一个是升级麻烦。系统自带的 PostgreSQL 版本基本锁死在系统发版时的版本，比如 Ubuntu 24.04 默认仓库的 PostgreSQL 是 16.x 系列，以后想要升到 17 或者 18，就得自己加 PostgreSQL 官方 APT 源，然后处理数据目录格式升级，一不小心就把服务搞挂。而 Docker 镜像的版本切换就是docker pull postgres:17加一次容器重建，数据目录升级步骤反而更可控。

第二个是迁移不灵活。系统里直接装的 PostgreSQL，配置分散在/etc/postgresql/、/var/lib/postgresql/、系统日志目录等好几个地方，想原样搬到另一台机器，要把依赖、配置、数据目录一起拷过去。Docker 方案更干净，一个docker-compose.yml文件加一个数据卷目录，到新机器上一条命令就恢复服务，这个优势在做灾备或者换服务器的时候特别值钱。

第三个是隔离性。云服务器上往往不只跑一个服务，如果数据库版本或者其他依赖跟业务环境冲突，直接装在系统里就会互相踩。Docker 把 PostgreSQL 独立在一个容器里，宿主机怎么折腾都不影响数据库运行。

当然，Docker 方案也不是没有代价。多了一层容器，排查网络问题时多一个环节；数据库性能虽然损耗极小，但如果你对性能有极致追求、或者要做很复杂的系统级调优，直接用物理机部署会更直接。对我来说，云服务器场景下 Docker 的收益远远大于代价。

1.2 版本选择和镜像挑选

PostgreSQL 版本方面，我这次选了postgres:16而不是最新版 17。主要是 16 已经经过了足够长时间的线上检验，生态里的扩展、监控工具、备份工具都跟得很稳。17 发布之后新增了不少好东西，比如增量备份、更细粒度的 WAL 管理，但它的生态成熟度还不算最佳，我个人的习惯是让新版本先飞一会儿，确认没问题再迁移。如果你有明确需求必须用 17，官方镜像同样支持，命令换一下就行。

镜像本身，我建议用官方镜像postgres:16，不要用postgres:16-alpine这类精简版。Alpine 镜像体积确实小很多，但里面用的 musl libc，跟系统自带的 glibc 在行为上有微妙差异，而且编译 PostgreSQL 扩展时经常缺依赖，遇到问题解决起来比多占那几百 MB 磁盘要痛苦得多。官方标准镜像是基于 Debian 的，生态兼容性最好，出问题网上资料也齐全。

这里顺便给个腾讯云服务器配置参考。如果是个人项目或者中小业务，2核4G的轻量应用服务器足够跑 PostgreSQL 加两三个业务容器；如果数据量大、并发高，建议 4核8G 以上，并且一定要单独挂一块云硬盘存数据库文件，别把数据库放到系统盘里，系统盘出问题会连带数据一起遭殃。

2. 腾讯云环境基础准备

2.1 系统初始化和用户配置

新买的腾讯云服务器，拿到手第一件事不是装 Docker，而是把系统基础环境收拾干净。我是通过 SSH 登录服务器操作的，先更新系统软件包：

sudo apt update sudo apt upgrade -y

Ubuntu 24.04 是 LTS 版本，腾讯云镜像源一般已经配置好了，更新速度还行。

接下来我习惯创建一个普通用户用于日常操作，不建议一直用 root 直接干活，误操作风险太大。腾讯云 Ubuntu 镜像默认是没有 ubuntu 用户的，需要自己动手建：

sudo adduser ubuntu sudo usermod -aG sudo ubuntu

然后把本机的 SSH 公钥加到~/.ssh/authorized_keys里，之后就能用ssh ubuntu@服务器IP免密登录。这里有一个细节：创建用户后要测试能正常sudo再退出当前 root 会话，我之前有次忘了测，结果退出后发现新用户 sudo 权限配错了，只能回腾讯云控制台用 VNC 登录救场，来回折腾大半天。

顺便把时区设置了，业务系统里的时间错乱比你想的更常见：

sudo timedatectl set-timezone Asia/Shanghai timedatectl

2.2 安装 Docker 引擎

Ubuntu 24.04 上装 Docker 有两条路：一条是直接apt install docker.io，简单，但装出来的是 Ubuntu 仓库里打好的 Docker 版本，更新频率低；另一条是添加 Docker 官方 APT 源装docker-ce，版本新，功能全。服务器生产环境我推荐后者。

由于国内网络环境访问 Docker 官方 APT 源速度不稳定，我建议先把源替换成国内镜像站，这里以清华源为例：

sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

装完以后把 Docker 服务设为开机自启并立即启动：

sudo systemctl enable docker sudo systemctl start docker docker version

能看到 Client 和 Server 两段信息，Server 段正常显示版本号就说明装好了。顺便把手头这个用户加进 docker 组，以后就不用每条命令前都加 sudo 了：

sudo usermod -aG docker ubuntu newgrp docker

这里有个容易忽略的坑：如果你是在 Ubuntu 桌面版或者某些云镜像上跑 Docker，可能会遇到cannot connect to the Docker daemon的错误，大概率是当前用户不在 docker 组，或者 Docker daemon 没起来，用systemctl status docker查一下就行。

2.3 拉取官方 PostgreSQL 镜像

环境就绪后，直接拉取 PostgreSQL 官方镜像：

docker pull postgres:16

国内访问 Docker Hub 的速度不稳定，如果拉取超时或者非常慢，可以给 Docker 配置镜像加速。腾讯云用户可以在控制台的容器镜像服务页面找到专属加速地址，本地配置就是在/etc/docker/daemon.json里加一行registry-mirrors：

{ "registry-mirrors": ["https://mirror.ccs.tencentyun.com"] }

配置完记得重启 Docker：

sudo systemctl restart docker

这个加速只对腾讯云内网访问有效，速度快很多。

镜像拉完以后，先别急着docker run，我建议先在本地做一次简单的启动测试，确认镜像本身没问题：

docker run --rm -e POSTGRES_PASSWORD=test123 postgres:16

看到数据库初始化日志、最后出现database system is ready to accept connections就说明镜像没问题，Ctrl+C停掉，这个测试容器会自动删除，不会留垃圾。

3. Docker 部署 PostgreSQL 核心实操

3.1 docker run 快速启动一个实例

先来一个最直接的docker run命令，把实例跑起来看看效果：

docker run -d \ --name postgres \ -e POSTGRES_USER=myuser \ -e POSTGRES_PASSWORD=Mypassword123! \ -e POSTGRES_DB=mydb \ -p 5432:5432 \ -v /data/postgres:/var/lib/postgresql/data \ --restart=always \ postgres:16

这行命令每个参数都是什么意思，我拆开说：

-d：后台运行容器。
--name postgres：容器名字，后续操作都靠这个名字指代。
-e POSTGRES_USER=myuser：初始化的超级用户名，默认是postgres。我习惯显式改成业务账号名字，方便后面权限管理。
-e POSTGRES_PASSWORD=Mypassword123!：这个账号的密码。官方镜像要求必须设置，否则会拒绝启动并给出告警日志。
-e POSTGRES_DB=mydb：初始化的数据库名，不设的话默认跟 POSTGRES_USER 同名。
-p 5432:5432：端口映射，宿主机 5432 端口转发到容器 5432 端口。左边是宿主机端口，右边是容器内端口，左右可以不一样，比如-p 5433:5432，但实际用的时候为了省心，两边保持一致。
-v /data/postgres:/var/lib/postgresql/data：数据卷挂载，宿主机目录对应容器内 PostgreSQL 数据目录，这是数据持久化的关键，没有这一行，容器一删数据就全没了。
--restart=always：容器退出后自动重启，服务器重启后也会自动拉起数据库。

启动后验证一下状态：

docker ps docker logs postgres

docker logs postgres能看到 PostgreSQL 初始化全过程，包括生成超级用户、创建数据库、启动 WAL 进程等，最后出现database system is ready to accept connections就是启动成功。

3.2 数据持久化的原理和正确姿势

刚才的-v /data/postgres:/var/lib/postgresql/data是关键中的关键，这里多说几句。

PostgreSQL 官方镜像的数据目录是/var/lib/postgresql/data，所有数据文件、WAL 日志、配置文件都在这个目录下。把宿主机/data/postgres挂载过去后，容器内的写入实际落盘在宿主机，这样哪怕容器被删除、重建，只要挂载同一个目录，数据都在。

但有三个坑我实测踩过，必须提醒你。

第一个坑是挂载目录的权限。官方镜像容器内跑进程的用户postgres的 uid 是 999，宿主机上如果挂载目录的属主不对，容器启动时可能因为无法写入而报错。解决方式简单粗暴：

sudo mkdir -p /data/postgres sudo chown -R 999:999 /data/postgres

第二个坑是环境变量只在首次初始化时生效。也就是说，容器首次创建时如果/var/lib/postgresql/data目录是空的，它才会执行 initdb 并根据POSTGRES_USER、POSTGRES_PASSWORD创建账号；一旦初始化完成，你再改环境变量重启容器，账号密码都不会变。网上很多"改了密码不起作用"的求助帖，基本都是这个原因。要改密码，正确姿势是进入容器内用 SQL 改，或者删除数据目录重新初始化（前提是不要旧数据）。

第三个坑是PGDATA。官方镜像的数据目录是可以通过PGDATA环境变量改位置的，但默认已经指向/var/lib/postgresql/data了，你在宿主机挂载时，挂载点和PGDATA路径必须匹配，否则会出现挂载了目录但数据实际写到别处的情况。比如你设置了PGDATA=/var/lib/postgresql/data/pgdata，那得把宿主机目录挂载到/var/lib/postgresql/data/pgdata才正确。

3.3 生产环境推荐：用 docker compose 编排

单容器场景用docker run够用，但为了以后配置可复用、改动可追踪，我推荐一步到位使用docker-compose.yml。下面是我实际在用的精简版：

services: postgres: image: postgres:16 container_name: postgres restart: always environment: POSTGRES_USER: myuser POSTGRES_PASSWORD: Mypassword123! POSTGRES_DB: mydb TZ: Asia/Shanghai PGTZ: Asia/Shanghai LANG: C.UTF-8 ports: - "5432:5432" volumes: - /data/postgres:/var/lib/postgresql/data - /data/backups:/backups healthcheck: test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"] interval: 10s timeout: 5s retries: 5 shm_size: '256m'

这个配置里要注意几个点：

TZ和PGTZ环境变量控制容器时区，不设置的话容器默认 UTC，日志时间跟北京时间差 8 小时，排查问题时候看着特别别扭。LANG设置字符集环境，避免出现中文乱码。

healthcheck定义健康检查，用pg_isready探测数据库是否就绪，docker ps里的 STATUS 列会显示(healthy)，这在后面接容器编排、自动重启、负载均衡时很有用。

shm_size设置共享内存大小，默认 64MB 在某些并发场景可能不够，如果看到could not resize shared memory这类报错，调大这个值就行。

启动编排文件：

docker compose up -d docker compose ps docker compose logs -f postgres

以后要升级 PostgreSQL 小版本，两步搞定：

docker compose pull docker compose up -d

这种"配置即代码"的方式，对团队协作和故障恢复都有很大价值。

3.4 服务器安全组和防火墙的配置

数据库跑起来之前，先把防火墙和安全组理清楚，不然连接不上、或者被公网随意扫描，都是麻烦事。

腾讯云有两层网络控制：一层是云平台层面的安全组（CVM）或者防火墙（轻量服务器），另一层是操作系统自身的防火墙（UFW）。

我个人原则是：数据库端口 5432 绝对不对全网开放。如果业务服务器和数据库在同一台机器，那 5432 只需要监听本地，连安全组都不用放行，直接用localhost或内网 IP 连接即可。但在云服务器场景下，往往需要从本地电脑用其他工具去连库，这时候可以放行，但一定要限制来源 IP。

在腾讯云控制台的操作是：

CVM 云服务器：进入「安全组」配置，添加入站规则，协议端口填 TCP:5432，来源填你自己的公网 IP/32。
轻量应用服务器：进入「防火墙」页面，添加规则 TCP:5432，限制来源 IP 或 IP 段。

系统层面，Ubuntu 24.04 默认没有启用 UFW，我一般启用它并放行必要端口：

sudo ufw allow 22/tcp sudo ufw allow from 你的IP to any port 5432 proto tcp sudo ufw enable sudo ufw status

注意顺序很重要：先放行 SSH 22 端口，再启用 UFW。我之前真的见过有人没放行 22 就开防火墙，然后把自己锁在外面，只好去控制台用 VNC 登录救场，非常尴尬。

4. 备份、恢复与日常维护

4.1 用 pg_dump 做逻辑备份

PostgreSQL 容器跑起来之后，第一件该做的事不是往里灌数据，而是把备份方案想好。

最常用的备份方式是逻辑备份，用pg_dump把数据库导出成 SQL 文件或者自定义格式文件。在 Docker 环境下，命令是在容器外部执行，通过docker exec进到容器里跑：

mkdir -p /data/backups docker exec postgres pg_dump -U myuser -d mydb -F c -f /backups/mydb_$(date +%Y%m%d).dump

这里-F c表示输出为自定义压缩格式，比纯 SQL 文件体积小，并且支持pg_restore灵活恢复。/backups是容器内路径，通过刚才 compose 文件里的/data/backups:/backups挂载映射到了宿主机。

如果需要备份所有数据库，用pg_dumpall：

docker exec postgres pg_dumpall -U myuser -f /backups/all_$(date +%Y%m%d).dump

pg_dumpall会把所有数据库、角色、表空间的定义都导出来，适合整机级别的备份。

备份还有一个细节：建议用自定义格式而不是纯 SQL，原因是恢复时pg_restore可以指定只恢复某些表，选择更灵活，纯 SQL 要么整库跑、要么手拆文件，效率差很多。

4.2 用 pg_restore 恢复数据

恢复数据也走docker exec。先确保目标数据库存在，然后把 dump 文件恢复到库里：

docker exec -i postgres pg_restore -U myuser -d mydb --clean --if-exists /backups/mydb_20250101.dump

--clean会在恢复前删除已存在的同名对象，--if-exists避免删除不存在的对象时报错中断。如果恢复过程中报权限或者对象冲突，加个--no-owner忽略 owner 信息：

docker exec -i postgres pg_restore -U myuser -d mydb --clean --if-exists --no-owner /backups/mydb_20250101.dump

如果是纯 SQL 文件，用 psql 恢复：

docker exec -i postgres psql -U myuser -d mydb < mydb.sql

恢复前一定确认目标库是空的或者你准备好了覆盖，否则数据会叠加，出现主键冲突。

4.3 写一个自动备份脚本并交给 crontab

手动备份容易忘，生产环境必须自动化。我写了个简单可靠的备份脚本/usr/local/bin/backup_postgres.sh：

#!/bin/bash BACKUP_DIR=/data/backups DATE=$(date +%Y%m%d_%H%M%S) RETENTION_DAYS=7 docker exec postgres pg_dump -U myuser -d mydb -F c -f /backups/mydb_${DATE}.dump if [ $? -eq 0 ]; then echo "[$(date '+%Y-%m-%d %H:%M:%S')] Backup succeeded: mydb_${DATE}.dump" >> /var/log/backup_postgres.log else echo "[$(date '+%Y-%m-%d %H:%M:%S')] Backup FAILED" >> /var/log/backup_postgres.log fi find ${BACKUP_DIR} -name "mydb_*.dump" -mtime +${RETENTION_DAYS} -delete

给脚本加执行权限，然后扔进 crontab：

sudo chmod +x /usr/local/bin/backup_postgres.sh crontab -e

在 crontab 里加一行，每天凌晨 2 点执行：

0 2 * * * /usr/local/bin/backup_postgres.sh > /dev/null 2>&1

这个脚本做了三件事：执行 pg_dump 备份、记录日志、清理 7 天前的旧备份。备份文件别一直堆着，既占磁盘空间又难管理，保留最近一周就够，更早的可以转移到对象存储归档。

这里我说句实打实的话：备份脚本写了、crontab 配了，不等于备份一定有效。我见过太多"定时任务跑了几个月，结果从没真正恢复过"的例子。建议每个月手动做一次恢复演练，把备份文件恢复到临时库，验证数据完整性，这一步关键时刻能救命。

5. 常见问题排查与实战经验

5.1 连接不上数据库的排查思路

这个是最常见的问题，没有之一。现象是本地用 psql 或者客户端工具连不上腾讯云服务器的 5432 端口。排查顺序很重要，我按经验排列：

第一，先确认容器是否在运行：

docker ps docker logs --tail 50 postgres

如果容器没起来，看日志是启动报错还是直接退出，常见的有密码未设置、数据目录权限错误、磁盘空间不足等。

第二，测试宿主机本地是否能连：

docker exec -it postgres psql -U myuser -d mydb

容器内能连说明数据库本身没问题，问题在网络层；容器内都连不上，问题在数据库配置或者容器本身。

第三，检查监听地址和端口。官方镜像默认listen_addresses='*'，如果之前手动改过postgresql.conf，确认没有限制成localhost：

docker exec postgres psql -U myuser -d mydb -c "SHOW listen_addresses;" docker exec postgres psql -U myuser -d mydb -c "SHOW port;"

第四，检查云平台安全组和系统防火墙是否放行了来源 IP 的 5432 访问，步骤见上文 3.4。

第五，检查pg_hba.conf认证配置。镜像默认允许所有来源、密码认证，如果你动过这个文件，注意确认没有把远端连接全部拒绝。查看生效配置：

docker exec postgres psql -U myuser -d mydb -c "SELECT * FROM pg_hba_file_rules;"

这套排查流程走下来，90% 的连接问题都能定位。

这里还有个本地客户端容易忽略的细节：psql连接时如果没指定主机名，它不会默认走到 TCP/IP，而是走 Unix socket。我在本地一直psql -U myuser -d mydb连不上，想了半天才想起来少了-h 服务器IP，加上之后就通了。这个坑虽然基础，但真的很常见。

5.2 容器启动失败和数据目录权限问题

刚刚说过，官方镜像容器内用户postgres的 uid 是 999。宿主机挂载目录如果权限不对，容器初始化数据目录时会报类似这样的错误：

chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted

或者：

initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted

解决方式很明确：

sudo chown -R 999:999 /data/postgres

如果是 Ubuntu 桌面版并启用了 AppArmor，偶尔还会遇到容器被限制的诡异情况，表现为容器启动后马上退出，dmesg里能看到 AppArmor 相关日志。这种在云服务器上很少见，真遇到可以临时用--security-opt apparmor=unconfined测试，但生产环境不建议这么干，优先从权限和挂载找原因。

5.3 容器重启后发现数据没了

这个问题的根源基本就是数据卷没挂好。

一种情况是docker run时忘了加-v参数，数据全写到容器可写层里，容器一删数据跟着没了。这是 Docker 数据持久化的核心知识点，官方镜像README里反复强调，但还是有很多人踩。

另一种情况是挂载了，但挂载的宿主机目录是空的，容器重新初始化了一个空库。比如你原来挂的是/data/postgres，后来改配置挂到/data/pgdata，数据其实还在老目录里，只是新容器没读到。

判断当前容器挂载情况：

docker inspect postgres | grep -A 5 Mounts

Mounts 列表会明确显示源路径和目标路径，一眼就能看出来数据目录挂载对了没有。

假如数据已经跟着旧容器走了，而旧容器还没删，还有机会把数据拷出来：

# 先把旧容器停下来，别继续写入 docker stop old-postgres # 把数据目录从容器里拷到宿主机 docker cp old-postgres:/var/lib/postgresql/data /data/postgres

如果旧容器已经被删了，但只要镜像还在，理论上还能从镜像层里恢复一部分数据，不过难度大很多。所以再次强调：数据卷挂载一定要在创建容器时就配好，这是最基本的底线。

5.4 性能调优的几个常用参数

PostgreSQL 容器跑稳后，可以做一些基础性能调优。别一上来就乱调，先看几个关键参数：

SHOW shared_buffers; SHOW effective_cache_size; SHOW work_mem; SHOW max_connections;

shared_buffers是共享缓冲区，官方推荐设为物理内存的 25% 左右。比如 4G 内存的机器，设 1GB 比较合理。这个参数在容器内只认容器的内存限制，如果宿主机内存充足，按实际需求调就行。

effective_cache_size是给查询规划器参考的"操作系统文件缓存 + shared_buffers"的总量估计，可以设成物理内存的 75%。它不真正占用内存，只是优化器决策用，设置太小时会让优化器偏向走索引而非顺序扫描，变大点没坏处。

work_mem是单个排序操作可以用的内存，建议控制在 4MB-64MB 之间，并发高时设太大会导致内存耗尽，设太小排序会走磁盘临时文件，性能暴跌。这个参数没有万能值，要根据业务查询特点针对性调。

修改参数，推荐用 SQL 方式而不是去容器里改配置文件：

ALTER SYSTEM SET shared_buffers = '1GB'; ALTER SYSTEM SET effective_cache_size = '3GB';

改完执行SELECT pg_reload_conf();即可，部分参数需要重启容器才会生效（比如shared_buffers）。注意ALTER SYSTEM改的是postgresql.auto.conf，优先级高于postgresql.conf，所以不用再手动改容器里的配置。

5.5 几个值得养成的实践习惯

第一个习惯是给容器命名固定化。不要用 Docker 随机生成的容器名，比如stoic_goldberg这种根本记不住。用--name postgres或者 compose 里的container_name，后续所有命令、脚本、监控都统一用这个名字，省心。

第二个习惯是留意时区和字符集。数据库容器里设置TZ=Asia/Shanghai，数据库连接时也尽量让客户端带着时区信息。PostgreSQL 的timestamptz类型会保存 UTC 时间并按会话时区显示，如果容器时区不对，日志和业务数据会出现 8 小时偏移，查问题的时候特别容易误判。

第三个习惯是别把数据库端口对公网放开。如果只是本地调试，甚至可以用 SSH 隧道访问远程数据库，端口根本不暴露到公网。这样就算数据库账号密码泄露，外部也没法直连，多一层安全保险。

举个例子，本地想用 pgAdmin 连腾讯云上的数据库，可以这样：

ssh -L 127.0.0.1:5433:127.0.0.1:5432 ubuntu@服务器IP -N

然后本地连接127.0.0.1:5433，实际请求通过 SSH 隧道转发到服务器的 5432 端口，公网完全碰不到数据库端口。

这次部署过程中，我印象最深的还是那个数据目录权限问题。当时挂载目录建好、容器启动正常，我还挺得意，结果重启服务器后容器一直起不来，日志一片红，最后定位到就是/data/postgres目录的属主不对。chown 999:999那行命令下去，服务立刻恢复正常。从那以后我只要写挂载相关的配置，第一步就先把宿主机目录权限理顺，省得后面折腾。

另一个想特别提的是备份脚本。我有一套 PostgreSQL 服务跑了两三年，中间经历过一次磁盘故障，靠着自动备份才把数据完整恢复回来。那次经历后我给自己定了个规矩：不仅要有备份，还要定期做恢复演练。数据这东西，不验证恢复流程，就等于没有备份。

希望这篇实操记录能帮你少走一些弯路。如果你打算在腾讯云、Ubuntu 24.04 上用 Docker 部署 PostgreSQL，照着上面的步骤来，应该能顺利跑起来。过程中遇到其他问题，也建议先看docker logs，它会把大部分线索都明明白白摆在你面前。