www.876873.xyz

阶段一：物理环境隔离与契约建立 (Initialization)

• 前因： 灾难恢复的工程基线要求备份数据必须脱离当前运行主机的故障域。同时，备份工具需要独立管理自身的元数据、压缩配置和保留策略。
• 执行过程： 1. 执行 pg_probackup init 和 add-instance。 2. 工具在指定的外部存储路径上调用 Linux mkdir 系统调用，建立严格的目录层级：包含存放数据块的 backups/ 目录，以及专门用于存放归档日志的 wal/ 目录。 3. 生成 pg_probackup.conf，确立连接源数据库的通信协议（本地 Socket 或 SSH）和路径映射。
• 物理结果： 构建了一个独立于 PostgreSQL 守护进程（postmaster）的静态物理存储架构。

阶段二：建立物理一致性基线 (Full Backup)

• 前因： 任何增量备份都必须依赖一个起始时间点。该时间点的数据文件必须是完整、物理一致且未损坏的。
• 执行过程：
  1. 打下时空锚点： 主控进程通过 libpq 协议连接 PostgreSQL，下发 SELECT pg_start_backup()。该指令在数据库内核中触发强制检查点（Checkpoint），迫使 shared_buffers 中的脏页立刻刷入物理磁盘（调用 write 和 fsync）。随后，内核在 WAL 流中记录此时的绝对字节偏移量，即 Anchor LSN（基础日志序列号）。
  2. 多进程旁路读取： pg_probackup 主进程调用 fork() 产生多个工作进程（Worker）。为了防止海量数据读取导致 PostgreSQL 共享内存池（shared_buffers）被击穿，Worker 进程直接利用 Linux 文件描述符，调用 pread() 函数，绕过数据库内存，直接从文件系统中并行读取底层数据文件。
  3. 硬件级防腐校验： 每次 pread() 读取 8192 字节（一个标准 PG 数据页）到内存后，Worker 进程会读取页头的 pd_checksum 字段。随后调用 CPU 的 SSE4.2 硬件指令集对该 8KB 数据重新计算 CRC32C 校验码并进行比对。若不一致，判定为静默损坏（Torn Page），立即中断备份；若一致，则调用 zlib/lz4 算法压缩落盘。
  4. 释放拦截： 调用 pg_stop_backup() 获取结束 LSN。
• 物理结果： 获得了一个时间点定格在 Anchor LSN、经过逐页完整性校验且被高度压缩的全量数据副本。