SQL 转储的方法是创建一个文本文件，里面都是 SQL 命令，当把这个文件回馈给服务器时，将重建与转储时状态一样的数据库。PostgreSQL 为这个用途提供了 pg_dump 工具。这条命令的基本用法是：
pg_dump dbname > outfile
正如你所见，pg_dump 把结果输出到标准输出。我们下面就可以看到这样做有什么好处。
pg_dump 是一个普通的 PostgreSQL 客户端应用(尽管是个相当聪明的东西)。这就意味着你可以从任何可以访问该数据库的远端主机上面进行备份工作。但是请记住 pg_dump 不会以任何特殊权限运行。具体说来，就是它必须要有你想备份的表的读权限，因此，实际上你几乎总是要成为数据库超级用户。
要声明 pg_dump 应该以哪个用户身份进行连接，使用命令行选项 -h host 和 -p port 。缺省主机是本地主机或环境变量 PGHOST 声明的值。类似的，缺省端口是环境变量 PGPORT 或(如果它不存在的话)编译好了的缺省值。服务器通常都有相同的缺省，所以还算方便。
和任何其它 PostgreSQL 客户端应用一样，pg_dump 缺省时用与当前操作系统用户名同名的数据库用户名进行连接。要覆盖这个名字，要么声明 -U 选项，要么设置环境变量 PGUSER 。请注意 pg_dump 的连接也和普通客户应用一样要通过客户认证机制(在章20里描述)。
由 pg_dump 创建的备份在内部是一致的，也就是说，在 pg_dump 运行的时候对数据库的更新将不会被转储。pg_dump 工作的时候并不阻塞其它的对数据库的操作(但是会阻塞那些需要排它锁的操作，比如 VACUUM FULL)。
【重要】如果你的数据库结构依赖于 OID(比如说用做外键)，那么你必须告诉 pg_dump 把 OID 也导出来。要导出 OID ，可以使用 -o 命令行选项。
pg_dump 生成的文本文件可以由 psql 程序读取。从转储中恢复的常用命令是
psql dbname < infile
这里的 infile 就是你给 pg_dump 命令的 outfile 参数。这条命令不会创建 dbname 数据库，你必须在执行 psql 前自己从 template0 创建(也就是用 createdb -T template0 dbname命令)。psql 支持类似 pg_dump 的选项用以控制数据库服务器位置和用户名。参阅 psql 的手册获取更多信息。
在开始运行恢复之前，目标库和所有在转储出来的库中拥有对象的用户，以及曾经在某些对象上被赋予权限的用户都必须已经存在。如果这些不存在，那么恢复将失败，因为恢复过程无法把这些对象恢复成原有的所有权和/或权限。有时候你希望恢复权限，不过通常你不需要这么做。
缺省时，psql 脚本将在遇到错误的时候仍然继续执行。你可能希望在脚本的最前面使用下面的命令来保证在遇见错误的时候退出 psql 并返回状态码 3 。
\set ON_ERROR_STOP
不管上述哪种方法都只能得到部分恢复了的数据库。另外，你可以将整个恢复过程当成一个单独的事务，这样就能够保证要么全部恢复成功，要么全部回滚。可以通过向 psql 传递 -1 或 --single-transaction 命令行参数达到此目的。使用这个模式的时候即使一个很微小的错误也将导致已经运行了好几个小时的恢复过程回滚。尽管如此，这种模式也比手动清除哪些不完整的恢复数据强。
pg_dump 和 psql 可以通过管道读写，这样我们就可能从一台主机上将数据库目录转储到另一台主机上，比如：
pg_dump -h host1 dbname | psql -h host2 dbname
【重要】pg_dump 生成的转储输出是相对于 template0 的。这就意味着任何加入到 template1 的语言、过程等都会经由 pg_dump 转储。这样在恢复的时候，如果你使用的是自定义的 template1 ，那么你必须从 template0 中创建空的数据库，就像我们上面的例子那样。
一旦完成恢复，在每个数据库上运行 ANALYZE 是明智的举动，这样优化器就有可用的统计数据了。vacuumdb -a -z 等效于手工运行 VACUUM ANALYZE 。关于如何有效加载海量数据的信息，参考节13.4。
pg_dump 上面的方法在备份整个数据库集群的时候比较麻烦而且不方便。因此我们提供了 pg_dumpall 程序。pg_dumpall 备份一个给出的集群中的每个数据库，同时还确保保留像角色和表空间这样的全局数据状态。这个命令的基本用法是：
pg_dumpall > outfile
生成的转储可以用 psql 恢复：
psql -f infile postgres
实际上，你可以声明任意现有的数据库进行连接，但是如果你是向一个空的数据库集群装载，那么 postgres 应该是比较好的选择。恢复 pg_dumpall 的转储的时候通常需要数据库超级用户权限，因为我们需要它来恢复角色和表空间信息。如果使用了表空间，需要注意转储中的表空间路径必须适合新的安装。
因为 PostgreSQL 允许表最大尺寸大于系统的最大文件尺寸，因此生成的文件尺寸很可能超过系统限制。因为 pg_dump 输出到标准输出，你可以用标准的 Unix 工具绕开这个问题：
使用压缩的转储。使用你熟悉的压缩程序(比如 gzip)
pg_dump dbname | gzip > filename.gz
用下面命令恢复：
createdb dbname gunzip -c filename.gz | psql dbname
或者
cat filename.gz | gunzip | psql dbname
使用 split 工具。 split 允许用下面的方法把输出分解成操作系统可以接受的大小。比如，让每个块大小为 1MB ：
pg_dump dbname | split -b 1m - filename
用下面命令恢复：
createdb dbname cat filename* | psql dbname
使用自定义的转储格式。如果 PostgreSQL 是在一个安装了 zlib 压缩库的系统上制作的，那么自定义转储格式将在写入输出文件的时候压缩数据。它会生成和使用 gzip 类似大小的转储文件，但是还附加了一个优点：你可以有选择地恢复库中的表。下面的命令用自定义转储格式转储一个数据库：
pg_dump -Fc dbname > filename
自定义格式的转储不是脚本，不能用于 psql ，而是需要使用 pg_restore 转储。请参考 pg_dump 和 pg_restore 的手册获取细节。