如何进行常规的数据库备份与恢复
pg_dump命令备份，psql直接恢复 e.g. pg_dump dbname |psql dbname
或者采用归档模式dump，然后用pg_restore恢复
pg_dump -Fc dbname > filename
pg_restore -d dbname filename
归档模式备份的好处是可以直接从备份文件中恢复某一个表或者用-j参数并行恢复
e.g.pg_dump -j num -F d -f out.dir dbname
如何进行数据库基础备份
这里说的基础备份实际上指的是continuous archiving base backup。这样的基础备份允许数据库在备份的同时发生变化，并保留所有变化相关的wal log。这样系统在restore的时候可以通过这些wal恢复到备份结束的时间点。之所以说archiving base backup和pg_dump产生的备份不同，是因为dump出来的备份并不需要包含索引、约束等信息，这部分数据是后来重建的，而archive backup包含这些信息，因此它通常比dump文件大得多。
pg提供了两种方式获取一份基础备份：
pg_basebackup
pg内置的工具，运行时对集群操作无影响，产生的备份可用于PITR或者生成从库。这个工具会对整个数据目录进行一个二进制备份，包括目录下的所有的文件、文件夹、配置文件和第三方文件。但是这些仅指物理文件，不包括软连接。如果是在从库上对主库运行该命令，并且权限配置正确的话，在备份完毕以后，程序会自动利用replication协议起一个pg连接，将文件发送到从库的指定目录。
low level AP
上面的工具是懒人的一揽子解决方案，如果你希望采用更灵活的方式来备份的话，可以选用传统的API方式来完成
采用low level API方式需要遵循以下步骤
检查确保wal archive正常运行
运行如下命令
SELECT pg_start_backup('label');这里面的label仅用于标记，一般我们会把备份文件的绝对路径作为label。这个命令通常会运行比较久的时间，因为他会先运行一下checkpoint，将所有数据刷到硬盘上。当然了，为了更快完成这个指令，我们也可以有些别的设置
SELECT pg_start_backup('label', true);这样会强制checkpoint尽可能快的执行完毕
用任意你熟悉的备份工具比如tar或者cpio对数据目录进行备份。当然了，这个工作是在不影响现有系统运行的情况下执行的。这种备份方式的灵活主要体现在这一步，因为备份的时候可以指定不包含某些文件。比如我不需要包含所有的日志文件，也不需要包含postmaster.pid 、 postmaster.opts这些现有系统的运行时记录文件等等。
备份完毕后，运行如下指令
SELECT pg_stop_backup();
这个指令告诉系统备份终止，并且强制生成一个新的wal log。之所以生成新log是为了方便将备份是所产生的wal log进行归档，用于将来的恢复
整个备份的结束是以所有备份期间的wal log归档完毕为标志的。如果我们将系统设置为归档模式，那么在最后一个wal被归档成功之前，pg_stop_backup是不会返回的。
时间线的概念
这个概念来源于现在很时髦的平行宇宙说。pg认为每发生一次系统的recovery，就产生了一个时间节点，以此为入口，系统恢复前的运行轨迹和恢复后的运行轨迹分成了两条平行的时间线。他们共同存在，互不影响，是存在于四维时间轴上的两个不同分支。让我来举一个例子说明时间线的重要性，假如一个数据库1号的时候运行在时间线A上，到了2号突然发现因为某些原因需要回滚到1号中午的时间点，那么回滚以后，他就运行到了新的时间线B上，如果在B上运行了一段时间又发现回滚是个错误的决定，系统还是要还原到时间线A上去。在没有时间线概念的情况下会发生什么呢，A时间线上的wal log可能已经被判为无用而回收重写了，系统再也回不到时间线A的状态了。但是有了时间线的概念呢，所有的wal都会跟着时间线走，不同时间线的log不会相互覆盖，我们随时可以还原到分支节点前后的任意位置。
针对上面的例子，还有一个需要注意的问题。就是系统在恢复的时候，一般是默认恢复到备份本身所在的时间线上的。当然，你也可以恢复到备份的子时间线上，比如上例中1号做的基础备份就会用于A、B两条子时间线，那么恢复的时候需要在recovery文件中明确指出需要恢复到哪个时间线。
