我正在阅读以下article 来设置 PITR。我感到困惑的一件事是，为什么文章建议在设置连续 WAL 归档后执行 basebackup（完整集群备份）。我以为 WAL 是实际数据？因此，如果我从 t=0 开始就有 WAL，为什么我需要任何其他备份？我在另外两个 postgres 社区中询问过，但对这一点的回应是“因为在实践中，从 t=0 开始你就不会拥有 WAL”，或者对于为什么两者都真正需要这两者有点未知。无论如何只是好奇，谢谢！
【问题讨论】：
标签： postgresql archive wal pitr
WAL 包含如下信息：“在文件 X 中，块 Y，在偏移量 z 处写入这 13 个字节”或“将文件 X 扩展 1 个 8kB 块”。
你总是需要一些可以恢复 WAL 的起点：
采用崩溃恢复，即最新的检查点，其位置写入控制文件。
使用 PITR，检查点取自运行基本备份时创建的 backup_label 文件，其中包含启动备份的检查点。
如果你没有一个起点，你怎么能恢复？
也许你的误解是数据库最初是空的，所以你需要的只是一开始的 WAL 文件。但这不是真的：即使在 initdb 之后，数据库已经包含目录表和元数据。
【讨论】：
存在一个伪随机Database system identifier，它因数据库系统而异。这记录在 pg_controldata 和每个 WAL 段中，并且必须匹配才能将 WAL 重播到服务器中。在我的手中，多次运行 initdb 会给出与 pg_controldata 和 pg_wal/000000010000000000000001 （当然还有文件系统时间戳）的内容相同的目录。
因此，如果您想在玩电锯时遇到交通拥堵，您可以跳过基本备份，然后只运行一个新的 initdb 并尝试将系统标识符改型到新的 pg_controldata 文件中。
享受自爆的乐趣。如果成功，您的奖励将不必进行初始基本备份，该备份压缩到 1.35MB。
这是在 pg_upgrade 之后立即出现的实际问题。新系统必须被视为易受攻击，直到采用新的基本备份（可能比 1.35MB 大得多且慢得多）。如果您使用pg_upgrade -k，这个新的基本备份可能构成完成升级所需的大部分时间窗口。
【讨论】：