www.876873.xyz

绝对会！百分之百会！它不仅会备份，而且会把表空间里最底层的真实物理数据块，一字节不差地全部抽空带走！

🧲 物理抓取全过程（拒绝空壳）

当 pg_basebackup 在主库上开始收容数据时：

1. 扫描与发现：它扫描主数据目录（$PGDATA），来到了 $PGDATA/pg_tblspc/ 目录。
2. 识破软链接：它看到了里面名叫 16384（表空间的 OID）的软链接。
3. 顺藤摸瓜（核心动作）：它绝对不会只把你这个空壳软链接拷走就完事了。它会顺着这根软链接，直接跨越目录边界，冲向你配置在另一块硬盘上的真实物理地址（比如 /data/ssd_01）。
4. 抽干实体数据：它进入 /data/ssd_01，把你放在那里的几十 GB 真实表数据、索引数据，全部读取出来，源源不断地拉回备份端！

---

⚠️ 生死警告：抓回来之后放在哪？（这才是最危险的）

既然数据被 100% 抓回来了，那么在备份机上，它会以什么形态落地？这取决于你的命令参数。这也是无数 DBA 踩过的大坑：

• 安全落地（推荐：-F t tar 格式）： 如果你敲的是打包模式。它会把主目录打包成 base.tar，然后把刚才从表空间抓回来的真实数据，单独打包成一个叫 16384.tar 的文件。主数据和表空间数据井水不犯河水，非常安全。
• 致命落地（危险：-F p plain 明文格式）： 如果你敲的是明文拷贝模式（且不加 -T 映射参数）。它把数据抓回来后，会强行试图在备份机上寻找一模一样的绝对路径（/data/ssd_01）去存放这些实体数据！
  • 如果备份机没有这个目录：当场报错，备份彻底失败。
  • 如果你是在主库本机执行这个备份命令：它会直接把抓出来的数据，重新覆盖写回你正在运行的主库表空间里，当场造成物理覆盖灾难！

💡 极简总结

表空间里的真实数据一定会跟着备份走。 软链接只是门牌号，pg_basebackup 会踹开门进去把里面的金条（数据）全部搬空。