备份

Pier 通过在运行中的容器内转储数据库、压缩输出并将其传输到对象存储来完成数据库备份。备份按服务逐项配置，并按 cron 计划运行，每次成功运行后都会执行保留策略。

支持的引擎

备份支持 PostgreSQL（包括 PostGIS 和 TimescaleDB）、MySQL、MariaDB 和 MongoDB。每种引擎生成不同的磁盘格式：

引擎	转储工具	存储格式
PostgreSQL / PostGIS / TimescaleDB	pg_dump -Fc（自定义格式）	.dump（自压缩）
MySQL / MariaDB	mysqldump	.sql.gz（在 Pier 中经 gzip 压缩）
MongoDB	mongodump --archive --gzip	.archive.gz

PostgreSQL 转储始终以集群超级用户身份运行，因此扩展的 schema（例如 PostGIS 的 tiger/topology）能够被完整捕获。

逐库备份 vs. 集群级备份

设置了 database_name 的计划仅备份单个逻辑数据库。未设置数据库名的计划为集群级备份：对于 SQL 引擎，它会遍历其已知的每个数据库，并将它们打包进单个 .tar.gz（条目命名为 <db>.dump 或 <db>.sql）；对于 MongoDB，它会运行一次全实例 mongodump。

恢复仅支持逐库进行。集群级 tar 归档可作为来源——Pier 会从中提取你要恢复的那一个数据库——但你无法在一次操作中恢复整个集群。

计划

每个计划存储一个 cron 表达式、一个保留数量和目标 S3 存储。创建计划时的默认值：

字段	默认值
Cron	0 2 * * *（每天 02:00）
保留	保留 7 份备份

计划由统一调度器驱动（参见计划任务）——备份计划会作为 backup 操作出现在计划列表中。你也可以随时触发临时运行；如果尚不存在逐库计划，临时的逐库运行会回退使用集群级计划的存储。

异地存储

备份会上传到兼容 S3 的对象存储或 Bunny.net。一个存储条目包含端点、区域、存储桶、访问密钥、密钥以及一个可选的键前缀（默认为 pier-backups）。键的布局为 {prefix}/{service}/{filename}。在将计划指向某个存储之前，使用 Test 来验证连接。

保留

每次备份成功后，Pier 会为该计划保留最新的 retention_count 份已完成备份，并删除其余的——包括对象存储中的 blob 和数据库记录。清理失败会被记录到日志，但绝不会导致备份本身失败。

恢复

存在两条恢复路径，二者均为逐库且均具有破坏性——目标数据库会被删除并重新创建，因此目标必须已在服务中存在（其存储的凭据提供属主角色和密码）：

• 从已存储的备份恢复——从存储下载 blob，必要时从集群 tar 中提取数据库，并通过 pg_restore/psql/mysql/mongorestore 进行重放。
• 从直接上传恢复——手动上传 .dump、.sql.gz、.tar.gz 或 .archive.gz 文件。这是跨集群灾难恢复路径：它可以在一个未配置任何存储的全新 Pier 实例上工作。格式会根据文件名检测，并针对目标引擎进行校验。

备份也可以作为文件下载，并可单独删除。

pier.db + .env 的系统备份

独立于数据库备份，Pier 会每日对自身状态进行本地快照：pier.db 和 .env 会被复制到 data/backups/system/，按天加时间戳，保留最近 7 天。这保护了控制平面数据库和加密配置；它不会被传输到异地。

后续步骤

• 告警与通知——在备份失败时获得通知。
• 计划任务——触发备份的调度器。
• 访问与审计——数据库凭据如何受到保护。