如何删除 Mac 本地 Time Machine 快照

存储空间发布于 更新于 约 6 分钟

本地 Time Machine 快照会在备份盘不可用时，把近期恢复点保留在启动卷上。它们可能继续引用现行文件系统已经不用的数据块，但“存在快照”不是储存故障：Apple 会把这部分空间计入可用空间，并在快照变旧或其他任务需要容量时自动删除。

这篇指南解释 APFS 机制、如何只读列出快照，以及什么情况下才值得手动移除。它也会区分启动卷上的本地恢复点与外接或网络备份目标上的真正历史。

普通空间检查做完后，只有真实的保存、复制或安装仍然失败，才考虑本地快照。tmutil listlocalsnapshots / 是只读清单。Apple 公开的手动移除路径是暂时关闭自动备份，等待本地快照删除，再重新打开自动备份。高级 tmutil 删除命令会丢掉本地恢复点，不应成为例行清理。

错误心智模型

很多人把可用空间理解成「看得见的文件之和」，在 APFS 上更接近「没有任何引用的块」。文件可以在 Finder 中消失，但其数据区段（extent）仍可能被快照引用，只要最后一个引用还在，df 就会继续把这些块算作已用。

口头上常混着三种数：

数字 回答的问题
Finder / 应用显示的「大小」 你仍能看见的命名文件的逻辑大小
df 的已用 / 可用 挂载文件系统按记账规则报告的结果
存储里的「可清除」 系统估计能回收的混合池上界

可清除不是文件夹，它可以包含本地快照、部分缓存、可驱逐的云内容，以及记账余量。工具若承诺「释放 47.2 GB 可清除」却不给出前后 df，就是在猜。

机制：写时复制与快照

Time Machine 创建本地快照时，会记录当时数据区段的冻结视图。之后的写入分配新块，只要快照仍需要旧块，旧块就会保留；删除文件只移除现行卷上的引用。

写时复制解释了旧块为什么仍可能分配，却不能证明列出的快照正在挡住当前任务。Apple 把本地快照描述为自动管理：它们在备份盘不在线时提供近期恢复点，空间计入可用，变旧或系统需要容量时会被移除。

文件离开现行卷后，本地快照仍可引用旧数据块；另一个任务需要容量时，macOS 可以回收这个受管理的快照。
快照可能保留物理块，同时 macOS 仍把这部分容量视为可供新任务使用。

本地快照名称通常类似：

com.apple.TimeMachine.2026-07-28-091530.local

.local 后缀一般表示启动卷上的本地快照，而不是备份目标上的历史。

本地、外接与其他快照

类型 位置 怎么处理
/ 上的本地 TM 快照 启动卷 由系统管理；只有证实需要时才手动移除
Time Machine 备份 外接或网络卷 真正历史；不要为内置盘空间抹掉
其他 APFS 快照 同卷，命名不同 只有确认所有者才可删
iCloud 优化存储 云端 + 本地物化 驱逐策略，不是 tmutil

diskutil apfs listSnapshots / 的范围可以大于仅 Time Machine，其他软件也能建 APFS 快照，不要用不明「优化器」乱删非 TM 快照。

APFS 容器划分为用户文件、快照、可清除空间与空闲空间
物理容量由文件、快照、可清除数据与空闲空间构成。系统数据是存储分类，不是一个可整体清空的文件夹。

实验：先测量，不先删除

先记录 Finder 可用空间、diskutil info /，以及真正失败的任务。下面的快照命令只读取清单：

date
diskutil info / | grep -i "Container"
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /

清单为空，就去测量现行文件夹、废纸篓和容器里的其他卷。清单有条目，也只能证明有恢复点，不能证明容量故障。先重试原本失败的保存、更新或复制，再决定是否需要改变 Time Machine。储存空间分类刷新慢，不等于任务没有拿到容量。

tmutil 能做什么

先让系统管理

保存、复制和更新都能正常完成时，不需要做任何事。macOS 会按容量需求移除快照，在不影响普通任务的同时尽量保留近期恢复点。

Apple 公开的手动移除路径

如果真实任务仍然因为空间失败，而且快照是剩下的已证变量，Apple 建议在 Time Machine 设置里暂时关闭自动备份，等待几分钟让本地快照移除，再打开自动备份。同一轮操作里恢复备份策略，不要把一次诊断变成长期停止备份。

