到目前为止，我们已经学习了如何设计数据库、如何操作数据、如何优化性能、如何保证安全。但所有这一切，都建立在一个基本前提之上：数据本身是安全的。

想象一下，如果有一天，你的服务器硬盘突然损坏，或者某个同事不小心执行了 DROP DATABASE 命令，而你没有任何备份……那将是毁灭性的灾难。

备份与恢复是任何一个生产数据库系统中最至关重要的环节。它是在灾难发生后，我们能让业务起死回生的唯一希望。一个没有经过测试的、可靠的备份恢复策略的数据库，无异于在悬崖边上裸奔。

PostgreSQL 提供了多种备份方式，本章我们主要关注最常用、最灵活的逻辑备份，它通过 pg_dump 和 psql (或 pg_restore) 这两个命令行工具来完成。

24.1 使用pg_dump进行逻辑备份

逻辑备份是指将数据库中的对象（表、视图、函数等）的定义 (Schema) 和数据 (Data)，以一系列 SQL 命令的形式导出到一个文本文件中。

这个备份文件本质上就是一个巨大的 .sql 脚本，内容就是大量的 CREATE TABLE ... 和 INSERT INTO ... (或者更高效的 COPY 命令) 语句。当需要恢复时，只需要执行这个脚本，就能重建整个数据库。

pg_dump 是 PostgreSQL 官方提供的、用于执行逻辑备份的命令行工具。它非常强大和安全，因为它在备份时不会锁定表，不会阻塞其他用户的读写操作。

备份整个数据库

这是最常见的备份方式。打开你的命令行终端（不是 psql），执行以下命令：

pg_dump -U your_username -h your_host -p your_port your_database_name > backup_file.sql

• -U your_username: 指定数据库用户名（如 postgres）。
• -h your_host: 指定数据库服务器地址（如 localhost）。
• -p your_port: 指定端口（如 5432）。
• your_database_name: 你想备份的数据库的名字（如 my_first_db）。
• >: 这是 shell 的重定向符，表示将 pg_dump 的输出写入到 backup_file.sql 文件中。

示例:

pg_dump -U postgres -h localhost my_first_db > my_first_db_backup.sql

执行后，系统会提示你输入 postgres 用户的密码。输入正确后，你就会在当前目录下看到一个 my_first_db_backup.sql 文件。你可以用文本编辑器打开它，看看里面的内容，加深理解。

备份单个表

有时候，我们只想备份某一张或几张特定的表。

# 只备份 users 表的结构和数据
pg_dump -U postgres -t users my_first_db > users_table_backup.sql

# 只备份 users 表的结构（不包含数据）
pg_dump -U postgres -t users --schema-only my_first_db > users_schema_backup.sql

# 只备份 users 表的数据（不包含结构）
pg_dump -U postgres -t users --data-only my_first_db > users_data_backup.sql

• -t table_name: 使用 -t 标志来指定表名。

使用自定义格式 (-Fc) 进行备份

纯文本的 .sql 格式虽然直观，但有一些缺点：它体积较大，而且在恢复时不够灵活（比如不能选择性地只恢复某张表）。

pg_dump 提供了一种更优的备份格式——自定义格式 (Custom Format)，通过 -Fc 标志来启用。

pg_dump -U postgres -Fc my_first_db > my_first_db_backup.dump

这种格式会生成一个经过压缩的二进制文件（通常以 .dump 或 .backup 为后缀）。它有以下优点：

• 体积更小。
• 恢复时更灵活：可以配合 pg_restore 工具，实现并行恢复、选择性恢复对象等高级功能。
• 更可靠。

黄金法则 ：对于生产数据库，强烈推荐使用 -Fc 自定义格式进行备份。

24.2 使用psql或pg_restore进行恢复

恢复就是备份的逆过程。

从纯文本.sql文件恢复

如果你的备份是 .sql 文件，恢复起来非常简单。本质上就是用 psql 去执行这个 SQL 脚本。

第一步：创建一个新的、空的数据库
这是一个好习惯，避免污染现有的数据库。

# 在命令行中，使用 createdb 工具
createdb -U postgres my_restored_db

第二步：使用 psql 导入备份文件

psql -U postgres -d my_restored_db < my_first_db_backup.sql

• -d my_restored_db: 指定要恢复到哪个数据库。
• <: 这是 shell 的输入重定向符，表示将 my_first_db_backup.sql 文件的内容作为 psql 的输入。

等待命令执行完毕。如果没有报错，你的 my_restored_db 数据库现在就应该和备份时的 my_first_db 一模一样了。

从自定义格式.dump文件恢复

如果你的备份是使用 -Fc 创建的，那么你必须使用 pg_restore 工具来恢复。pg_restore 提供了更强大的恢复选项。

第一步：同样，先创建一个空数据库

createdb -U postgres my_restored_db_from_dump

第二步：使用 pg_restore

pg_restore -U postgres -d my_restored_db_from_dump my_first_db_backup.dump

pg_restore 会读取 .dump 文件，解析其中的内容，并连接到指定的数据库进行恢复。

pg_restore 的一些高级用法:

• 并行恢复: 如果你的服务器有多个 CPU 核心，可以使用 -j 标志来并行恢复，大大加快速度。
• pg_restore -j 4 -d my_restored_db_from_dump my_first_db_backup.dump
• 查看备份内容: 你甚至可以在不恢复的情况下，先看看备份文件里都包含了哪些东西。
• pg_restore -l my_first_db_backup.dump

23.3 物理备份简介

除了我们上面讲的逻辑备份，PostgreSQL 还支持物理备份。

物理备份不是导出 SQL 命令，而是直接复制构成数据库的数据文件。它通常与预写日志 (WAL) 归档结合使用，可以实现更高级的恢复策略，比如：

• 时间点恢复 (Point-in-Time Recovery, PITR)：可以将数据库恢复到过去任意一个精确的时间点（比如“恢复到昨天下午 3:05 的状态”）。
• 流复制 (Streaming Replication)：可以搭建一个或多个与主数据库实时同步的“热备”服务器，用于高可用和读写分离。

物理备份比逻辑备份更复杂，通常用于对数据丢失容忍度极低、对高可用性有严格要求的大型生产系统。对于中小型应用，一个定期执行、经过验证的 pg_dump 逻辑备份策略通常已经足够。

本章小结

你已经掌握了保护数据安全的最后一道，也是最重要的一道防线！

• 我们理解了逻辑备份的原理，即把数据库导出为 SQL 脚本。
• 学会了使用 pg_dump 工具来备份整个数据库或单个表。
• 掌握了使用 -Fc 标志创建自定义格式的备份，这是生产环境的最佳实践。
• 学会了如何分别使用 psql 和 pg_restore 从不同格式的备份文件中恢复数据。
• 对物理备份有了初步的了解，知道了它可以实现 PITR 等更高级的功能。

记住：没有经过恢复测试的备份，等于没有备份！ 请务必定期演练你的恢复流程，确保在真正的灾难来临时，你的备份是可用的。

在下一章，我们将介绍 PostgreSQL 强大的扩展生态，学习如何通过安装扩展来为你的数据库添加各种各样的新功能。我们下一章见！