PostgreSQL备份与恢复

2019独角兽企业重金招聘Python工程师标准>>>

PostgreSQL备份与恢复

官方文档（英文）：http://www.postgresql.org/docs/9.4/static/backup.html

官方文档（中文）：http://58.58.27.50:8079/doc/html/9.3.1_zh/backup.html

逻辑备份：

1.SQL转储（pg_dump,pg_dumpall）

  SQL转储不包括索引，可以自定义要备份的对象及其内容，将备份内容生成不同的格式。可以通过pg_restore还原备份。

  是pg_dump的输出通常可以重新载入到PostgreSQL新版本， 然而文件级别备份和连续归档都限于原服务器版本。pg_dump是将数据库传输到另一台机器体系结构工作时唯一的方法， 如从32位变到64位服务器。

  由pg_dump创建的备份在内部是一致的， 也就是说，pg_dump转储的pg_dump开始运行时的数据库快照。pg_dump工作的时候并不阻塞其它的对数据库的操作 (但是会阻塞那些需要排它锁的操作，比如多数形式的ALTER TABLE)。

Important: 如果你的数据库结构依赖于OID(比如说用做外键)， 那么你必须告诉pg_dump把OID也导出来。要导出OID， 可以使用-o命令行选项。 

物理备份：

1.文件系统备份

    文件系统级别备份，就是直接copy数据库目录，必须关闭服务，这无法在提供24小时不间断服务的Web上应用。

    需要注意的是文件系统备份往往比SQL转储大。 比如pg_dump不用导出索引， 只是创建它们的命令。然而，文件系统备份也可能会更快。

2.连续归档和基于时间点恢复PITR(Point In Time Recovery)

  基于时间点恢复可参考：http://my.oschina.net/Kenyon/blog/58112 

     在任何时候，PostgreSQL都在集群的数据目录的pg_xlog/ 子目录里维护着一套预写日志(WAL)。 这些日志记录着每一次对数据库的修改细节。这些日志存在是为了防止崩溃： 如果系统崩溃，数据库可以通过"重放"上次检查点以来的日志记录以恢复数据库的完整性。但是，日志的存在让它还可以用于第三种备份数据库的策略： 我们可以组合文件系统备份与WAL文件的备份。如果需要恢复，我们就恢复备份，然后重放备份了的WAL文件，把备份恢复到当前的时间。这个方法对管理员来说，明显比以前的方法更复杂，但是有非常明显的优势：

• 在开始的时候我们不需要一个非常完美的一致的备份。 任何备份内部的不一致都会被日志重放动作修改正确 (这个和崩溃恢复时发生的事情没什么区别)。因此我们不需要文件系统快照的功能， 只需要tar或者类似的归档工具。

• 因为我们可以把无限长的WAL文件序列连接起来， 所以连续的备份简化为连续地对WAL文件归档来实现。 这个功能对大数据库特别有用，因为大数据库的全备份可能并不方便。

• 我们可没说重放WAL记录的时候我们必须重放到结尾。我们可以在任意点停止重放，这样就有一个在任意时间的数据库一致的快照。因此，这个技术支持即时恢复： 我们可以把数据库恢复到你开始备份以来的任意时刻的状态。

• 如果我们持续把WAL文件序列填充给其它装载了同样的基础备份文件的机器， 我们就有了一套热备份系统：在任何点我们都可以启动第二台机器， 而它拥有近乎当前的数据库拷贝。

Note: pg_dump和 pg_dumpall没有产生文件系统级别备份，并且不能作为 连续归档解决方案的一部分。比如备份是符合逻辑的并且不包含 WAL重放使用的足够信息。

转载于:https://my.oschina.net/liuyuanyuangogo/blog/497416