PG backup （9.4 manual)-优快云博客

本文介绍了PostgreSQL数据库的多种备份方法，包括SQL转储、文件系统级别备份、在线备份及即时恢复等。详细讲解了使用pg_dump、pg_basebackup等工具的具体步骤，以及备份过程中的注意事项。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

24.1. SQL转储
pg_dump
pg_dumpall
pg_restore

pg_dump和psql可以通过管道读写，这样我们就可能从一台主机上将数据库目录转储到另一台主机上，比如：

pg_dump -h host1 dbname | psql -h host2 dbname

24.2. 文件系统级别备份

冷备份，只能备份整个数据库集群，不能通过拷贝单个文件或者相应pglog来实现单个或多个表（schemes dbs)

tar -cf backup.tar /usr/local/pgsql/data

24.3. 在线备份以及即时恢复(PITR)

一次基础备份 pg_basebackup加上wal日志可以恢复到任何时间点

test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/

确保WAL归档打开并且可以运转。
以数据库超级用户身份连接到数据库，发出命令:
```
SELECT pg_start_backup('label');
```
这里的label是任意你想使用的这次备份操作的唯一标识 (一个好习惯是使用备份转储文件的放置地全路径)。 pg_start_backup用备份信息在集群目录里创建一个备份标签文件backup_label。包含起始时间和标签字符串。该文件对于备份完整性是非常重要的，你需要从中恢复。

至于你连接到集群中的那个数据库没什么关系。你可以忽略函数返回的结果；但是如果它报告错误，那么在继续之前先处理它。

默认情况下，pg_start_backup可能需要很长的时间才能完成。这是因为它会执行一个检查点，并且I/O所需的检查点会被分散在一个显著的时间段，默认情况下，使用一半你的相互检查点间隔（参见配置参数 checkpoint_completion_target）。这是你想要的，因为它最大限度地减少对查询处理的影响。如果你想尽快开始备份，使用：
```
SELECT pg_start_backup('label', true);
```
这强制检查点尽快完成。
执行备份，使用任何方便的文件系统工具，比如tar或者cpio （而不是pg_dump或者 pg_dumpall）。这些操作过程中既不需要关闭数据库，也不需要关闭数据库的操作。
再次以数据库超级用户身份连接数据库，然后发出命令：
```
SELECT pg_stop_backup();
```
这将中止备份模式并自动切换到下一个WAL段。自动切换是为了在备份间隔中写入的最后一个WAL 段文件可以立即为下次备份作好准备。
只要在备份过程中使用的WAL段文件备份完毕，你的备份工作就完成了。通过pg_stop_backup的结果标识的文件是需要形成一套完整备份文件的最后一段。如果archive_mode已启用， pg_stop_backup不返回，直到最后段被归档。这些文件的归档是自动发生的，因为已配置archive_command。在大多数情况下，这将迅速发生，但建议您监控您的存档系统以确保没有延迟。如果归档进程已经落后，因为存档命令失败，它会继续重试直到存档成功，备份完成。如果您希望在执行pg_stop_backup时有时间限制，则设定适当的 statement_timeout值。

目前，在线备份技术还有几个局限。它们可能在将来的版本中修补：

在Hash索引上的操作目前没有使用WAL记录日志，所以重放就不会更新这些索引类型。这将意味着任何新的插入被索引忽略，已更新行显然会消失，并且已删除行将仍然保留指针。换句话说，如果你修改了带有hash索引的表，那么你将获得备用服务器上不正确的查询结果。当完成恢复时，建议是在完成恢复操作之后手工REINDEX每个这样的索引。
如果在进行数据库备份的时候发出一个CREATE DATABASE命令，然后在这个过程中CREATE DATABASE命令拷贝的模板数据库被修改了，那么用这个备份进行恢复的数据库很有可能导致这些修改也传播到新创建的数据库中去。这个行为当然是不愿意看到的。为了避免这个风险，最好在进行数据库备份的时候不要修改任何模板数据库。
CREATE TABLESPACE命令是用文本的绝对路径记录WAL日志的，因此会以相同的绝对路径重新创建。如果日志是在另外一台机器上重放，那么这个行为可能不是我们想要的。即使在同一台机器，但是在一个新的数据目录里重放日志，都很可能是危险的：重放仍将会覆盖原来的表空间的内容。为了避免这类的潜在问题，最好的方法是在创建或者删除表空间之后进行一次新的基础备份。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26526320/viewspace-2106850/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26526320/viewspace-2106850/