PostgreSQL快照备份是指结合文件系统级别的快照能力与数据库自身的备份钩子，在几乎不阻塞业务的情况下获得一份物理一致的磁盘镜像。这种方法绕开了逻辑导出时的全表扫描，特别适合体量较大、写入频繁的实例。
一、为什么需要文件系统快照
传统的pg_dump属于逻辑备份，会把每张表转成SQL或自定义格式，当数据库达到几百GB甚至TB级别时，导出和后续恢复都非常耗时。而且逻辑备份过程中长事务可能导致膨胀，影响线上性能。文件系统快照则直接在块设备层面对某一时刻的磁盘状态拍照，无论数据量多大，创建动作通常在秒级完成。
不过单靠快照还不够。PostgreSQL在运行时会有脏页驻留内存，并且数据文件可能正处于非一致写状态。如果直接对磁盘做快照而不通知数据库，恢复后会出现类似断电的效果，必须由重放WAL来修补。因此快照备份本质是一个“冻结写+拍磁盘+补日志”的组合操作。
二、核心原理与执行步骤
PostgreSQL提供了专门的函数来协调物理备份：pg_start_backup和pg_stop_backup。前者会让数据库强制把脏页刷盘，并在WAL中写入一条备份开始记录；后者则写入结束记录并切换WAL段。在两者之间，我们可以安全地对文件系统或块存储打快照。
以Linux的LVM为例，假设数据目录位于逻辑卷/dev/vg0/pgdata，可以先执行SQL层面命令，再使用lvcreate创建快照。示例如下：
-- 在psql中执行，label可自定义
SELECT pg_start_backup('snapshot_2024', false, false);
-- 系统命令行创建LVM快照，大小视写入量而定
-- lvcreate -L 10G -s -n pgdata_snap /dev/vg0/pgdata
-- 快照完成后告诉数据库
SELECT pg_stop_backup(false, false);
上面的false参数分别表示不强制立即做全量检查点、不等待备份结束归档。实际生产中可根据归档配置调整。快照卷生成后，可挂载到临时目录拷贝，也可直接交由备份系统流转到对象存储。
需要注意，快照仅捕获打点时刻的块状态，后续数据库继续写入不会影响快照内容。但必须保证从pg_start_backup到pg_stop_backup期间的WAL文件都被完整保留，否则恢复时缺少段会报错。
三、不同文件系统与存储的快照方案
并不是所有环境都使用LVM。在云上，主流云厂商的云硬盘都提供快照API；本地物理机可能用ZFS、Btrfs等自带快照能力的文件系统。下表列出常见方案的特点：
| 方案 | 创建速度 | 空间开销 | 一致性保障 |
|---|---|---|---|
| LVM | 快 | 需预留COW空间 | 依赖pg_start_backup |
| ZFS | 极快 | 按需分配 | 可结合pg钩子 |
| 云盘快照 | 快 | 后端增量 | 需暂停写或调钩子 |
ZFS的快照是文件系统原生能力，可以在毫秒级完成，并且支持快照克隆，方便直接拉起只读副本做校验。云盘快照虽然方便，但部分平台在调用快照时会有短暂IO悬挂，最好仍在pg_start_backup保护窗口内操作。
如果底层是Ceph或分布式存储，通常通过QEMU或CSI驱动暴露快照接口，此时要确认快照动作的原子性，避免多个卷之间出现时间差导致备库无法对齐。
四、从快照恢复数据库
恢复过程和常规物理备份类似：先把快照数据还原到目标机器的数据目录，再准备一个recovery配置，让PostgreSQL启动时重放WAL到指定时间点。假设我们已经把快照卷挂载到了/var/lib/postgresql/restore，操作如下：
# 停止原实例或确保目标机无运行中的PG systemctl stop postgresql # 清空并拷贝快照内容 rm -rf /var/lib/postgresql/15/main/* cp -a /mnt/snapshot/* /var/lib/postgresql/15/main/ # 创建恢复信号文件，老版本用recovery.signal touch /var/lib/postgresql/15/main/recovery.signal
在postgresql.conf或standby.signal相关配置中，需要指定restore_command来取回WAL归档。因为快照时刻之后的事务都在WAL里，只有这些日志可用，数据库才能跑到一致状态。若只需恢复到快照点，可设置recovery_target为immediate。
恢复完成后建议立刻执行一次pg_checksums校验，并跑应用层的冒烟测试。由于快照备份属于物理备份，其版本必须与目标PG小版本兼容，跨大版本恢复需借助pg_upgrade而非直接拷贝。
五、优缺点与注意事项
快照备份最大的优势是对业务延迟影响极小，且备份速度不随数据量线性增长。它还天然适合做克隆环境，比如从生产快照拉一个预发库做回归。缺点在于需要存储层配合，不是所有托管数据库都开放快照权限；另外快照链过长会占用后端空间，要有合理的过期策略。
另一个常见误区是认为有了快照就不需要WAL归档。实际上快照只是某个时间点的基线，若想实现时间点恢复，必须持续归档WAL。建议把快照当作低频全量、WAL当作高频增量的混合策略，既控成本又保灵活。
经验法则：每次打快照前记录当前WAL的LSN，恢复时以此作为元数据索引，能快速定位所需归档段。
最后提醒，使用文件系统快照时务必确认挂载选项里没有禁用屏障写，否则在意外断电场景下快照可能捕获到乱序落盘内容，反而破坏一致性。
PostgreSQL文件系统快照快照备份修改时间：2026-08-11 09:39:35