返回目录

PostgreSQL 备份:文件在,不代表一定能恢复

离线文本版 · Markdown 标记与示例按原文保留。

> 日期说明:归档日期为历史整理日期,不代表原始首发时间;本文于 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/)