PostgreSQL备份与恢复

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重放使用的足够信息。