更换 PostgreSQL 备份工具，真正困难的部分通常不是安装新二进制文件，而是如何处理已经运行多年的备份仓库、保留策略、恢复流程、值班手册和合规要求。迁移到 pg_hardstorage 的关键思路，是把它当作一次渐进式运维转换，而不是一次仓库重写或“一键切换”。
迁移的核心：保留旧仓库，建立新历史
迁移期间，现有备份仓库继续保留，新的备份则写入 pg_hardstorage 仓库。历史备份仍然由创建它们的原工具负责恢复，例如：
- 由 pgBackRest 创建的备份，继续使用 pgBackRest 恢复。
- 由 Barman 创建的备份，继续使用 Barman 恢复。
- 由 WAL-G 创建的备份，继续使用 WAL-G 恢复。
- 迁移后产生的新备份，使用 pg_hardstorage 管理和恢复。
这种方式避免了对历史仓库进行重写，也不会要求团队在同一天完成所有恢复验证。旧仓库可以按照原有保留期限自然退出，团队则可以在生产切换前单独验证新的备份链和恢复流程。
双写模型如何工作
一个适合 PostgreSQL 运维的迁移流程通常包含以下步骤：
- 在现有备份环境旁边创建新的 pg_hardstorage 仓库。
- 创建一个新的全量备份，作为 pg_hardstorage 的备份历史起点。
- 在迁移窗口内持续捕获 WAL，确保新仓库具备可用的时间点恢复能力。
- 使用隔离环境验证全量恢复、WAL 重放和时间点恢复。
- 让生产备份任务切换到 pg_hardstorage。
- 保留旧仓库和旧恢复工具，直到原有保留窗口结束。
- 根据审计、合规和内部运维规则，完成旧仓库的退役。
需要注意的是，“双写”并不一定意味着每个备份文件都必须被两个工具同时生成。更准确的理解是：迁移阶段同时维护旧的恢复能力和新的备份历史。兼容层可以帮助保留现有自动化入口，使熟悉的命令和定时任务继续生成原生的 pg_hardstorage 备份，从而减少调度系统和运行手册的改动。
一个可改造的迁移脚本示例
下面是一个简化的 Bash 示例，展示如何把迁移过程拆成可审计的步骤。命令名称和参数需要根据实际部署的 pg_hardstorage 版本、仓库路径以及现有备份工具进行调整；示例重点是流程编排，而不是宣称某个固定 CLI 接口。
#!/usr/bin/env bash
set -Eeuo pipefail
OLD_REPO="/backup/pgbackrest"
NEW_REPO="/backup/pg_hardstorage"
VERIFY_DIR="/srv/postgresql-restore-check"
mkdir -p "$NEW_REPO" "$VERIFY_DIR"
# 1. 创建新的 pg_hardstorage 仓库。
pg_hardstorage repo init --path "$NEW_REPO"
# 2. 建立新的全量备份历史。
pg_hardstorage backup create \
--repo "$NEW_REPO" \
--pgdata /var/lib/postgresql/16/main \
--full
# 3. 迁移期间继续捕获 WAL。
pg_hardstorage wal start \
--repo "$NEW_REPO" \
--pgdata /var/lib/postgresql/16/main
# 4. 恢复到隔离目录，验证新仓库可用。
pg_hardstorage restore \
--repo "$NEW_REPO" \
--target "$VERIFY_DIR" \
--latest
# 5. 通过应用检查、数据库检查或自动化测试确认恢复结果。
pg_isready -D "$VERIFY_DIR"
psql "host=/var/run/postgresql dbname=postgres" \
-c "SELECT now(), version();"
# 6. 验证通过后，再把新的定时任务指向 NEW_REPO。
printf 'Recovery validation completed for %s\n' "$NEW_REPO"
printf 'Keep the old repository at %s until its retention window expires.\n' "$OLD_REPO"
在真实环境中，建议把恢复验证放进临时虚拟机、独立 Kubernetes 命名空间或隔离主机，并补充以下检查：
- 数据库是否能够启动并完成 WAL 重放。
- 关键业务表的行数、最新时间戳和校验结果是否符合预期。
- 时间点恢复是否能够恢复到指定时间。
- 应用连接、扩展、角色和权限是否完整。
- 恢复所需的密钥、证书、配置文件和外部依赖是否可用。
- 故障转移和恢复手册是否仍然与实际命令一致。
不要只测试“备份成功”
迁移成功的判断标准不应只是备份任务返回零退出码。真正需要验证的是：团队能否在压力下找到正确的仓库、选择正确的工具，并在规定时间内恢复服务。
可以为每个恢复场景建立明确的验收记录：
| 场景 | 使用的仓库 | 使用的工具 | 验证结果 |
|---|---|---|---|
| 迁移前历史备份恢复 | 旧仓库 | 原备份工具 | 通过/失败 |
| 迁移后最新全量恢复 | 新仓库 | pg_hardstorage | 通过/失败 |
| 时间点恢复 | 新仓库与 WAL | pg_hardstorage | 通过/失败 |
| 生产切换回退 | 旧仓库 | 原备份工具 | 通过/失败 |
回退能力尤其重要。即使新工具已经通过测试，也不应在旧仓库的保留期限结束前删除它。旧仓库不仅是数据副本，也是迁移期间的操作保险和合规证据。
从不同工具迁移时的共同原则
从 pgBackRest、Barman 或 WAL-G 迁移时，具体命令和仓库结构会不同，但整体方法可以保持一致：
- 让旧仓库继续承担历史恢复职责。
- 为 pg_hardstorage 创建独立的新仓库和全量备份历史。
- 在切换前验证恢复，而不是等到灾难发生时验证。
- 尽量保留现有调度、监控和告警入口。
- 按既定 retention window 退役旧仓库。
对于依赖流式备份或 WAL 归档的环境，迁移时还需要特别确认 WAL 捕获是否连续、归档延迟是否可观测，以及新旧系统之间是否存在重复归档、覆盖文件或权限冲突。
上线前检查清单
采用这种迁移策略前，可以逐项确认：
- [ ] 新仓库的容量、权限、加密和网络路径已验证。
- [ ] 已完成一次新的全量备份。
- [ ] WAL 捕获和归档延迟有监控。
- [ ] 已在隔离环境完成完整恢复。
- [ ] 已验证至少一个时间点恢复场景。
- [ ] 值班手册同时记录新旧工具的使用方式。
- [ ] 生产切换有明确的回退步骤和负责人。
- [ ] 旧仓库的保留期限、删除审批和合规记录已经确认。
- [ ] 监控、告警、定时任务和权限策略已经完成变更评审。
pg_hardstorage 的迁移价值并不只在于替换备份工具，而在于让新工具逐步进入现有 PostgreSQL 运维体系。保留旧仓库、建立新的备份历史、验证恢复能力，再根据保留策略完成退役，这种节奏可以把一次高风险切换拆成多个可验证的操作步骤。对于恢复要求严格的生产环境，迁移速度应当服从恢复信心，而不是相反。