Time Machine 出问题了？最常见备份错误的 12 种修复方法

Time Machine 处于多个子系统的尴尬交汇点。要完成一次备份，它必须协调文件系统、文件系统事件守护进程、网络挂载、SMB 或 AFP、sparsebundle 封装、加密层、快照，以及用户对这些都不会同时失败的假设。当某一项失败时，表面错误通常是泛泛的"发生错误"，毫无有用上下文，而实际原因往往是约十二种具体问题之一。

本指南就是这十二项问题的实战清单。每个修复方法都遵循相同结构：症状是什么样的、底层实际发生了什么，以及让备份恢复正常的精确步骤。

第一步：阅读日志

在改动任何东西之前，先看看 Time Machine 实际在对自己说什么。打开终端运行：

log show --predicate 'subsystem == "com.apple.TimeMachine"' --info --last 1h

这会输出过去一小时的 Time Machine 活动。滚动查找 error、fail、denied 或 copying 等词。实际根本原因几乎总写在其中某处，即使用户看到的对话框毫无用处。

更快的分诊方式：

tmutil status
tmutil latestbackup

第一条打印备份引擎的实时状态。第二条告诉你最后一次成功快照完成的时间。如果 latestbackup 是几天甚至几周前的，那么"Time Machine 已完成备份"的通知就是骗你的。

修复 1：备份永远不结束

症状：进度条几小时缓慢前进却从未完成。剩余时间不断增长。

诊断：两种常见原因。要么真的是大量数据的首次备份（那确实就是很慢），要么是 fseventsd 出了问题，Time Machine 在做全盘扫描而非增量。

修复：

1. 如果这是有史以来第一次备份，让它完成即可。1 TB 的初始备份经 USB 3 需要 6 至 12 小时；同样经 Wi-Fi 可能需要数天。如果是云端目的地，插上以太网。
2. 如果不是首次备份，怀疑 fseventsd。在源卷上运行 sudo rm -rf /.fseventsd，然后重启。下一次备份会因重建事件数据库而慢，但之后会恢复正常速度。
3. 在活动监视器中检查 backupd 和 backupd-helper。如果 CPU 高但磁盘 I/O 低，瓶颈是元数据扫描而非数据传输。再次怀疑 fseventsd。

修复 2：卡在"正在准备备份…"

症状：状态显示"正在准备备份…"数小时，从未推进。

诊断："准备"阶段是 Time Machine 对源卷做快照并遍历变更日志以决定要备份什么的阶段。如果变更日志损坏或目的地的 sparsebundle 元数据陈旧，这个阶段可能无限期停滞。

修复：

1. 打开菜单栏 Time Machine 图标，点击"跳过此备份"。这会终止卡住的任务。
2. 等 30 秒，然后从同一菜单触发"立即备份"。
3. 如果新运行也停滞，弹出并重新挂载目的磁盘。
4. 如果停滞依旧，从磁盘工具对源卷运行 fsck 等效操作（急救）。
5. 最后手段：用 sudo rm -rf /.fseventsd 重建 fseventsd 数据库，重启，然后备份。

修复 3：备份盘满，sparsebundle 持续增长

症状：Time Machine 报告备份盘已满，即便你设置了宽松的尺寸上限。

诊断：Sparsebundle 不会随着快照删除自动缩小。Time Machine 精简旧快照时，释放的空间在 sparsebundle 内被报告，但 sparsebundle 文件本身保持已增长的大小。在与其他数据共享的目的地上，宿主文件系统会在 Time Machine 察觉前用尽空间。

修复：

1. 压缩 sparsebundle。先从 Time Machine 弹出，手动挂载，然后运行：hdiutil compact /Volumes/Backups/MyMac.sparsebundle。
2. 如果无法压缩，可能需要将活动数据复制出来，重新创建更小的 sparsebundle，然后复制回去。
3. 如果备份目的地支持，在 sparsebundle 上设置硬性大小上限。macOS 本身在 UI 中不暴露此选项；必须使用 tmutil setdestination 或服务器上的管理工具。
4. 考虑使用专门用于 Time Machine 的目的地，让其他文件不与之争夺空间。Capsule Backup 等云端目的地分配固定配额，不会被任何东西吞噬。

修复 4：Time Machine 找不到备份磁盘

症状："Time Machine 找不到备份磁盘"，尽管你在 Finder 中能看到它。

诊断：磁盘已挂载但 Time Machine 失去了对它的持久引用（UUID 或卷标识符不匹配），或 SMB 共享掉线且自动重新挂载失败。

