Azure PostgreSQL Point In Time Restore失效 还原后数据与当前库一致咨询

Azure PostgreSQL的PITR（时间点还原）功能基于连续WAL日志和定期全量快照生成还原实例，出现所有时间点还原结果都和当前运行库一致的问题，通常是以下操作遗漏导致：

• 未确认还原的目标实例是否为新生成的独立实例
  操作时容易误把当前生产实例的只读副本、或者之前生成的旧还原实例当成本次的还原结果访问，建议先在Azure门户的PostgreSQL实例列表中核对本次还原生成的实例名称、创建时间，确认访问的是本次新生成的还原实例，而非原生产库。
• 未确认PITR还原的源实例选择正确
  如果订阅下存在多个同名、或者配置相似的PostgreSQL实例，操作时可能误选了其他无数据删除操作的实例作为还原源，导致还原出来的内容一直是对应实例的当前状态。建议返回还原操作页，再次核对源实例的资源ID、名称、资源组信息是否为故障发生的实例。
• 未确认数据库的备份保留周期配置
  Azure PostgreSQL的备份保留期默认是7天，灵活服务器可手动调整最长35天。如果你选择的还原时间点已经超出了该实例的备份保留周期，Azure会默认使用备份保留期内最早的可用备份进行还原，如果数据删除操作发生在最早可用备份时间之前，就会出现所有还原结果都已经是删除后的状态。你可以在源实例的「备份」配置页查看实际的备份保留时长，确认你选择的05-05-21 11:50 PM是否在保留范围内。
• 未排除误操作重复执行数据删除的可能性
  如果你的生产库配置了自动化脚本（比如定时清理脚本、ETL作业），且该脚本也同步配置到了还原后的实例上，会导致还原完成后脚本自动执行再次删除目标表数据，看起来就像还原结果和当前库一致。建议还原完成后第一时间停止实例的所有外部连接、暂停所有自动化作业，再查询表数据验证结果。
• 未核对日志确认数据删除的真实发生时间
  你记录的故障发生时间06-05-21 10:30 AM可能和实际数据删除的执行时间有偏差，如果删除操作实际发生的时间远早于你记录的时间，你选择的10:25 AM的还原点本身就已经是数据删除后的状态。你可以查询PostgreSQL的pg_stat_statements模块、或者Azure门户的「日志」面板搜索DROP TABLE、DELETE相关的执行记录，确认准确的删除时间，再选择对应时间之前的还原点重试。
• 未确认是否使用了只读快照而非PITR还原
  部分用户会混淆Azure的实例快照功能和PITR功能，如果是基于删除后的时间点生成的快照进行还原，自然所有还原结果都是数据删除后的状态，确认你操作的入口是源实例「备份」页的「还原」按钮，而非快照列表的还原入口。

内容的提问来源于stack exchange，提问作者Jeroen van Heel