你要从一份虚拟机备份里，单独抽出磁盘镜像文件做检查或迁移。你按记忆里的命令敲下去，等着文件出现在你指定的位置——结果要么找不到文件，要么转出来的内容不对，要么机器内存莫名其妙吃紧了。
现象
表现可能有几种，而且经常一起出现：
- 文件没出现在你期望的地方：解压出来的东西写回了原目录，或者转出来的镜像落在一个你没想到的路径下；
- 报错说目录已存在：抽取工具拒绝执行，提示目标目录必须不存在；
- 内存被吃掉：往某个目录里解压/抽取时，机器内存明显变紧，甚至触发 OOM。
根因
问题出在几个工具的默认行为都很反直觉，而你按"想当然"去用了。
反直觉一：压缩工具不加 -o 会把结果写回原目录。
像 zstd -d backup.zst 这种用法，不加 -o 输出文件 时，它的默认行为是解压到来源所在的位置——结果可能生成一个文件堆在原目录里，或者在原文件名基础上做替换。你以为"解压到当前目录就行"，它却写去了别处。
反直觉二：抽取工具要求目标目录"必须不存在"，它自己来创建。
像 Proxmox VE 的 vma extract 这类工具，你把目标目录传给它时，它期望的是一个还不存在的路径——它会自己去建。如果你事先 mkdir 好了那个目录，它反而报错（"目录已存在"）。这和大多数"你得先建好目录"的工具习惯正好相反。
反直觉三：虚拟化平台的 /tmp 是内存盘（tmpfs）。
很多虚拟化平台的 /tmp 被挂成内存盘——写进去的东西占用的是 RAM，不是磁盘。而备份镜像动辄几个 GB，往 /tmp 里解压/抽取，等于把这些数据全塞进内存。本来紧张的内存被瞬间吃光，轻则变慢，重则 OOM 或平台异常。
解决
针对这三点，逐一明确处理：
其一：解压必须显式指定输出文件。
# 明确写出输出到哪里、叫什么
zstd -d -o /真实磁盘路径/disk.img backup.vma.zst
不要省 -o，因为你不知道它的默认目的地会是哪儿。同理，tar、gzip 这类工具的输出位置也最好显式指定。
其二：抽取的目标目录，给一个不存在的路径。
# 目标目录 /data/restore/disk 事先不要创建，让工具自己建
vma extract -v /备份路径/backup.vma /data/restore/disk
如果它报"目录已存在"，就把那个目录删掉/确保它是干净的，再执行。
其三：落盘放到真实磁盘，不要用 /tmp。
先确认 /tmp 是什么文件系统：
df -h /tmp # 看它的挂载点
findmnt /tmp # 看它是不是 tmpfs
如果 findmnt 显示类型是 tmpfs，那它就是内存盘。把你的工作目录放到真正的大容量磁盘上（比如你专门的数据盘）。
做法串起来：
# 1. 先看磁盘空间够不够
df -h /data
# 2. 解压到真实磁盘（显式输出）
zstd -d -o /data/restore/backup.vma /备份/backup.vma.zst
# 3. 抽取到"尚不存在"的目标目录
vma extract -v /data/restore/backup.vma /data/restore/disk
延伸与预防
这条坑最值得带走的，是一句通用的经验：命令行工具的"默认输出位置"，几乎每次都得显式覆盖。
cp、mv、tar、dd、各种解压工具，默认行为各不相同，有的写当前目录，有的写来源目录，有的用派生文件名。省参数时看着简洁，出问题时却极难定位——因为"文件到底去哪了"这件事，在你脑袋里从来没被明确过。
预防上，养成三个小习惯：
- 写命令时习惯性地把输入、输出两个路径都写全，哪怕默认行为"看起来"是你想要的；
- 大文件操作前先
df -h看空间，尤其要确认目标目录不是内存盘（findmnt看类型）； - 不确定工具行为时，先拿一个小文件试一遍，看清楚它把东西放哪了，再对真实数据动手。
这三条看着啰嗦，但它们拦下的是"解压到一半磁盘满""数据写进内存把机器搞崩"这类真正昂贵的事故。