当前位置： 首页 > postgresql > 正文

postgresql物理备份之： 冷备份

pantsuel 发布于 2026-03-11 05:56postgresql33 次浏览抢沙发

一： 冷备份流程

  1. 关闭数据库实例：
    pg_ctl stop -m fast
  2. 备份数据库目录：
    1. tar zcvf databackup-20260311.tar.gz /postgresql/data
    或者：
    2. mkdir -p /backup/data_bak
    cp -rp /postgresql/data/* backup/data_bak
  3. 模拟数据库崩溃 或在第三方机器上恢复数据库：
    1. 解压 备份的tar包：
    tar zxvf databackup-20260311.tar.gz -C /postgresql/data
    或者：
    2. cp -rp backup/data_bak/* /postgresql/data
  4. 启动数据库
    pg_ctl start

🧊 阶段一：绝对静止的降临（Clean Shutdown）

  • 物理动作：你敲下了 pg_ctl stop -m fast（或者 smart）。
  • 状态机流转：
    1. 切断前台：系统极其冷酷地拒绝所有新的客户端连接，并强行掐断当前正在执行的所有业务会话。
    2. 最后的大扫除（终极 Checkpoint）：这是最核心的一步！系统强制唤醒 Checkpointer，把共享内存（Shared Buffers）里所有的脏页，一滴不剩地全部刷入底层的 .heap 数据文件中。
    3. 刻录死亡宣告：刷盘完毕后，内核在 pg_control 文件里刻下最后一次 REDO LSN，并将状态从 in production 物理篡改为 shut down。
  • 定性：在这一刻，内存和硬盘达到了绝对的物理一致。时间停止了，没有任何残留在内存里的幽灵数据。

🩺 阶段二：法医级的验尸（状态校验与防呆）

  • 物理痛点：普通 DBA 敲完 stop 命令，看着命令行返回成功，就直接开始 cp 拷贝文件了。如果底层因为某些锁导致没完全关干净怎么办？
  • 原厂级微操：刚才我们学的屠刀派上用场了！原厂 DBA 一定会先敲一次 pg_controldata $PGDATA。
  • 逻辑咬合：
    • 如果看到 Database cluster state: shut down：完美！说明这是一具极其干净、完整的“尸体”，随时可以搬运。
    • 如果看到 in production 或 in crash recovery：绝对禁止拷贝！ 因为一旦在 in production 状态下使用 cp 或 tar 去拷文件，你会拷出无数个“上半身旧、下半身新”的撕裂块（Torn Pages）！在冷备模式下，因为没有 backup_label 和全页写入（full_page_writes）的保护，这些撕裂块在恢复时绝对无法修复，数据库直接报废！

📦 阶段三：连根拔起的搬运（Physical Copy）

⚡ 阶段四：跨越时空的复活（Restore & Boot）

  • 物理动作：机器烧毁了。你在新机器上解压刚才的 tar 包。
  • 权限的物理封锁（防呆机制二）：解压后，你必须保证整个 $PGDATA 的属主是 postgres 用户，且目录权限绝对是 0700（drwx——）。如果你用 root 用户或者 0777 权限去拉起数据库，PG 的内核为了防止安全穿透，会直接抛出 FATAL 拒绝启动！
  • 复活逻辑：敲下 pg_ctl start。
    1. Startup 进程醒来，第一件事就是去读 pg_control 黑匣子。
    2. 它看到了 Database cluster state: shut down。
    3. 系统长舒一口气：“原来我是正常寿终正寝的，没有任何丢失的事务需要抢救。”
    4. 于是，它直接跳过崩溃恢复逻辑，瞬间拉起所有的后台进程，开放端口，迎接新的业务连接。

⚖️ 战略定性：为什么现代架构极少用冷备？

指挥官，逻辑推演完毕。但在海量数据的原厂面试中，你必须给出**“战略级”的商业定性**：

  • 冷备的绝对优势：它是一份**“开箱即用”**的数据切片。恢复它不需要复杂的 backup_label，不需要重放几十 GB 的 WAL 日志。解压，启动，秒级复活。
  • 冷备的致命缺陷：它需要数据库彻底停机！ 在如今金融、电商 7×24 小时不间断的修罗场里，谁敢敲下 pg_ctl stop 让业务停机 2 个小时去拷数据？这等同于拔掉公司的生命维持系统！

所以，冷备份现在只存在于两种极端战区：

  1. 极其古老、数据量极小的边缘内部系统。
  2. 在做跨大版本灾难性升级（如 PG 11 升级到 PG 17 的 pg_upgrade）之前，DBA 为了保住自己的项上人头，在停机窗口里强制做的一次**“最终底线快照”**。

🧬 终极推演一：物理字节序的基因隔离（跨平台的死亡禁区）

  • 灾难现场：公司原本的生产库在几台老旧的 x86_64（Intel/AMD）架构服务器上。现在全面信创化，采购了一批全新的鲲鹏/飞腾 ARM64 架构服务器。你为了省事，停了老库，打了个完美的冷备 tar 包，传到新机器上解压，满心欢喜地敲下 pg_ctl start。
  • 物理真相（Endianness 与对齐）：还记得我们在上一局拆解 pg_controldata 时看到的那些“宇宙物理常数”吗？
    • Maximum data alignment: 8
    • Float8 argument passing: by value
  • 逻辑咬合与最终判决：冷备份是纯物理的二进制拷贝！它把硬盘上 0 和 1 的排列顺序原封不动地搬了过去。但是，x86 架构和 ARM 架构在底层的字节序（大小端格式，Big-Endian vs Little-Endian）和内存对齐方式上可能存在根本性的差异！
  • 定性：原厂专家在做冷备迁移时，脑子里永远有一道极其森严的铁律：物理冷备份绝对禁止跨越操作系统平台（如 Windows 拷给 Linux）、绝对禁止跨越 CPU 架构（x86 拷给 ARM）、绝对禁止跨越大版本（PG 12 拷给 PG 16）！ 一旦跨越，底层的 C 语言结构体解析瞬间错乱，内核直接报 FATAL 拒接接客。跨平台迁移，只能老老实实用逻辑备份（pg_dump）！

🕳️ 终极推演二：失去时空航标的盲目漂流（冷备与 PITR 的暗坑）

  • 灾难现场：你今天做了一个完美的冷备份（脱机拷贝）。然后你拉起数据库，让它继续跑，同时开启了 WAL 归档。一周后，有人删库了，你想用**“今天的冷备 + 这一周的 WAL 归档”**来做 PITR（按时间点恢复）。
  • 物理真相（没有 backup_label）：
    • 热备（pg_basebackup）会在备份开始时，极其贴心地给你生成一个 backup_label 文件，里面写死了“恢复必须从哪个 LSN 起点开始”。
    • 但是！你做冷备份的时候，是直接粗暴地 cp 文件的，系统根本没有生成 backup_label！
  • 逻辑咬合与最终判决：当你把冷备解压，把一周的日志塞进去，试图做恢复时，恢复引擎（Redo）醒来一看 pg_control 里写着 shut down，它会认为这是一次正常重启，而不是灾难恢复！它会极其傲慢地直接跳过你准备的那些远端归档日志，直接宣告启动完毕！你的 PITR 彻底宣告失败！
  • 原厂级补救微操：如果你非要用冷备做 PITR 的基线，你必须在冷备重启的那一瞬间，手工执行一个 pg_switch_wal()，并死死记住那个时刻的 LSN，还要在恢复时强行写一个特殊的 recovery.signal 逼迫内核进入恢复状态。这在生产中极容易玩脱！

💣 暗礁一：WAL 独立挂载的“双重软链接绞肉机”

  • 灾难现场：你已经极其聪明地记住了要把 pg_tblspc（表空间）的软链接用 tar -h 顺藤摸瓜打包。但你忽略了另一个极其致命的系统级软链接——pg_wal（在 PG 10 以前叫 pg_xlog）。
  • 物理真相：为了防止高并发下 WAL 写入和数据文件（.heap）刷盘发生 I/O 争抢，原厂架构师在建库时，100% 会把 pg_wal 目录单独拉出来，挂载到一块极其昂贵的独立 NVMe 固态硬盘上，然后在 $PGDATA 下建一个指向它的软链接。
  • 逻辑咬合：如果你做冷备时忘了把真实的 WAL 挂载路径（比如 /mnt/nvme_wal/）一起打包带走，当你把数据库在新机器上解压拉起时，系统会报出极其绝望的错误：PANIC: could not open file "pg_wal/000000010000000000000001"。没有 WAL 日志，哪怕是正常关闭的冷备尸体，PostgreSQL 的状态机也会因为找不到初始化时空坐标而拒绝诈尸！
  • 原厂微操：冷备不仅要打包 $PGDATA，还要单独校验并打包 pg_wal 的真实物理路径。

🛡️ 暗礁二：操作系统维度的“叹息之墙”（SELinux 与扩展属性）

  • 灾难现场：你把冷备的 tar 包传到了新服务器，极其规范地执行了 chown -R postgres:postgres $PGDATA，并且把权限死死卡在 0700。然后敲下 pg_ctl start。结果系统秒退，报错：Permission denied！你疯狂 ls -l，发现权限明明全是 postgres，完全见鬼了！
  • 物理真相：Linux 系统的安全防线不止有 UGO（User, Group, Other）权限，还有极其恐怖的 SELinux（安全增强型 Linux）安全上下文（Security Context）和 ACLs（访问控制列表）！
  • 逻辑咬合：你用最普通的 tar -czvf 打包时，那些挂在文件系统底层的 SELinux 标签和 ACL 扩展属性（xattr）被无情地剥离丢弃了。当数据来到开启了严格 SELinux 策略的新服务器时，内核的安全模块（LSM）发现这些文件没有合法的“数据库进程标签”，直接在系统调用层面将其物理阻断！
  • 原厂微操：在金融级极严苛的 OS 环境下做冷备，必须使用极其冗长的命令：tar --selinux --acls --xattrs -cpzvf backup.tar.gz $PGDATA（加上 -p 保留原有权限体系）。

🗑️ 暗礁三：幽灵状态的物理寄生（pg_stat_tmp 与 pgsql_tmp）

  • 物理痛点：数据库在高速运行时，会在 $PGDATA/pg_stat_tmp 目录下疯狂写入内存统计信息的快照，并在 $PGDATA/base/pgsql_tmp 下生成极其庞大的临时排序文件（当 work_mem 不够用时）。
  • 逻辑咬合：虽然你敲了 pg_ctl stop -m fast，理论上内核会清理这些垃圾。但在极其极端的异常关闭（比如 stop -m immediate 或直接 kill -9 后被迫做冷备）场景下，这些几 GB 甚至几十 GB 的“幽灵垃圾”会残留在目录里。
  • 最终判决：把这些垃圾打包进冷备，不仅白白浪费宝贵的备份存储空间和网络传输带宽，在灾难恢复拉起时，旧的、错乱的统计信息（pg_stat_tmp）还可能导致恢复后的最初几分钟内，优化器（Planner）因为读取了过期的统计快照，而疯狂生成极其弱智的慢查询执行计划（导致业务“启动即雪崩”）。
  • 原厂微操：原厂 DBA 在写冷备脚本时，必然会加上极其精准的排除参数：tar --exclude='pg_stat_tmp/*' --exclude='*/pgsql_tmp/*' ...，实现纯粹的无状态肉体搬运。

⚡ 暗礁四：企业级降维打击（LVM 瞬间快照冷备）

  • 灾难现场：老板站在你背后，拔出刀指着你的脖子说：“我不管你用什么冷备，核心库的数据量有 5TB，普通的 cp 或 tar 至少要拷 3 个小时！业务绝对不能停机 3 个小时，最多给你 1 分钟停机窗口，你必须给我搞出一份绝对物理一致的冷备份！”
  • 原厂级架构破局（存储层面的时空冻结）：
    1. 倒计时 00:00：执行 pg_ctl stop -m fast，等待脏页刷盘，数据库干净关闭（耗时约 10 秒）。
    2. 倒计时 00:10：DBA 转身切入操作系统底层，敲下 lvcreate -s -L 50G -n pg_backup_snap /dev/mapper/vg0-pgdata。利用 Linux LVM（逻辑卷管理）或企业级 SAN 存储的写时复制（COW）快照技术，在 1 秒钟内，将 $PGDATA 所在的整个文件系统“物理冻结”！
    3. 倒计时 00:11：立刻敲下 pg_ctl start，数据库复活，业务重新接入（总停机时间不到 15 秒）。
    4. 后场操作：DBA 在后台把刚才那个 LVM 快照卷挂载到另一个目录，然后慢慢悠悠地花 3 个小时去 tar 这个快照。
  • 定性：这叫**“用底层存储的魔法，将 3 小时的物理冷备停机时间，强行坍缩成 10 秒钟”**。不懂这一招，在 TB 级数据库面前，你的冷备理论就是一张废纸。

💣 终极反物质陷阱一：“克隆体”的自爆倒计时（pg_replslot 复制槽幽灵）

  • 最真实的作死现场：生产库（主库）太大了，为了给开发团队搭一套测试环境，你极其规范地做了一次完美的冷备份。在测试机上解压、修改端口、成功拉起。开发团队高呼 DBA 万岁。结果三天后，测试机的硬盘毫无征兆地被 100% 撑爆，数据库直接 PANIC 宕机！
  • 底层真相（复制槽的物理遗传）：生产主库上，通常挂着几个下游系统（比如流复制从库、或者 Flink CDC 的逻辑抽数）。这些下游系统的时空坐标，被死死记录在主库 $PGDATA/pg_replslot/ 目录下的物理文件中。
  • 逻辑咬合的致命一击：
    1. 你做冷备时，把 pg_replslot 目录原封不动地拷给了测试机。
    2. 测试机（克隆体）拉起后，内核一查这个目录：“哦！原来我还有几个小弟（从库/CDC）需要喂数据！”
    3. 于是，测试机开始疯狂地把生成的 WAL 日志全部死死扣留在本地，绝对不清理（因为配置了槽位，必须等小弟来取）。
    4. 但是，那是测试机啊！根本没有任何真实的从库会连上来消费！
    5. 最终，测试机的 pg_wal 目录无限膨胀，直到撑爆整块硬盘，带着克隆体同归于尽。
  • 原厂级微操（绝育手术）：如果冷备是为了做克隆克隆库，在打包时必须加上 --exclude='pg_replslot/*'，或者在克隆体启动的第一时间，连进去疯狂敲 pg_drop_replication_slot()，给它做物理绝育！

🏴‍☠️ 终极反物质陷阱二：商业级密码学的铁棺材（TDE 与外置密钥）

  • 高阶降维打击现场：你去面试海量数据（Vastdata）、云和恩墨这种做商业发行版的原厂。他们的企业级 PostgreSQL 几乎 100% 开启了 TDE（透明数据加密）。
  • 物理真相：在 TDE 开启的情况下，你拷走的那个 $PGDATA 目录里，8KB 数据页里的内容不再是明文，而是被 AES-256 算法彻底搅碎的高熵乱码！
  • 逻辑咬合的终极审判：
    1. 冷备只拷贝了密文的肉体。
    2. 而解密这些肉体的“灵魂（Master Key）”，通常根本不在 $PGDATA 里！它们被保管在外部的 KMS（密钥管理系统）服务器上，或者 Linux 的某个极度安全的 TPM 芯片/独立硬件加密机里。
    3. 如果你只懂抱着 $PGDATA 跑路，到了灾备中心解压启动时，数据库会向你要主密钥。拿不出来？这几 TB 的冷备数据，就是一堆连量子计算机都算不出来的纯粹物理垃圾！
  • 定性：在金融级架构下，冷备份已经不是单纯的“复制文件”，而是**“数据块拷贝 + 密钥库（KMS）离线引出”**的联合双重战术行动！

【PostgreSQL 物理冷备份：六维终极防御阵列】**：

🧊 第一维：时空静止与法医验尸（The Physics of Stoppage）

  • 绝对红线：绝不盲目相信 pg_ctl stop 的返回码。
  • 物理防呆：必须使用 pg_controldata 探底，只有当 Database cluster state 呈现出绝对安详的 shut down 时，宇宙才算真正静止，物理拷贝才被允许。若带着 in production 状态拷贝，必将产生无法修复的“撕裂块（Torn Pages）”。

🪤 第二维：文件系统的视觉欺骗（The Symlink & OS Traps）

  • 藤与瓜的绞肉机：死死盯住 $PGDATA/pg_tblspc（自定义表空间）和 $PGDATA/pg_wal（独立日志盘）下的软链接。必须顺藤摸瓜（如 tar -h），否则拷走的永远只是一个几字节的快捷方式空壳。
  • 叹息之墙：跨越极严苛的操作系统时，普通打包会剥离 SELinux 标签和 ACL 扩展属性，导致恢复时遭遇内核级 Permission denied。

🧬 第三维：宇宙常数的基因隔离（The Architecture Ban）

  • 跨界禁区：冷备是纯二进制的硬盘拓印。底层的 Endianness（字节序：大小端） 和 CPU 内存对齐规则，决定了 x86 架构的冷备包绝对不能直接在 ARM（鲲鹏/飞腾）架构上拉起。跨平台、跨大版本，冷备即废纸。
  • 密码学铁棺：若开启了 TDE（透明数据加密），冷备拷走的只是高熵乱码。没有 KMS 服务器或独立硬件导出的 Master Key，数据将遭遇降维打击，永远无法解密。

👻 第四维：幽灵状态的致命寄生（The Residual State Bombs）

  • 自爆倒计时（pg_replslot）：带走旧主库的复制槽，会在新机器上唤醒幽灵订阅者，导致新库的 WAL 日志无限膨胀，最终同归于尽（必须在打包时排除或启动后立刻物理绝育）。
  • 死前遗言（pg_serial）：带走了前世的 SERIALIZABLE 可串行化隔离级别锁状态，可能导致新库启动初期的幽灵幻读报错。
  • 无日志大清洗（_init 分支）：如果停机不干净，UNLOGGED 表在复活时，会被其底层的 _init 空模板强行覆盖，主数据瞬间蒸发。
  • 统计垃圾（pg_stat_tmp）：打包前必须排除内存统计快照和临时排序文件，防止新库启动时优化器智商掉线。

⚡ 第五维：企业级降维魔法（Time-Space Compression）

  • 停机时间坍缩：面对 TB 级核心库，不允许 3 小时停机冷备。必须利用底层存储的 LVM Snapshot 或 SAN COW（写时复制快照） 技术，将物理冻结时间强行压缩至 10 秒以内，随后在后台慢慢拉走快照卷。

🕳️ 第六维：PITR 的时空盲区（The Navigation Blindspot）

  • 缺失的航标：冷备不会像热备那样生成 backup_label。它是一座没有时间锚点的孤岛。用冷备做基线强行衔接归档日志做 PITR，内核会误以为是正常重启而拒绝回放，除非进行极其危险的极客微操（强制设标与写 recovery.signal）。

了解 www.876873.xyz 的更多信息

订阅后即可通过电子邮件收到最新文章。

您可能还会对这些文章感兴趣！

postgresql物理备份之： 冷备份：等您坐沙发呢！

发表评论