Anu*_*ama 3 postgresql replication
我有一个 postgres 9.1 主服务器和 2 个从服务器，设置了带有 WAL 存档的流式复制。
现在，我正在尝试为 PITR 设置至少 1 周的窗口期。这是为了弥补任何管理错误（例如错误地删除重要的表）。这是我对 PITR 的理解
使用上面的 2 个方法，我们可以将数据库重建到中间的任何点。
涉及的数据库很大，大约1TB，每周增长30GB
我想了解在运行实例上实现快速基础备份创建和低性能开销的最佳方法是什么。我可以想到以下替代方案，但不确定
如果有其他更好的选择
是每周进行一次基本备份并累积 WAL 直到下一次基本备份还是只进行一次基本备份（比如现在）并每周只备份 WAL 更好。
如果我们每周都进行基础备份，那么使用 pg_basebackup 或 pg_start_backup + rsync + pg_stop_backup 更好。如果我由于 rsync 而每周使用相同的目标磁盘/卷/文件夹，第二个选项会明显更快吗？
是否最好对主服务器运行基本备份，或者是否可以在暂时停止其中一个从服务器并在快照后恢复复制后拍摄 postgres 集群的磁盘快照。如果我想要执行 PITR，此快照是否可用于在恢复模式下设置实例，或者是否会出现任何数据一致性或时间线问题？
感谢您的任何见解。
有几种方法可以做你想做的事。
我建议使用特定的解决方案，例如WAL-E、barman或OmniPITR，以便自己更轻松地管理 Basebackups 和 WAL 存档，或者使用 pg_basebackup 。其中一些工具（取决于版本）将允许您备份副本，这将减少主服务器上的负载，并且不会将数据从文件系统缓存中推出，这些都是非常好的事情。
正如您所期望的，您的方法肯定有利有弊。
对于第一个问题，您必须考虑到，如果您采用单个基本备份并继续归档 WAL 段，则随着您归档的每个 WAL 段，恢复时间会变得更长，因为恢复每个文件需要大量时间。因此，这并不理想，大多数人倾向于按计划进行备份，以满足恢复要求，有时会在存储分配允许的情况下保留多个基本备份。此外，对于非常非常大的 WAL 归档，有时单个 WAL 段可能会发生一些情况（这就是为什么您总是测试备份），并且如果 WAL 段无法恢复，则后续段将不会恢复，并且您运气不好。
我自己听到并使用的一条一般规则是，如果我每周进行基本备份，保留大约 3 周的 WAL 段和 2 个基本备份，可以让我安心地拥有至少一个已知良好的备份，以及一组已知良好的备份。 WAL，以及相当合理的恢复时间。我非常相信定期测试我所做的备份。
对于你的第二个问题，任何一个都可以很好地工作，但是 pg_basebackup 更容易使用并且需要更少的你自己的程序集。如果您在自己的脚本中使用 rsync 来启动和停止 Basebackup，则必须检查每个命令的退出代码。如果不这样做并且命令失败，您最终可能会得到一个无用的损坏的基本备份。上述工具与 pg_basebackup 一起为您处理所有这些迂腐的细节。
对于你的第三个问题，在某些情况下，是的，你可以从副本而不是主副本上进行备份。如果您可以管理它，那么执行基本备份并归档副本是可行的方法，因为进行基本备份会生成大量 I/O，并且会影响您的操作系统文件系统缓存。不幸的是，直到 9.2+ pg_basebackup 才支持它，因此您需要使用外部工具（例如 OmniPITR）或升级 PostgreSQL 版本。只要您有 WAL 与之配合，副本中的快照就不应该出现任何时间线问题或一致性问题。
最后，Magnus Hagander 在 PgCon 2013 上的演讲涵盖了您的许多问题和最佳实践：PostgreSQL 备份策略
花时间观看视频是非常值得的。
希望有帮助。=)