修复：

1. 对本地磁盘：打开系统设置 → 通用 → Time Machine，移除目的地，重新添加。Time Machine 会检测到现有备份文件夹并继续，而非从头开始。
2. 对网络共享：通过 Finder 的 ⌘K 弹出并重连。将凭据保存到钥匙串，让自动重连未来能工作。
3. 验证磁盘的文件系统是 Time Machine 支持的：本地磁盘是 APFS 或 HFS+，网络是 SMB3。exFAT 和 NTFS 不是支持的目的地。

修复 5："发生错误"且无其他信息

症状：经典的泛泛错误对话框，毫无可操作信息。

诊断：这是 macOS UI 放弃了。实际错误在日志中。

修复：

1. 运行上面的日志查询以找到底层错误。
2. 错误通常是本清单的其他项之一：权限、网络、sparsebundle 损坏、磁盘满，或更新后故障。匹配并应用相应修复。

修复 6：Sparsebundle 损坏

症状：Time Machine 拒绝挂载目的地，或备份中途抱怨 sparsebundle 已损坏。

诊断：Sparsebundle 是一个小"band"文件的文件夹，它们共同构成一个虚拟磁盘。如果某个 band 损坏（通常因为源在写入中途被拔出，或网络在关键元数据更新期间掉线），整个卷就变得无法挂载。

修复：

1. 挂载共享，找到 sparsebundle，尝试双击手动挂载。如果 macOS 提示修复，接受。
2. 从终端：hdiutil verify /path/to/MyMac.sparsebundle。这会报告卷是否可挽救。
3. 如果 verify 失败，尝试：hdiutil attach -noverify -nomount /path/to/MyMac.sparsebundle 不挂载附加，然后用磁盘工具的急救对附加的镜像执行。
4. 如果修复成功，立刻执行一次全新备份到不同目的地。需要修复过一次的 sparsebundle 已处于借来的时间。
5. 如果修复失败：你的快照历史完了。开始一份新的备份到新目的地。详见 还原指南。

修复 7：网络共享反复断开

症状：备份开始，运行一两小时后因网络错误而失败。常伴随 Finder 通知"服务器已断开"。

诊断：SMB 会话掉线。原因从 Wi-Fi 不稳到路由器 NAT 超时到服务器的空闲断开策略，再到把 Mac 在传输中途置于睡眠的不当节能设置。

修复：

1. 从 Wi-Fi 切换到以太网。多小时传输中的 Wi-Fi 丢包会累积。
2. 系统设置 → 节能 → 取消勾选"在可能时让硬盘睡眠"和"为网络访问唤醒"。
3. 系统设置 → 节能 → 将"关闭显示器"间隔设得更长，并确认台式机上"显示器关闭时阻止自动睡眠"已启用。
4. 对于 SMB 特定的连接掉线，编辑（或创建）/etc/nsmb.conf 并添加：[default] notify_off=yes signing_required=yes。第一项减少某些服务器处理不好的多余通知路径。
5. 如果服务器强制空闲超时，安排保活活动，或迁移到为长时间 Time Machine 会话设计的目的地。

修复 8：增量备份缓慢

症状：本应几秒完成的每小时备份要花 20 至 40 分钟。

诊断：要么 fseventsd 正在重建（见修复 1），要么源磁盘有过多小文件，元数据阶段自然慢。

修复：

1. 将常见的捣乱者加入排除列表：node_modules、~/.gradle、~/.m2、虚拟机磁盘镜像、大型容器缓存。这些容易重新生成，是备份中的纯噪音。
2. 从终端，以编程方式排除：tmutil addexclusion ~/projects/big-monorepo/node_modules。对每个路径重复。
3. 确认排除已生效：tmutil isexcluded ~/projects/big-monorepo/node_modules。

修复 9：权限错误（操作不被允许）

症状：日志报告特定路径上"操作不被允许"。常见目标是 ~/Library/Mail、~/Library/Messages 或第三方应用沙盒。

诊断：macOS 使用 TCC（透明度、同意与控制）来限制对特定用户数据的访问。backupd 需要"完全磁盘访问"才能读取这些位置。

修复：

1. 系统设置 → 隐私与安全性 → 完全磁盘访问。
2. 确认 Time Machine 出现在列表中且开关已打开。如果缺失，使用 + 按钮手动添加，浏览到 /System/Applications/Utilities/，或直接搜索。
3. 对某些 macOS 版本必须直接添加 backupd。路径为 /System/Library/CoreServices/backupd.bundle/Contents/MacOS/backupd。
4. 重启。运行手动的"立即备份"并检查日志是否还有残余权限错误。

