上周处理了一次某云平台PostgreSQL实例磁盘被写满的故障。生产库在K8S集群里跑着下午三点半告警进来整库掉进ReadOnly状态好在恢复所依赖的一套备份文件独立存放在对象存储里最终没有丢数据。这次踩坑之后我把K8S环境下PostgreSQL数据备份恢复的整套做法重新梳理了一遍从备份方案选型、定时任务编排到恢复验证和故障排查都整理了可以照抄的配置。这篇内容就是那次复盘的结果适合正在把数据库迁到K8S平台的DBA、负责容器化平台的应用运维也适合刚接触容器化数据库备份的开发者。我会尽量把命令、脚本和踩过的坑都写清楚照着做能少走不少弯路。1. 备份方案选型K8S环境里PostgreSQL备份有哪几条路1.1 主流方案的适用场景矩阵K8S里跑PostgreSQL备份思路和传统虚拟机环境有明显区别。传统环境你只要在一台机器上配好cron想怎么备份就怎么备份到了K8S里Pod会被重建、节点会故障、PVC可能迁移备份方案如果不建立在容器编排原语之上很容易出现“定时任务挂掉了没人知道”或者“备份文件跟着集群一起消失”的情况。现阶段比较常用的方案有四类先看对比表。方案工作原理恢复粒度外部依赖适用场景pg_dump/pg_dumpall 逻辑备份通过SQL导出数据可恢复单表、单库无只需psql客户端中小库、跨大版本迁移、需要选择性恢复pg_basebackup 物理备份复制整个数据目录全实例恢复需预留同版本工具大库、需要完整复刻实例、配合WAL归档CSI卷快照对PVC做时间点快照整卷回滚依赖存储类和CSI驱动与底层存储强绑定适合快速恢复备份Operator或第三方编排工具封装逻辑/物理备份按需选择依赖Operator部署需要自动化生命周期管理的生产环境单看表可能不够直观我说下我的实际选型习惯。部署在K8S里的业务库我至少会保留两条链路一条是每天定时执行的pg_dump逻辑备份文件传送到独立存储另一条是依赖存储层或物理备份的快速恢复通道用于应对整库级别的故障。逻辑备份能救单表误删物理备份能救数据目录损坏二者不能互相替代。1.2 为什么K8S里做数据库备份不能照搬传统方式很多人第一反应是“PostgreSQL备份我熟pg_dump加crontab不就完了”。这句话在虚拟机时代基本没毛病但放到K8S环境里会碰到几个隐藏问题。第一Pod生命周期不可控。数据库Pod被调度器迁移、滚动更新、OOM重启之后你在旧Pod里写下的crontab文件会直接消失没有任何提示。第二网络地址会变。Pod重建后IP大概率变化备份脚本如果写死了某个IP下次执行可能连的就是别的节点。第三存储位置要区分开。如果你把备份文件写到数据库Pod挂载的同一个PVC里一旦PVC损坏或误删备份和源数据一起没。这相当于把钥匙锁在保险柜里。所以我的操作习惯是备份任务的执行器不要依赖数据库Pod本身统一用K8S的CronJob单独跑备份文件的落盘目标不要和数据库数据卷共享同一份存储至少要放到另一块PVC或者对象存储关键脚本全部通过ConfigMap挂载这样即使Pod重建也能从配置中心拉回来。1.3 逻辑备份与物理备份怎么选逻辑备份的标准姿势是pg_dump和pg_dumpall。pg_dump用于导出单个数据库或部分表pg_dumpall则负责导出集群级别的全局对象比如角色、表空间。两者配合使用能覆盖绝大多数业务场景。物理备份则使用pg_basebackup它直接复制数据库的数据目录不关心上层有哪些表。物理备份的优势是恢复速度快、能完整保留事务日志和复制关系劣势是备份文件大小通常远大于逻辑备份而且恢复时要求PostgreSQL主版本一致跨大版本基本不兼容。怎么选我的建议很简单业务库小于500GB逻辑备份完全够用超过这个量级或者对恢复时间要求很高就必须引入物理备份和WAL归档把RPO降到分钟级甚至秒级。本篇下面的配置示例以逻辑备份为主因为它的普适性最强物理备份的很多运维思路是相通的。2. 定时备份用CronJob把备份任务彻底托管起来2.1 动手前先定策略RPO、RTO和保留周期技术方案跑通之前先回答三个问题能接受丢多少数据能接受备份多久备份文件要留多久这三个问题对应RPO、RTO和保留周期。我习惯用一个具体场景来定参数。比如某个业务库每天凌晨2点访问量最低允许丢失24小时的数据那么每天一个全量逻辑备份就差不到哪去如果业务方说最多只能丢15分钟的数据那必须做WAL归档把归档日志连续推送到对象存储。保留周期一般看业务合规要求租户业务我至少保留30天本地测试环境可以只留7天控制存储成本。定好策略之后再写调度配置不要反过来。我见过不少团队先搭好了CronJob再回来想备份频率结果发现磁盘容量根本扛不住只能返工。2.2 CronJob配置的关键参数与YAML模板CronJob本身不复杂但有几个参数甜点很值得注意。第一个是schedule支持标准的cron表达式比如每天凌晨2点触发0 2 * * *。第二个是concurrencyPolicy必须设为Forbid防止上一个备份还没跑完下一个就启动了导致两个备份任务同时连数据库产生额外压力。第三个是ttlSecondsAfterFinished指定备份任务结束多久后自动清理避免Job堆成一片。下面是一个可用的CronJob模板密码通过Secret注入备份文件写到单独挂载的PVC。apiVersion: batch/v1 kind: CronJob metadata: name: postgres-backup-cron namespace: database spec: schedule: 0 2 * * * concurrencyPolicy: Forbid startingDeadlineSeconds: 600 successfulJobsHistoryLimit: 7 failedJobsHistoryLimit: 7 jobTemplate: spec: backoffLimit: 2 ttlSecondsAfterFinished: 3600 template: spec: restartPolicy: OnFailure containers: - name: backup image: postgres:16-alpine env: - name: PGPASSWORD valueFrom: secretKeyRef: name: pg-backup-secret key: password command: - /bin/sh - -c - | mkdir -p /backup/$(date %Y%m%d) pg_dump -h postgres-svc -U backup_user -d appdb \ -Fc -Z 5 -f /backup/$(date %Y%m%d)/appdb.dump echo backup done volumeMounts: - name: backup-storage mountPath: /backup volumes: - name: backup-storage persistentVolumeClaim: claimName: pg-backup-pvc这套模板里我特意把backoffLimit设成2试错成本可控。successfulJobsHistoryLimit控制成功历史的保留条数防止etcd里积攒大量无用的CronJob历史记录。2.3 备份文件的压缩、加密与传输pg_dump有两个很有用的开关-Fc表示自定义格式支持选择性恢复和并行恢复-Z 5表示压缩等级0到95在压缩比和CPU消耗之间比较平衡。自定义格式的文件不能直接读但pg_restore能直接操作日常使用很舒服。如果业务对数据安全等级要求高备份文件需要加密。最简单的方式是先用gpg生成公钥脚本里通过公钥加密备份文件恢复时用私钥解密。命令大概是这样的pg_dump -h postgres-svc -U backup_user -d appdb -Fc -Z 5 | gpg --encrypt --recipient backup-key -o /backup/appdb.dump.gpg备份文件只留在PVC里是不够的一旦集群整体故障PVC同样可能被销毁。所以我在生产环境里要求备份文件必须同步到独立的对象存储服务。传输逻辑很简单写一个同步脚本放到同一个CronJob里就行比如# 上传到对象存储 object_storage_upload /backup/$(date %Y%m%d)/appdb.dump gs://bucket-name/postgres/appdb/无论你用的是哪个对象存储平台只要支持S3协议都可以用成熟的CLI工具完成上传。边界场景里如果没有对象存储最低也要做到把备份文件同步到另一台独立服务器的磁盘上。2.4 备份状态的观测与失败告警备份任务跑没跑成功不能靠人肉去看。我要求所有备份脚本执行完必须输出明确的成功或失败标识并且接入告警。最简单的做法是脚本里加一个判断失败时通过Webhook推送到即时通讯工具或者直接发邮件给值班人员。在没有现成告警平台的情况下留一个Shell判断脚本也能应付if [ $? -eq 0 ]; then echo backup success: $(date) else curl -X POST -H Content-Type: application/json \ -d {text:postgres backup failed} \ http://your-alert-webhook.example.com/hook fi定时检查CronJob状态也可以作为兜底手段。常用命令备查kubectl get cronjob -n database kubectl get jobs -n database kubectl logs job/backup-job-name -n database我遇到过不止一次备份脚本在某个版本调整之后悄悄失败因为没有告警直到恢复演练才发现文件全是空的。这个坑一定要在配置阶段就堵上。3. 备份文件存储分层管理、校验与自动清理3.1 备份数据的三层存放结构备份文件不是一份走天下我习惯把它拆成三层。第一层是快速访问层放在K8S集群内的一块PVC上用于最近几天的快速恢复。第二层是安全独立层存放在对象存储中和K8S集群隔离即使整个集群挂了备份文件还在。第三层是冷归档层针对满足合规要求的旧备份可以启用对象存储的低频访问或归档策略降低存储成本。这三层的策略我建议用表格固化下来比如这样存储层级保留时间访问频率用途集群内PVC最近3天高快速单表恢复、小范围回滚对象存储30天中灾难恢复、跨集群重建冷归档180天低合规留存、长期审计需要强调一点任何一层“定期清理”规则都要实际测试过尤其是对象存储的自动过期策略。我在测试阶段就遇到过生命周期规则配置错误导致全部备份被意外删除的案例这比没有备份还可怕所以清理规则的灰度测试必不可少。3.2 备份完成后的完整性校验备份脚本跑完不等于备份文件可用。验收备份至少要看三层第一层是文件层检查文件大小和校验和第二层是格式层用pg_restore的列表模式验证备份内容是否可读第三层是数据层恢复到一个临时实例比对关键表的行数。文件大小检查最简单但很有效。一个几十GB的业务库如果备份出来只有几KB即使命令返回成功也必然有问题。比较稳妥的办法是同时记录文件字节数和执行时间连续几天对比波动异常就要警惕。格式层验证命令如下pg_restore -l /backup/appdb.dump | head -20这行命令只读取备份目录结构不会真正导入数据。如果输出的内容里有大量报错说明备份文件结构已经损坏需要立刻检查存储和脚本。3.3 数据目录级校验与残留文件排查更高阶的校验是恢复验证这个放到下一章详细展开。这里先提一下残留文件问题。CronJob每次执行都会产生新的备份文件如果清理做得不好PVC会被写满导致备份任务彻底失败。针对集群内PVC我建议在CronJob里顺带做一次过期清理find /backup -type f -mtime 7 -delete清理逻辑要写在备份成功之后绝不能写在备份之前。我曾经因为顺序写反导致当天备份还没完成旧备份已经被清掉了等于整个窗口期没有可用恢复点这是故障演练时暴露出来的低级失误。4. 恢复验证与故障演练不能等到出事才第一次做恢复4.1 恢复验证的三个层级建议至少做到第二层恢复验证这种事平时不做真的出故障时大概率手忙脚乱。我给自己定了个规矩任何生产备份方案上线前必须完整演练一次从备份文件恢复到独立实例的过程并且要在恢复完成后执行数据一致性检查。第一个层级是“格式可用性验证”使用pg_restore -l看结构这个上面说过了。第二个层级是“数据完整性验证”恢复到临时实例后对比行数和几个关键字段。第三个层级是“业务可用性验证”模拟真实业务请求访问恢复出来的实例确认应用层兼容这一层通常由业务方配合完成。不要一上来就追求第三个层级成本和收益不一定匹配。但第二个层级是底线不做就等于没有备份。4.2 从备份文件恢复到新实例的完整流程下面是一个用到自定义格式备份的典型恢复流程。假设当前环境里有一个独立的PostgreSQL实例目标库名appdb备份文件在本地路径。pg_restore -h target-host -U postgres -d appdb \ --clean --if-exists --no-owner \ /backup/appdb.dump这里三个参数分别解释一下。--clean表示导入前先删除目标库中已存在的对象配合--if-exists可以避免不存在的对象导致报错。--no-owner比较关键它会让恢复出来的对象属主统一为执行导入的用户可以跳过原环境角色不一致的问题。如果备份文件是压缩过的自定义格式pg_restore可以直接处理不需要单独解压。如果备份文件是明文SQL做法就换成用psql直接执行psql -h target-host -U postgres -d appdb -f /backup/appdb.sql4.3 恢复后的数据一致性检查恢复成功不等于万事大吉。我会在恢复出来的实例上做三件事。第一件统计所有表行数和源库的统计值或业务已知的基准值做对比。第二件检查关键表的自增序列是否落后于表内已有的最大值否则后续插入数据会报主键冲突。第三件随机抽几条关键业务数据核对字段值和源库一致。检查SQL不复杂重点是形成习惯。比如自增序列检查SELECT last_value FROM appdb.some_table_id_seq; SELECT max(id) FROM appdb.some_table;如果max(id)大于last_value导入后插入新记录会撞主键修复方式是SELECT setval(appdb.some_table_id_seq, (SELECT max(id) FROM appdb.some_table));4.4 在K8S里临时拉起一个恢复验证实例有时候为了做恢复验证不方便使用现有数据库实例我会直接在K8S里临时起一个PostgreSQL实例验证完再销毁。这样不污染任何在线环境还能顺便验证“K8S环境下从备份文件拉起数据库”的完整链路是否通顺。操作思路是kubectl create namespace restore-test kubectl run postgres-restore --imagepostgres:16-alpine \ --envPOSTGRES_PASSWORDtestpassword \ --envPOSTGRES_DBappdb \ --namespace restore-test # 等待Pod Ready后端口转发 kubectl port-forward pod/postgres-restore 5432:5432 -n restore-test然后本机执行pg_restore导入完成后执行SQL校验最后销毁临时实例kubectl delete namespace restore-test临时实例验证的好处是测试环境和生产完全隔离无论恢复过程出了什么错都不会影响在线业务。如果恢复失败的根因没找到直接在生产环境里反复试风险太大。5. 常见问题与排查实录5.1 Pod内存限制导致备份进程OOMKilled逻辑备份工具本身的CPU和内存消耗不算高但大库导出时同样能打爆容器内存尤其是启用高压缩等级后内存开销会进一步上升。我遇到过一次备份Job反复重启查看事件发现是OOMKilled。排查思路分两步。第一步看Job和Pod事件kubectl describe pod backup-pod-name -n database输出的Events里会有明确的OOMKilled字符串。第二步调整资源里的limits和requests给备份容器留够内存余量。经验值是可以先按源库大小的5%到10%预留内存再根据实际监控调整。5.2 CronJob时区问题备份时间总是和预期差8小时K8S的CronJob调度默认使用kube-controller-manager所在节点的时区而很多国内团队的期望是北京时间。如果你看到备份文件生成时间比预期晚了8小时大概率是时区没对齐。解决方式有两种。第一种是给CronJob加timeZone字段比如spec: timeZone: Asia/Shanghai schedule: 0 2 * * *注意timeZone字段要求K8S版本较新如果版本太低不认识这个字段建议直接更改镜像内的时区设置env: - name: TZ value: Asia/Shanghai这里建议两种方式都试一下我见过部分集群的CronJob对timeZone字段支持不完整设置了却在Worker节点上不生效的情况。5.3 备份Job积压导致任务重叠如果concurrencyPolicy没有设置成Forbid上一个备份还没跑完下一个备份可能已经启动两个进程同时执行pg_dump源库压力会成倍上涨。这个问题在备份大库时尤其明显一个全量备份要跑好几个小时而CronJob默认的并发策略是允许并发执行的。排查方法很简单列出所在命名空间下的所有Pod看同一时间段是否有多个备份Pod在运行kubectl get pods -n database | grep backup修复方式就是给CronJob加上concurrencyPolicy: Forbid同时把startingDeadlineSeconds设成适当的值避免任务因为前一个未结束而被无限跳过。5.4 备份文件上传失败但本地没有告警很多备份脚本会把“pg_dump成功”等同于“备份成功”。实际上pg_dump生成了本地文件但上传对象存储失败恢复时依然拿不到文件。这个问题特别隐蔽因为本地文件始终存在人肉看很难判断。我现在的脚本要求每一步都必须校验返回值上传完成后还会拉取远程文件的元数据做大小比对。如果对象存储不支持直接校验就在上传日志里记录md5值脚本里做一次本地和远程的校验和对比失败立即告警。5.5 pg_dump客户端版本和源库大版本不一致pg_dump的兼容规则是高版本客户端可以备份低版本数据库低版本客户端不能备份高版本数据库。举例来说用PostgreSQL 16的pg_dump去备份PostgreSQL 14库通常没问题但反过来导出的文件会直接报错。在K8S环境里这个问题更容易出现因为备份Pod的镜像版本可能没有被同步更新。当数据库通过Operator升级了主版本CronJob的镜像还停留在旧版本于是备份文件全部不可用。我的习惯是备份镜像单独维护一个版本清单每次数据库大版本升级时强制同步更新备份镜像。5.6 恢复时角色不存在导致大量权限报错从生产环境备份的文件恢复到临时实例时如果原环境里有大量自定义角色恢复过程会反复报错。原因很简单临时实例里没有这些角色。解决方式是在恢复前先创建好需要的角色或者在pg_restore时加上两个参数pg_restore --no-owner --no-privileges ...--no-privileges会跳过权限语句的导入避免因为角色缺失导致中断。业务如果依赖这些权限恢复完成后再单独执行权限脚本比在导入过程中层层报错好处理得多。5.7 磁盘被写满导致的备份与业务故障联动文章开头提到的磁盘写满故障根因之一就是备份文件一直堆积在数据库节点本地。数据库事务不断写入加上备份文件持续占盘最终数据库进入ReadOnly模式。这种故障在K8S里表现更加隐蔽因为PVC容量可能没有设置上限或者设置了上限但没有监控告警。我的建议是给数据卷和备份卷都配置容量告警低于15%时开始提醒低于5%时必须触发值班告警。另外备份文件存储和数据库数据卷必须分开这件事在架构设计阶段就要做。5.8 恢复演练中发现备份不完整最后一次提醒备份策略上线后每个月至少做一次随机恢复演练。我自己就因为长期没做演练发现某个备份脚本从某个时间点开始导出的数据一直缺一张分区表根源是那张表是在备份策略上线之后新建的而pg_dump的某些参数组合会漏掉特定对象。排查小技巧是对比备份文件和源库的对象清单pg_restore -l /backup/appdb.dump | grep TABLE | wc -l psql -h source-host -U postgres -d appdb -c \dt | wc -l两边数字对不上就要逐一检查差异项。结语说句实在话备份技术在PostgreSQL里的门槛并不高pg_dump、pg_restore这些工具官方文档都写得很清楚。真正区分运维水平的地方在于边界情况处理得怎么样备份文件会不会跟着集群一起丢定时任务失败有没有人知道恢复出来的数据能不能用。我自己的体会是备份方案里至少一半的工作量要给“恢复验证”这不是文档上的口号而是一次次故障复盘得到的经验。K8S里的容器运维给了我们很多便利但也让很多传统运维经验失效多花点时间把备份这条链路做扎实出问题的时候一定能体会到它的价值。