PostgreSQL 的备份有两种老毛病要么全量 dump 落在数据库本机盘盘满了才慌要么 WAL 归档目录和主库同机器主库一挂归档也跟着没。pgBackRest 是社区里最稳的 Postgres 备份工具它原生支持把仓库放进 S3 兼容对象存储repo-type设成s3备份和 WAL 归档就直接写进对象存储的桶里。下面把接自建 S3 端点的配置和备份、恢复流程走一遍。先建备份桶和专用身份别拿管理员账号建一个只管备份桶的 IAM 用户。下面这条路径用 rc 客户端演示rcaliassetrustfs http://rustfs:9000$RUSTFS_ACCESS_KEY$RUSTFS_SECRET_KEYrc mb rustfs/pg-backup rc admin useraddrustfs pgbackrestChangeMe-Strong-Secretcatpg-policy.jsonEOF { Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [s3:ListBucket, s3:GetBucketLocation], Resource: [arn:aws:s3:::pg-backup] }, { Effect: Allow, Action: [s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListMultipartUploadParts], Resource: [arn:aws:s3:::pg-backup/*] } ] } EOFrc admin policy create rustfs pg-policy pg-policy.json rc admin policy attach rustfs pg-policy pgbackrest内置的readwrite策略对所有桶开放读写不符合权限收在备份桶的意图所以用自定义策略。服务端 1.0.0 已于 2026 年 9 月 16 日 GArc 启动的服务必须显式设置RUSTFS_ACCESS_KEY/RUSTFS_SECRET_KEY默认口令已废弃。pgbackrest.conf 的 s3 仓库怎么配核心是把repo1从本地文件系统改成s3endpoint指到存储的 9000 端口uri-style用pathS3 兼容存储的稳妥写法[global] repo1-types3 repo1-s3-endpointrustfs:9000 repo1-s3-bucketpg-backup repo1-s3-regionus-east-1 repo1-s3-keypgbackrest repo1-s3-key-secretpgbackrest 的 secret repo1-s3-uri-stylepath repo1-path/pgcluster01 repo1-retention-full7 [main] pg1-path/var/lib/postgresql/16/main几个参数的官方口径repo-s3-uri-style只有host和path两种取值默认host连 bucket.endpoint 域名自建端点没有这套 DNS用path。证书校验选项现在的名字是repo1-storage-verify-tls默认y老的repo-s3-verify-tls已列入废弃名单、暂时兼容。端点是 http 时没有 TLS 这回事不用管它用 https 加自签证书时才需要设n官方注明这只该用于测试或自签场景。stanza 段就是 stanza 名本身上面配的是[main]pg1-path指数据目录别放错段。repo1-path建议给个前缀而不是桶根官方的理由是桶里可能还要放日志等其他内容。repo-retention-full不配的话只出警告不清理要么显式给值要么接受备份无限累积。region参与签名计算自定义端点下填一个两端一致的值即可us-east-1是惯例占位。PostgreSQL 侧开 WAL 归档备份要连续得让 Postgres 把 WAL 段实时推进桶里。改postgresql.confarchive_mode on archive_command pgbackrest --stanzamain archive-push %p wal_level replica%p是当前 WAL 文件路径archive-push会把它传到repo1指向的桶。改完SELECT pg_reload_conf();或重启生效。WAL 归档连续才谈得上 PITR时间点恢复。备份与恢复一条 stanza 走全pgbackrest--stanzamain stanza-create pgbackrest--stanzamain backup--typefull pgbackrest--stanzamain backup--typeincr systemctl stop postgresql pgbackrest--stanzamain restore systemctl start postgresql恢复时 pgBackRest 会把需要的全量、增量和 WAL 从桶里拉回来重组。备份落在对象存储的好处是数据库机和备份彻底解耦主库机器挂了备份还在桶里换一台机器restore就行。边界与代价WAL 归档是前提。只跑backup不配archive_command恢复点就只能到上一次备份做不到连续PITR 必须archive_modeon。网络要通。pgBackRest 在数据库机执行得能访问存储的 9000 端口跨网段挂 TLS 反向代理并保持证书校验开启。保留策略在 pgBackRest 侧。retention-full控制留几个全量过期的备份集由 pgBackRest 自己从桶里清理不用手动删对象。大库首备放低峰。首次全量要把整个数据目录读一遍、压缩、分片传到存储端点耗时按数据库体积和网络吞吐算量级和增量的只传差异块完全不是一回事同时process-max拉起的并行压缩会同时吃 CPU、磁盘 IO 和带宽。挑业务低峰跑跑的时候别顺手做 VACUUM 或重索引。桶里不是全部。官方在说明自包含导出时讲得很透仓库除了备份集和 WAL 归档还保存着压缩、加密、文件打包这类功能所必需的关键元数据只把备份文件和一部分 WAL 拷出去通常跑不起来。留在数据库机上的还有配置本身/etc/pgbackrest.conf、日志目录/var/log/pgbackrest以及开了异步归档之后的本地队列目录spool-path。真出灾难要恢复这些和桶里的数据是一套只恢复桶等于丢掉 stanza 的配置前提。断网会重试但不会自己救场。归档命令失败时 PostgreSQL 会攥着 WAL 段反复重试pg_wal里的段越堆越多严重的会把写操作顶住。官方 FAQ 把这类could not find WAL segment归到归档命令、pgBackRest 配置、网络或权限、第三方存储配置、WAL 积压这几类原因上排查时用check并把--archive-timeout调得比配置值更高看清理队列要多久写入量大的集群可以开异步归档把卡在返回给数据库这一环的窗口压短。备份本身也能续跑中断的备份会拿清单里的校验和比对本已传完的文件从断点继续。pgBackRest 接 S3 兼容存储的全部门槛就是 repo1 那几行加一个能写能删的专用身份剩下的是备份策略本身的设计。主库故障不再连带归档丢失这一条就值得把仓库从本地盘挪出来。RustFS 1.0.0 已于 2026 年 9 月 16 日 GA源码和 issue 在 github.com/rustfs/rustfspgBackRest 的配置参考在 pgbackrest.org。
