Postgresql系统备份与恢复（四）

5          PG的恢复方式

 

1.         SQL 转储：使用“pg_restore”完成，逻辑恢复的一种方式，命令中参数同“pg_dumpall”等。

2.         文件系统级别备份：把备份的文件拷贝再拷回到系统的数据目录下，属于物理恢复方式。

3.         从在线备份中恢复：（摘自：http://www.pgsqldb.org/pgsqldoc-8.1c/backup-online.html ）

（1）    停止 postmaster，如果它还在运行的话。

（2）    如果你还有足够的空间，把整个集群数据目录和所有表空间拷贝到一个临时位置， 以防万一你之后还需要它们。请注意这个预防措施要求你在系统里有足够的剩余空间来保存现有库的两份拷贝。 如果你没有足够的空间，那么你至少需要把集群数据目录的 pg_xlog 子目录的内容拷贝到安全的地方， 因为它们可能包含系统宕掉的时候还没有归档的日志。

（3）    然后清理掉所有在该集群数据目录里的现存文件， 以及所有你使用的表空间里根目录下的现存文件。

（4）    从你的备份转储中恢复数据库文件。要小心用正确的所有者（数据库系统用户，而不是 root！）和权限恢复它们。 如果你使用了表空间，你可能需要核实在 pg_tblspc/ 里的符号连接都得到正确恢复。

（5）    删除任何目前还在 pg_xlog/ 里的文件；这些文件来自备份转储，因此它们可能比目前的老。 如果你就根本没有归档 pg_xlog/，那么重建之，要注意也要重建子目录 pg_xlog/archive_status/。

（6）    如果你有在步骤 2 里面保存的 WAL 段文件，那么把它们拷贝到 pg_xlog/。 （最好是拷贝它们，而不是把它们移动回来，这样即使发生了糟糕的事情，你需要重启的时候， 你也依然拥有未修改的文件。）

（7）    在集群数据目录里创建一个恢复命令文件 recovery.conf（参阅 Recovery Settings）。 你可能还需要临时修改 pg_hba.conf 以避免普通用户连接，直到你确信恢复已经正常了为止。

（8）    启动 postmaster。postmaster 将进入恢复模式并且继续读取它需要的归档的 WAL 文件。 在恢复过程完成后，postmaster 将把 recovery.conf 改名为 recovery.done （以避免不小心因后面的崩溃再次进入恢复模式）然后开始正常的数据库操作。

（9）    检查数据库的内容以确保你已经恢复到你期望的位置。 如果还没有，回到步骤 1。如果全部正常，则恢复 pg_hba.conf 成正常状态，允许你的用户登录。