PostgreSQL 18 新增的 file_copy_method = clone，可以利用支持写时复制（Copy-on-Write，CoW）的文件系统快速克隆数据库文件。在条件合适时，一个 TB 级数据库的复制操作可以在约半秒内完成。这里的关键不是 PostgreSQL 突然获得了每秒数 TB 的磁盘吞吐量，而是文件系统只复制元数据，并让新旧文件暂时共享底层数据块。
这项能力很适合测试环境、临时分析库和快速创建租户数据库，但它并不是无条件的性能开关。文件系统能力、后续写入量、空间监控和备份策略都会影响是否值得启用。
clone 为什么能跳过漫长的数据搬运
传统文件复制需要读取源文件，再把每个数据块写入目标文件。复制 1 TB 数据所需的时间，基本由存储吞吐量决定。即使底层磁盘能持续提供 1 GB/s，也需要十几分钟。
CoW 克隆采用另一种方式：
- 创建一组新的文件系统元数据。
- 让源文件和目标文件引用相同的数据块。
- 任意一方发生写入时，再为被修改的数据块分配独立空间。
因此，克隆刚完成时通常同时具有两个特征：创建速度极快，新增的实际磁盘占用很小。随着源数据库和克隆数据库继续写入，两者共享的数据块逐渐分离，实际空间占用也会增长。
file_copy_method 控制的是 PostgreSQL 复制数据库文件时采用的方法。要让它参与 CREATE DATABASE，应明确走 FILE_COPY 策略；如果使用其他数据库创建策略，就不能假定这个参数会带来同样效果。
先确认文件系统真的支持 CoW 克隆
clone 依赖底层文件系统和操作系统提供克隆文件的能力。配置参数存在，并不意味着当前数据目录所在的卷一定支持它。云盘、容器卷、网络文件系统和不同挂载选项之间都可能存在差异。
可以先在与 PostgreSQL 数据目录相同的文件系统上做一个独立测试。运行前把 /path/on-postgres-volume 替换为该文件系统上的临时目录：
set -eu
TEST_DIR=/path/on-postgres-volume/reflink-test
mkdir -p "$TEST_DIR"
cd "$TEST_DIR"
truncate -s 1G source.bin
time cp --reflink=always source.bin clone.bin
ls -lh source.bin clone.bin
du -h source.bin clone.bin
rm -f source.bin clone.bin
rmdir "$TEST_DIR"
cp --reflink=always 如果失败，说明这条测试路径无法按要求完成 reflink 克隆。即使测试成功，也应再通过 PostgreSQL 做端到端验证，因为命令行工具测试只能证明文件系统具备相关能力，不能代替 PostgreSQL 自身的兼容性测试。
还可以先确认服务器版本和参数是否可用：
SHOW server_version;
SHOW file_copy_method;
用会话级参数做一次可回滚的基准测试
不建议一开始就修改全局配置。可以这样实践：准备一个允许作为模板复制的测试数据库，然后分别测量 clone 与普通复制的耗时。
下面假设 PostgreSQL 18 已经运行，benchmark_template 是测试模板库，并且执行账号有创建数据库的权限。创建数据库时，模板库不能承载普通业务连接。
set -eu
time env PGOPTIONS='-c file_copy_method=clone' \
psql -X -v ON_ERROR_STOP=1 -d postgres \
-c 'CREATE DATABASE benchmark_clone WITH TEMPLATE = benchmark_template STRATEGY = FILE_COPY;'
time env PGOPTIONS='-c file_copy_method=copy' \
psql -X -v ON_ERROR_STOP=1 -d postgres \
-c 'CREATE DATABASE benchmark_copy WITH TEMPLATE = benchmark_template STRATEGY = FILE_COPY;'
psql -X -v ON_ERROR_STOP=1 -d postgres \
-c 'DROP DATABASE benchmark_clone;'
psql -X -v ON_ERROR_STOP=1 -d postgres \
-c 'DROP DATABASE benchmark_copy;'
这里使用 PGOPTIONS 只影响对应客户端会话，便于在不改变集群默认行为的情况下验证功能。如果安装环境中的普通复制取值或支持范围有差异，应以 PostgreSQL 18 实例上的 SHOW file_copy_method、参数视图和实际错误信息为准。
基准测试不要只记录 CREATE DATABASE 的墙钟时间，还应同时观察：
- 克隆前后的文件系统可用空间与实际分配块数。
- 两个数据库持续写入后，空间增长速度是否符合预期。
- 克隆期间模板数据库的连接限制对业务有没有影响。
- 删除克隆库后，文件系统空间是否按预期回收。
- 备份、快照、复制和监控工具能否正确处理克隆文件。
快速创建不等于零成本运行
clone 最容易被误解的地方，是把“半秒创建”当成“免费复制”。它只推迟了数据块复制，并没有消除后续写入的成本。
对于只读测试、短期查询和一次性排障环境，源库与克隆库可以长时间共享大量数据块，收益通常很直接。对于高写入压力的测试环境，克隆完成后大量页面会迅速分裂，空间占用可能逐步接近两份完整数据库，还会产生额外的 CoW 写入开销。
这项功能也不能替代备份。克隆通常与源数据库位于同一存储故障域；底层卷损坏、误删除或主机故障可能同时影响两者。需要恢复保障时，仍然要保留独立备份、归档 WAL，并定期执行恢复演练。
另一个边界是监控口径。ls 展示的逻辑文件大小可能很大，而 du 或文件系统专用工具反映的实际分配空间较小。容量告警如果只看其中一个指标，可能在克隆初期高估用量，也可能在后续块分裂时低估增长风险。
上线前的决策清单
适合优先试用 file_copy_method = clone 的场景包括短生命周期测试库、大型只读分析副本、CI 数据库夹具，以及需要频繁从固定模板创建数据库的开发平台。
正式启用前，应完成以下检查：
- PostgreSQL 已升级到 18，并确认参数在目标实例上可用。
- 数据目录所在文件系统通过了 CoW 克隆测试。
- 使用
CREATE DATABASE ... STRATEGY = FILE_COPY做过真实数据规模的基准测试。 - 测量了克隆创建时间，也测量了持续写入后的空间和延迟。
- 监控系统能够区分逻辑大小、实际分配空间和文件系统剩余容量。
- 团队明确知道克隆不是备份，也不跨越存储故障域。
- 准备了回退到普通文件复制方法的操作方案。
file_copy_method = clone 的价值非常具体：把原本受数据量约束的复制过程，变成接近元数据操作的克隆过程。只要文件系统支持、工作负载以读取或短期使用为主，并且团队能管理后续写入带来的空间增长，它就能显著缩短 TB 级数据库环境的交付时间。