修复 10：排除列表未生效

症状：你将一个文件夹加入排除列表，但它仍出现在备份中或计入备份大小。

诊断：排除是针对旧路径添加的（文件夹被重命名或移动），或排除通过一种机制添加而 Time Machine 从另一种机制读取。

修复：

1. 列出当前排除：sudo tmutil listexclusions。
2. 如果排除错误，移除：tmutil removeexclusion /path/to/folder。
3. 针对规范的绝对路径重新添加。
4. 通过运行 tmutil calculatedrift 或简单等待下次预定备份来强制刷新大小估算；排除会立即生效。

修复 11：加密磁盘无法解锁

症状：Time Machine 每次备份都要求加密密码，或拒绝你知道正确的密码。

诊断：备份磁盘的钥匙串条目已被移除、损坏或替换。这发生在重大 macOS 升级后、经 iCloud 钥匙串同步冲突后，或从另一份备份恢复系统后。

修复：

1. 打开钥匙串访问并搜索备份卷的名称。删除任何重复或陈旧条目。
2. 运行"立即备份"，并在提示时重新输入密码。勾选"保存到钥匙串"。
3. 如果密码被以"密码错误"等错误拒绝但你确信正确，尝试通过磁盘工具输入。在磁盘工具中通过"装载"按钮挂载 sparsebundle 并在那里使用密码。如果磁盘工具接受，问题纯粹是钥匙串条目不匹配，重新保存即可修复。
4. 如果磁盘工具也拒绝：确认你没有误输 FileVault 密码，参阅 Mac 备份加密详解 了解两层之间的区别。真正遗忘的 Time Machine 加密密码没有恢复路径。

修复 12：macOS 更新后 Time Machine 损坏

症状：昨天还能工作。今天，在 Sequoia 小版本发布后，备份失败。

诊断：macOS 更新例行调整 SMB 栈、TCC 数据库或 Time Machine 内部。故障几乎总落入三类之一：丢失完全磁盘访问、SMB 凭据丢失，或 sparsebundle 需为新版本重新认证。

修复：

1. 如修复 9 所述重新授予 backupd 完全磁盘访问。
2. 通过 ⌘K 手动重新挂载 SMB 共享，并将凭据重新保存到钥匙串。
3. 如果目的地是网络 sparsebundle，弹出并重新附加。macOS 有时需要针对新 OS 重新验证 sparsebundle 元数据。
4. 如果上述都不管用，从系统设置 → 通用 → Time Machine 中移除目的地并重新添加。现有快照会被检测并继续，而不是被擦除。

预防性维护

多数 Time Machine 故障都可通过少量持续投入来预防。

• 每季度验证备份。通过 Time Machine 浏览器还原一个随机文件。确认内容匹配。按日历安排。如果你六个月没做过，今天就做。
• 每月对 sparsebundle 运行 hdiutil verify。先从 Time Machine 弹出，再挂载并验证。在损坏吞噬你的历史前先抓住它。
• 保持两个目的地。本地 USB SSD 用于快速恢复，加上异地云端目的地用于灾难恢复。macOS 自动轮替。
• 记录加密密码。放在密码管理器里。今天。你忘记它的那天就是你需要它的那天。
• 看着菜单栏图标。每天点开。如果最后一次成功备份已超过一天，去调查。

何时重新开始（最后手段）

如果你已应用本指南中的每个修复但 Time Machine 仍失败，有时正确的做法是开始一份全新的备份。在动手前：

1. 在另一块磁盘上添加新目的地，让它完成完整的初始备份。
2. 通过测试还原验证新备份。
3. 只有这时才移除损坏的目的地。

永远不要在希望新备份能用的情况下删除快照历史的唯一副本，因为如果不行，你将完全没有备份了。关于选择新的异地目的地的详细信息，参阅 云端 Time Machine 设置指南，或直接跳到 设置教程。

更大的图景

Time Machine 工作时出色，失败时令人沮丧，因为故障模式如此不透明。上面的十二个修复覆盖了我们在野外见到的约 95% 的故障。剩下的 5% 通常追溯到实际硬件死亡，这种情况下没有任何修复能让磁盘起死回生，正确答案是不同的目的地——理想情况下是你端到端控制的那种。Capsule Backup 部分存在的意义就是云端 Time Machine 目的地通过完全移除"磁盘即故障点"来绕过许多此类故障模式。