PostgreSQL 备份：文件在，不代表一定能恢复

> 日期说明：归档日期为历史整理日期，不代表原始首发时间；本文于 2026-11-02 核对并修订。命令示例需按实际环境替换占位符。


小型站点可以从 pg_dump 开始，保留数据库逻辑备份。本文整理两个容易忽略的环节，作为日常使用时的检查参考。

<!-- more -->

## 先选择适合规模的方法

小型站点可以从 pg_dump 开始，保留数据库逻辑备份。角色与权限可能还需要单独导出。更大的数据库可能需要物理备份和 WAL 归档，并围绕恢复时间目标做设计。

## 恢复测试要在独立位置进行

选择匹配的客户端版本，记录扩展、编码与权限要求。在新数据库中恢复后，检查关键表、约束与应用读写。只检查备份文件大小，无法发现扩展缺失或权限不完整。

## 日常使用的小结

备份应配合保留策略和异地副本。把数据库密码直接写进定时任务命令行会增加暴露面，可采用受限的凭据文件或运行环境。


## 操作参考与适用边界

### 导出并检查目录清单

```sh
pg_dump -Fc -h DB_HOST -U DB_USER DB_NAME -f backup.dump
pg_restore --list backup.dump
```

使用 PostgreSQL 原生工具。密码通过交互提示或受限 pgpass 提供；不要把密码直接拼进命令。list 成功只代表能读取归档目录，仍需在隔离数据库中验证完整恢复。

### 如何判断结果

操作后应将实际结果与文中目标对照；命令成功退出只能证明该步骤完成，不能替代业务层验证。记录异常信息时，保留时间、软件版本与相关上下文，方便后续复查。

## 参考资料

- [官方文档与规范](https://www.postgresql.org/docs/current/backup-dump.html)（本次整理参考，页面内容可能随版本更新）
- [继续阅读本站归档](/archives/)