2.1 创建一个需要恢复对象表tbl_lottu_drop。并插入1000记录。也保证数据从数据缓存写入磁盘中。
2.2 这个获取一个时间：用于后面基于数据库PITR恢复(当然现实操作后只能记住一个大概的时间；还往往是不准；可能记住的时间是误操作之后。后面有讲解如何获取需要恢复到那个时间点)
2.3 进行drop表
2.4 后续进行dml/ddl操作；表明正式数据库还是进行正常工作
3、恢复操作3.1 将备份拷贝到Postgres202数据库上
3.2 删除不必要的文件
3.3 还原备份表空间软链接
3.4 将wal日志拷贝到Postgres202数据库上pg_xlog目录下；从哪个日志开始拷贝？
查看backup_label；知道00000003000000000000000F开始到正在写入的wal日志。
3.5 编辑recovery.conf文件
3.6 启动数据库；并验证数据
从这看数据是恢复了；copy到线上数据库操作略。
延伸点下面讲解下如何找到误操作的时间。即recovery_target_time = '2018-04-28 20:47:31.617808+08'的时间点。上文是前面已经获取的；
1. 用pg_xlogdump解析这段日志。
2. 从lottu.log中可以找到这段日志
根据“32784”日志可以看到是表tbl_lottu_drop在2018-04-28 20:46:37.718442插入1000条记录(所以恢复时间点选2018-04-28 20:47:31.617808+08没毛病)；即也是在事务id为1690操作的。并在事务id为1691进行删除操作。
所以上面的recovery.conf 也可以改写为：
补充：PostgreSQL多种恢复实例分析
Postgresql归档恢复实例分析(时间线机制)
这篇文章根据实例介绍Postgresql归档恢复的方法，时间线的含义。
1 参数配置 2 数据操作 3 制作基础备份配置pg_hba.conf通道
4 数据库上继续进行业务操作（模拟在基础备份后，业务继续下发，然后发生故障）时间轴（第三行的缩写代表Create Insert）
情况1
没有设置archive_timeout，整个数据目录被删除
5 数据目录被rm -rf掉了（模拟误操作） 6 归档恢复修改pg_hba.conf阻止用户连接
7 恢复结果test02存在，但是其中的数据被认为是未提交事务，表为空（最后一个xlog文件的内容全部遗失了）。
情况2
设置archive_timeout，整个数据目录被删除，归档timeout为60s，在test02表数据灌入之后，xlog自动切换并归档
5 数据目录被rm -rf掉了（模拟误操作） 6 归档恢复修改pg_hba.conf阻止用户连接
7 恢复结果test02存在，数据也存在（由于归档设置了超时切换，最后一个xlog会被归档）。
情况3（重要）
设置archive_timeout，根据估计时间点尝试多次恢复，不能确定想恢复到具体哪个时间点，归档timeout为60s
5 数据目录被rm -rf掉了（模拟误操作） 6 归档恢复修改pg_hba.conf阻止用户连接
(1) recovery_target_time = ‘2017-4-1 10:09:47' （基础备份时间之前）
结果：
恢复时间定到了基础备份之前，所以这里会恢复到最早时间点：基础备份点。
注意：无法恢复到基础备份之前的点，所以再做基础备份时，请保证数据一致性。
(2) recovery_target_time = ‘2017-4-1 10:10:00' （基础备份时间之前）
结果：
恢复时间定到了基础备份之前，所以这里会恢复到最早时间点：基础备份点。
注意：无法恢复到基础备份之前的点，所以再做基础备份时，请保证数据一致性。
(3) recovery_target_time = ‘2017-4-1 10:16:00'
结果：
表test02存在，但没有数据。说明如果时间在基础备份点之后，可以恢复到任意时间点。恢复后会创建新时间线。
(3.1) 在(3)的基础上继续进行恢复：recovery_target_time = ‘2017-4-1 10:17:00'
结果：
同3，这次恢复创建了一条新的时间线3，这条时间线上面进行恢复的话，数据库会去archive里面去找时间线2的xlog，但是归档目录中的日志应该都是时间线1的，所以会报错找不到xlog。
注意： 根据上述结论，请在每次恢复时都使用原始归档文件，即如果尝试再次恢复，请重新使用基础备份进行恢复，不要在前一次恢复的基础上继续进行，否则由于时间线切换，会找不到归档文件。
其他压缩的归档日志
1、recovery.conf（几个重要参数）Postgresql9.6手册（彭煜玮翻译）
restore_command (string)
用于获取 WAL 文件系列的一个已归档段的本地 shell 命令。这个参数是归档恢复所必需的，但是对于流复制是可选的。在该字符串中的任何%f会被替换为从归档中获得的文件的名字，并且任何%p会被在服务器上的复制目标路径名替换（该路径名是相对于当前工作目录的，即集簇的数据目录）。任何%r会被包含上一个可用重启点的文件的名字所替换。在那些必须被保留用于使得一次恢复变成可重启的文件中，这个文件是其中最早的一个，因此这个信息可以被用来把归档截断为支持从当前恢复重启所需的最小值。%r通常只被温备配置（见Section 26.2）所使用。要嵌入一个真正的%字符，需要写成%%。很重要的一点是，该命令只有在成功时才返回一个为零的退出状态。该命令将会被询问不存在于归档中的文件名，当这样被询问时它必须返回非零。
recovery_target_time (timestamp)
这个参数指定恢复将进入的时间戳。
recovery_target_xid (string)
这个参数指定恢复将进入的事务 ID。记住虽然事务 ID 是在事务开始时顺序分配的，但是事务可能以不同的数字顺序完成。那些在指定事务之前（也可以包括该事务）提交的事务将被恢复。精确的停止点也受到recovery_target_inclusive的影响。
recovery_target_timeline (string)
指定恢复到一个特定的时间线中。默认值是沿着基础备份建立时的当前时间线恢复。将这个参数设置为latest会恢复到该归档中能找到的最新的时间线，这在一个后备服务器中有用。除此之外，你只需要在复杂的重恢复情况下设置这个参数，在这种情况下你需要返回到一个状态，该状态本身是在一次时间点恢复之后到达的。相关讨论见Section25.3.5
2、关于时间线Postgresql9.6手册（彭煜玮翻译）
将数据库恢复到一个之前的时间点的能力带来了一些复杂性，这和有关时间旅行和平行宇宙的科幻小说有些相似。例如，在数据库的最初历史中，假设你在周二晚上5：15时丢弃了一个关键表，但是一直到周三中午才意识到你的错误。不用苦恼，你取出你的备份，恢复到周二晚上5：14的时间点，并上线运行。在数据库宇宙的这个历史中，你从没有丢弃该表。但是假设你后来意识到这并非一个好主意，并且想回到最初历史中周三早上的某个时间。你没法这样做，在你的数据库在线运行期间，它重写了某些WAL段文件，而这些文件本来可以将你引向你希望回到的时间。因此，为了避免出现这种状况，你需要将完成时间点恢复后生成的WAL记录序列与初始数据库历史中产生的WAL记录序列区分开来。
要解决这个问题，PostgreSQL有一个时间线概念。无论何时当一次归档恢复完成，一个新的时间线被创建来标识恢复之后生成的WAL记录序列。时间线ID号是WAL段文件名的一部分，因此一个新的时间线不会重写由之前的时间线生成的WAL数据。实际上可以归档很多不同的时间线。虽然这可能看起来是一个无用的特性，但是它常常扮演救命稻草的角色。考虑到你不太确定需要恢复到哪个时间点的情况，你可能不得不做多次时间点恢复尝试和错误，直到最终找到从旧历史中分支出去的最佳位置。如果没有时间线，该处理将会很快生成一堆不可管理的混乱。而有了时间线，你可以恢复到任何之前的状态，包括早先被你放弃的时间线分支中的状态。
每次当一个新的时间线被创建，PostgreSQL会创建一个“时间线历史”文件，它显示了新时间线是什么时候从哪个时间线分支出来的。系统在从一个包含多个时间线的归档中恢复时，这些历史文件对于允许系统选取正确的WAL段文件非常必要。因此，和WAL段文件相似，它们也要被归档到WAL归档区域。历史文件是很小的文本文件，因此将它们无限期地保存起来的代价很小，而且也是很合适的（而段文件都很大）。如果你喜欢，你可以在一个历史文件中增加注释来记录如何和为什么要创建该时间线。当你由于试验的结果拥有了一大堆错综复杂的不同时间线时，这种注释将会特别有价值。
恢复的默认行为是沿着相同的时间线进行恢复，该时间线是基础备份创建时的当前时间线。如果你希望恢复到某个子女时间线（即，你希望回到在一次恢复尝试后产生的某个状态），你需要在recovery.conf中指定目标时间线ID。你不能恢复到早于该基础备份之前分支出去的时间线。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方，望不吝赐教。
