pgsql的备份和恢复:备份:
1.pg_dump:(sql转储,类似于mysql的binlog的dump,可以加上压缩如gzip,可以设置压缩级别)备份:pg_dump dbname > outfile
恢复:psql dbname < infile
outfile 和infile是同一个文件
2.pg_dumpall:(sql转储,导出所有的db)
备份:pg_dumpall -f outfile
恢复:psql -f outfile postgres
3.pitr:在线备份,和oracle的归档原理差不多.
archive(归档文件):database manager 把query语句记录在 archive文件里,archive文件一般有多个,有固定大小.采取轮循的方式写.然后到了触发一定条件的时候,如:记录了1个小时的query语句了或者写满了1/2的时候.就执行这些query语句并把结果写到数据文件里.即记录到硬盘中.1.要使用pitr,必须打开pgsql的归档模式(archive)
在postgresql.conf文件中,设置如下:
# - Archiving -
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'cp "%p" /usr/local/pgsql/backup/"%f"'
# command to use to archive a logfile segment
archive_timeout = 60 # force a logfile segment switch after this
# time; 0 is off
2.以postgres身份连接到pgsql
psql 要备份的dbname
3.发出备份命令
select pg_start_backup('label'); --> 备份archive文件.
label --> 备份标签,一般为放置备份文件的全路径.如: /usr/local/pgsql/backup
4.执行备份
用tar或者cpio备份数据文件.此过程中,不用关闭数据库,也不用断开连接.
5.再以postgres身份连接到pgsql
select pg_stop_backup(); --> 终止备份archive文件.
这将终止备份模式,并自动切换到下一个归档文件.这样的好处是可以立即为下次备份做好准备.
4.pitr的即时恢复
1.停止pgsql服务
2.最好copy /usr/local/pgsql/data 到临时位置,以防万一.
3.清理掉data 文件下所有文件,如果用到tablespace,还得清掉表空间目录下的所有文件.
4.用正确的所有者恢复数据库文件.用postgres最好.
5.清理pg_xlog目录里的文件.删掉文件,保留文件夹
6.copy archive文件到pg_xlog文件夹下.
7.在集群数据目录/usr/local/pgsql/data里创建一个恢复命令文件recovery.conf。模版文件recovery.conf.sample在tarball的src里.
restore_cmd --> 恢复的命令
recovery_target_time -->声明恢复到哪个时间戳
recovery_target_xid --> 声明恢复到哪个事物id
recovery_target_inclusive --> 声明是在恢复目标之前还是之后停止.
recovery_target_timeline --> 声明恢复到一个时间线.
还需要临时修改 pg_hba.conf 以避免普通用户连接，直到你确信恢复已经正常了为止。
8.所有这些操作的关键是设置一个恢复命令文件，这个文件描述你希望如何恢复以及恢复应该走到哪里。
你可以使用 recovery.conf.sample(通常安装在安装目录的 share/ 子目录里)作为原型。
你必须在 recovery.conf 里面声明的一个东西是 restore_command ，它告诉系统如何拿回归档的 WAL 文件段。
类似 archive_command ，这个是一个脚本命令字符串。它可以包含 %f ，这个变量会被需要的日志文件名替换，以及 %p ，
它会被要拷贝去的日志文件的绝对路径代替。如果需要在命令里替换真正的 % 字符，那么就双写(%%)。
最简单的有用命令是类似下面的东西
restore_command = 'cp /mnt/server/archivedir/%f %p'这个命令将把以前归档的 WAL 段从 /mnt/server/archivedir 目录拷贝过来。
你当然可以使用某些更复杂的东西，甚至是一个要求操作者挂载合适的磁带的 shell 脚本。
重要的一点是：该命令在失败的时候返回非零值。如果日志文件没有出现在规档中，那么该系统将询问该命令；
在问到的时候，它必须返回非零。这个不是错误条件。还要注意 %p 路径的基础名将和 %f 不一样；不要认为它们是可以互换的。
在归档中找不到的 WAL 段将被认为在 pg_xlog/ 里；这样就允许使用最近没有归档的段。
但是在归档中的段将比 pg_xlog/ 中的优先。在检索归档文件的时候，系统将不会覆盖现有的 pg_xlog/ 内容。
通常，恢复将处理所有可用的 WAL 段，因此将把数据库恢复到当前时间(或者是在所给出的可用 WAL 段数的情况下，
我们能走到的最近的地方)。但是如果你想恢复到某些以前的时刻点(比如，在菜鸟 DBA 删除你的主要事务表之前)，
那么只需要在 recovery.conf 里声明要求的停止点。你可以通过日期/时间来声明，也可以通过特定事务 ID 的结束来声明这个停止点，
我们叫做"恢复目标"。目前，只有日期/时间选项比较有用，因为我们没有工具来帮助你精确地标识应该使用哪个事务 ID
【注意】请注意停止点必须在备份的终止时间之后(也就是 pg_stop_backup 的时间)。
你无法使用一个基础备份恢复到备份正在进行中的某个时刻。要想恢复到该时刻，你必须回到你以前的基础备份，然后从那个位置向前滚动。
如果在恢复过程中发现在 WAL 数据中存在错误，那么恢复将在错误的地方停止，并且不会启动服务器。
在这种情况下，可以指定一个位于错误点之前的"恢复目标"，然后从起始点开始重新运行恢复进程，这样恢复就可以正常完成。
如果由于外部原因(系统崩溃、无法读取 WAL 归档)导致恢复失败，那么可以简单的重新启动恢复过程即可，它将从上次失败的地方继续。
重新启动恢复过程与检查点的操作非常类似：
服务器周期性的强制将其状态记录到磁盘上并更新 pg_control 文件以标识已经处理的 WAL 数据不需要被再次扫描。