高级 tmutil 操作

本机 man tmutil 记录的语法是 thinlocalsnapshots mount_point [purge_amount] [urgency]，urgency 为 1 到 4。它请求从本地快照回收最多指定字节。使用前查看当前 Mac 的手册，并确认有近期备份；不要复制缺少挂载点、容量或紧迫度语境的裸命令。

tmutil deletelocalsnapshots 可按卷或日期删除本地恢复点。它不会改写外接备份盘，却会删除 Mac 离线时可用的近期版本。执行后必须重新打开自动备份，并重试原本失败的任务；更大的数字本身不是目标。

用一个例子判断

假设储存空间显示很大的系统数据，tmutil 也列出几个近期快照，但 macOS 更新可以正常开始。这里没有需要修的故障：分类与快照描述的是受管理状态，更新成功则证明任务拿到了容量。

如果更新确实因空间失败，先测量现行大文件夹、确认废纸篓，再做一个用户可控的改动并重试。只有这些内容解释不了失败时，快照移除才是一项边界明确的实验。实验后重新打开自动备份并重试更新；仍失败就停止删除快照，继续寻找其他现行文件、稀疏文件、克隆、容器卷或非 Time Machine 快照。

变薄后空间仍可能不涨

即使本地快照已经没了：

  • 存储估计里大部分其实是其他可清除类（云物化、可再生缓存）
  • 稀疏文件与克隆让逻辑与物理大小分叉（总量为何不一致）
  • 废纸篓仍占同卷空间
  • APFS 容器内另一卷共享空闲池
  • 仍有非 TM 快照或备份目标相关数据

这些各有测量路径，快照只是其中一章。

安全前提

激进变薄前：

  1. 确认外接 Time Machine 或其他近期且打开测过的恢复路径
  2. 接受：你删掉的中间本地版本，在新快照出现前无法离线恢复
  3. 优先文档化的 tmutil，而不是给不出前后可用空间差值的工具

本地快照是正常机制，只有在内置卷已满、且刚删除的数据仍被钉住时，它才变得紧迫。

常见错误

追逐系统数据那个数字。 目标是可用容量，以及机器还能更新、还能存文件，不是灰色块好看。

因为内置盘满就抹外接备份盘。 把本地快照和备份历史搞混了。

因为可清除看起来很大就乱删资源库。 可清除不是安全路径地图。

变薄后立刻量一次就下结论。 等一下，再采一次 df。

忽略容器记账。 一个卷标签不是 APFS 的全貌。

工具的边界

磁盘分析工具只能帮你定位当前可见的大目录，不能把系统数据变成一个可整体清空的目录。Mole 将磁盘分析、应用维护和清理前确认整合在原生 Mac App 里，系统数据仍由 macOS 和对应应用管理，快照是否存在、该如何处理，仍应以 tmutil 和前后 df 的读数为准。

若工具提示本地快照，先把它当作线索，而不是精确的可释放承诺，处理后重新测量可用空间，才知道实际结果。

操作顺序

  1. 确认真正的备份路径存在，而且自动备份已打开。
  2. 记录 Finder 可用空间、diskutil info / 和实际失败的任务。
  3. 先测量用户可控的大文件夹并检查废纸篓。
  4. 只读列出本地快照。
  5. 同一任务仍失败且快照是剩余变量时，使用 Apple 的临时设置路径或本机 tmutil 手册。
  6. 重新打开备份，重试任务，成功后就停止。

延伸阅读

本地快照让 Time Machine 能在启动盘上保留短期恢复点，把 tmutil 与 df 一起看，就能判断「删了 30 GB 却没变化」是不是快照造成的。

常见问题

删除本地快照会影响外接备份盘吗？

不会改写外接备份历史，但会删除只存在 Mac 上、在备份盘未连接时可用的近期恢复点。

为什么清空废纸篓后可用空间没有立刻变化？

储存空间分类可能更新较慢，快照也可能引用旧块。不过 Apple 会把受管理的本地快照空间计入可用，并在别的任务需要容量时回收。用原本失败的任务验证，而不是只看灰色分类条。

一次性删除所有本地快照安全吗？

不要把它当作例行清理。外接历史仍然独立，但本地近期恢复点会消失。只有真实容量故障、近期备份和明确证据同时存在时才这样做。