Mac 上的 com.apple.sbd 是什么进程？

最后更新: 2026-07-31

它是什么

com.apple.sbd 是 Apple 的 Secure Backup Daemon。macOS 平时不会让它一直运行，而是在安全恢复相关任务出现时按需启动。它属于用户级系统进程，已知工作主要围绕 iCloud 钥匙串展开：处理加密恢复副本、托管记录、钥匙串 keybag、恢复元数据，以及部分受保护 iCloud 数据所需的加密密钥。

名字里的 “Backup” 很容易让人误会。com.apple.sbd 处理的不是普通文件备份，而是安全托管和恢复所需的数据。它不是 Time Machine，也不负责把 Mac 里的文档、应用、照片或整套系统内容备份到 iCloud。这里说的“备份”，重点是将来能否安全恢复钥匙串和相关密钥，不是能否找回整台电脑里的文件。

还要注意职责边界。Apple 公布了 iCloud 钥匙串同步、托管和恢复所采用的安全架构，却没有按进程列出 com.apple.sbd 在当前 macOS 中负责的全部数据类别。现有资料足以确认它和钥匙串备份、托管、恢复密切相关，但不能据此断言所有钥匙串功能都由它独自完成。

它为什么要联网

com.apple.sbd 的启动时机来自系统事件，不是固定日程。本机的 launchd 配置表明，安全子系统发出钥匙串备份通知、iCloud 键值存储状态发生变化，或者其他系统组件通过 XPC 提出请求时，macOS 都可能唤起 com.apple.sbd。任务结束后，它可以退出，不需要常驻后台等待。

建立或更新钥匙串恢复记录时，com.apple.sbd 需要和 Apple 服务交换数据。受信任设备加入、旧设备恢复、钥匙串恢复、托管元数据获取或提交，也可能触发联网。连接对象属于 Apple 的 iCloud 键值存储或 CloudKit、Apple Account 认证服务，以及受硬件安全模块保护的 iCloud 托管服务。

Apple 没有公布 com.apple.sbd 专用且固定不变的域名清单。因此，不能只凭进程职责编造一组域名，也不能保证它每次都走同一主机或同一路径。可以确定的是，它的已知任务需要访问 Apple 的认证、云端存储和安全托管基础设施。

“每天固定运行一次”也没有依据。当前 launchd 配置里能看到通知触发和 XPC 按需触发，看不到每日定时项。有人提到的“每日备份”，通常来自 Apple 对 iPhone、iPad 整机 iCloud Backup 的说明。那是另一项服务，不能直接套到 Mac 上的 com.apple.sbd。

正常流量应该是多少

目前没有经过验证的正常流量区间。Apple 没有公布 com.apple.sbd 一次应该传多少、一天通常传多少，也没有给出可用于判断异常的 MB 数字。脱离具体设备给出精确范围，只会制造一种并不存在的确定性。

从已知职责看，com.apple.sbd 平时传输的内容主要是经过加密的钥匙串相关数据、keybag、恢复材料和控制元数据。这类数据通常应该远小于照片、视频或 iCloud Drive 文件同步。不过，“通常更小”只是基于数据类型作出的相对判断，不等于存在一个已经实测并由 Apple 确认的上限。

首次启用相关功能、把新设备加入受信任设备集合，或者执行恢复时，短时间内可能传输得更多。现有调研同样无法为这些场景划定数字门槛。看到一次流量突增，不应立刻认定异常；长期持续传输也不能只靠一个网上流传的“标准值”下结论。更可靠的办法是查看这台 Mac 自己的逐进程记录，再结合当时是否刚做过设备加入或恢复来判断。

能不能关掉

建议保留 com.apple.sbd。Apple 没有提供单独关闭 com.apple.sbd 的系统开关。

强行阻止 com.apple.sbd，可能让 iCloud 钥匙串恢复记录无法建立或更新。新设备加入受信任设备集合时可能失败，设备恢复也可能受到影响；部分受保护 iCloud 数据所需的密钥，之后还可能无法正常恢复。这些后果都涉及数据访问和安全恢复，不适合拿来换取未经证实的流量或内存收益。

只在活动监视器里结束 com.apple.sbd，也不等于永久关闭。它由 launchd 管理。下次安全子系统发出通知、iCloud 状态变化，或其他组件提出 XPC 请求时，系统仍可重新启动它。

macOS 确实有一项相关设置：系统设置 > [你的姓名] > iCloud > 查看全部 > 密码 > 同步此 Mac。关闭它可以停止这台 Mac 的密码与钥匙串同步，但它不是 com.apple.sbd 的专用开关。现有证据也没有证明关闭同步后，com.apple.sbd 就再也不会因其他恢复或托管任务启动。

把 com.apple.sbd 禁掉，当作网络或内存优化手段，并没有可靠依据。它本来就会按需运行，空闲时可以退出；目前也没有证据显示它平时持续产生大量流量。强行拦截带来的恢复风险很明确，所谓优化收益却没有得到验证。

常见的误解

• “com.apple.sbd 就是 Time Machine，或者 Mac 版整机 iCloud Backup。” 不是。com.apple.sbd 面向安全托管、钥匙串恢复和相关密钥材料，不负责备份 Mac 上的普通文件。Time Machine 和整机云备份都不能用来解释它的职责。

• “com.apple.sbd 会把明文密码上传给 Apple。” 这个说法不符合 Apple 公布的安全架构。Apple 文档说明，iCloud 钥匙串同步和恢复数据采用端到端加密；托管记录还要经过严格的恢复认证，并由硬件安全模块保护。现有资料不支持“上传明文密码”这一结论。

• “com.apple.sbd 每天固定备份一次。” 没有证据。它的 launchd 配置使用安全通知、iCloud 状态变化和 XPC 请求来触发，没有每日定时项。iPhone 和 iPad 的整机 iCloud Backup 可以按条件每日执行，但那不能证明 Mac 上的 com.apple.sbd 也采用同样安排。

• “禁用 com.apple.sbd 可以安全地省流量、省内存。” com.apple.sbd 本来就是按需进程，空闲后会退出。强行禁用可能破坏托管记录更新、受信任设备加入或安全恢复流程，却没有可靠证据证明它平时是持续占用大量网络的服务。

• “只要阻止 com.apple.sbd，全部 iCloud 钥匙串实时同步就会立刻停止。” 这个判断超过了现有证据。Apple 把钥匙串同步和钥匙串恢复定义为两项服务。目前能更直接确认的是，com.apple.sbd 参与备份、托管和恢复。Apple 没有公开进程级分工表，因此无法确认持续同步的每一步由哪个组件完成，也不能把所有实时同步行为都归到 com.apple.sbd 名下。

• “macOS 的 com.apple.sbd 就是 Linux 上那个 sbd。” 两者没有关系。Linux 中同名的加密 netcat 工具、集群 SBD 守护进程，都不是这里讨论的 Apple 系统进程。名字相同，不代表用途或实现相同。

怎么看它到底用了多少

如果 com.apple.sbd 看起来流量偏高，下一步不是套用一个未经验证的通用数字，而是检查这台 Mac 的实际记录。可以在 Bytetally 的逐进程统计中找到 com.apple.sbd，看看流量只集中在一小段时间，还是持续出现。再对照当时是否刚启用钥匙串、加入受信任设备或执行恢复，判断这次活动是否符合使用场景。

相关进程

常见问题