Time Machine 通过 Wi-Fi、Ethernet 与云端

每个拥有不止一块硬盘的 Mac 用户最终都会问同一个问题：Time Machine 应该通过 Wi-Fi、通过 Ethernet，还是备份到云端？答案很少是干净利落的——它取决于你有多少数据、你多久改动一次、你愿意花多少钱，以及你最担心哪种故障。

本文给你诚实的版本：理论带宽、真实世界的数字、每种配置往往如何出故障，以及大多数有经验的 Mac 用户最终会采用的混合方案。

带宽计算（理论对现实）

备份速度有两个上限：网络移动比特的速度，以及目的地写入它们的速度。对 Time Machine 来说，网络几乎总是瓶颈。下面是每种常见传输方式在实践中实际能提供的表现。

Wi-Fi 5（802.11ac）

宣传数字是：80 MHz 信道两条空间流为 866 Mbps，三条流为 1.3 Gbps。而你在一台普通家用环境里的 Mac 上实际看到的持续传输速率更接近 300 至 450 Mbps，具体取决于与接入点的距离、干扰情况，以及同一频段上有多少其他设备。较老的 Wi-Fi 5 客户端芯片，或 AC1200 级别的路由器，可能会掉到接近 200 Mbps。

Wi-Fi 6（802.11ax）

宣传数字每条流高达 1.2 Gbps。在现代 MacBook 上，与接入点同处一室时真实的持续吞吐通常为 700 至 900 Mbps，隔着几堵墙会降到 400 至 600 Mbps。Wi-Fi 6 应对密集环境的能力也远胜 Wi-Fi 5——如果你住在 5 GHz 频段拥挤的公寓楼里，这很有用。

Wi-Fi 6E 和 Wi-Fi 7（6 GHz 频段）

Wi-Fi 6E 增加了 6 GHz 频段，目前基本空旷，因此良好条件下的真实吞吐可以接近 1 Gbps。Wi-Fi 7 增加了 320 MHz 信道和多链路操作，理想条件下 Mac 的真实吞吐为 1.5 至 2 Gbps。代价是：6 GHz 的覆盖距离短于 5 GHz，所以你通常需要待在同一个房间里。

千兆 Ethernet

扣除协议开销后持续吞吐约为 940 Mbps。这是所有认真做本地备份的人都应当以之为底线的水平。它稳定、低延迟，并且不受 Wi-Fi 常见问题的影响。为 MacBook 配一个 USB-C 转 Ethernet 适配器，其花费低于你在一次大备份上节省下来的时间的价值。

2.5 GbE 和 10 GbE

如果你有一台带 2.5 GbE 或 10 GbE 的 NAS，以及一台支持它的 Mac（部分 Mac mini、Studio 和 Pro 机型出厂即配 10 GbE），你就能让目的地磁盘而非网络成为瓶颈。对 Time Machine 而言，这在增量模式下很少有影响——每小时要移动的数据本就不多。但对一台 1 TB 以上机器的首次备份来说，它确实有影响。

典型家庭光纤上行

云端目的地受限于你的上传带宽，而这正是几乎所有人都会忘记的一点。常见的家用套餐：

• Cable / VDSL：上行 10 至 50 Mbps
• 中端光纤：上行 100 至 300 Mbps
• 对称千兆光纤：上行 1 Gbps
• 手机热点 / 网络共享：上行 5 至 30 Mbps，通常有上限或被限速

就云端备份而言，那条 1 Gbps 对称光纤线路基本上和到本地 NAS 的千兆 Ethernet 一样快。如果你有这样一条线路，本地对云端的速度之争也就不存在了。

Time Machine 究竟如何备份

在看数字之前，先了解 Time Machine 在链路上做了什么会很有帮助。根据目的地的不同，其行为在几个重要方面有所差异。

首次全量备份对增量备份

首次备份是对 Time Machine 认为符合条件的每个文件的完整复制。此后，每小时的备份只写入发生变化的文件（在直接连接的 APFS 目的地上则是变化的 APFS extent）。对大多数用户而言，每日变化量在几百 MB 到几 GB 之间——小到即使是慢速连接也能在几分钟内完成。

APFS 快照与“瘦身”

在直接连接到 Mac 的 APFS 格式目的地上，Time Machine 使用 APFS 快照。这些快照极其高效——只写入变化的块，随着空间紧张，旧快照会自动“瘦身”。网络 Time Machine 目的地（包括所有云端目的地）无法直接使用 APFS 快照；它们使用一个包含 APFS 卷的 sparsebundle 磁盘映像。

SMB3 对 AFP（旧版）

AFP，即 Apple Filing Protocol，是最早的 Mac 网络文件协议。它已被弃用，不再是 macOS 的默认协议，且在 Time Machine 工作负载上明显慢于 SMB3。SMB3 是每一个当前云端 Time Machine 服务所使用的协议，也是每一台现代 NAS 作为推荐协议所支持的。SMB3 还带来了原生的传输中加密，这对云端目的地至关重要。

Sparsebundle 的 band 与分块

Time Machine 在网络目的地上使用的 sparsebundle 格式是一个装满小“band”文件的文件夹，通常每个 8 MB。随着备份增长，会创建更多 band。这种设计让 sparsebundle 无需重写整个映像即可增长，并允许备份在断连后恢复。缺点是：在错误的时机发生一次糟糕的写入，就可能让某个 band 文件处于不一致状态。健壮的 SMB3 服务器和处理得当的重连逻辑可以将其最小化。廉价的家用 NAS 固件、频繁的 Wi-Fi 掉线，或在写入过程中睡眠的 Mac，则会将其放大。

真实世界的首次备份耗时

下面是带宽计算换算成时间后，在一台典型 Mac 上进行首次 Time Machine 备份的实际含义。这些数字假设目的地磁盘能跟上网络——对任何现代 SSD 支撑的 NAS 或任何云端 SMB 目的地来说都成立，但对一块老旧的 USB 2 机械硬盘则未必如此。

250 GB 首次备份

传输方式	有效吞吐	预计耗时
Wi-Fi 5，隔壁房间	~250 Mbps	~2.4 小时
Wi-Fi 6，同一房间	~800 Mbps	~45 分钟
千兆 Ethernet	~940 Mbps	~38 分钟
云端，上行 50 Mbps	~45 Mbps	~13 小时
云端，上行 300 Mbps	~270 Mbps	~2.2 小时
云端，对称 1 Gbps	~900 Mbps	~40 分钟

500 GB 首次备份

传输方式	有效吞吐	预计耗时
Wi-Fi 5，隔壁房间	~250 Mbps	~4.7 小时
Wi-Fi 6，同一房间	~800 Mbps	~1.5 小时
千兆 Ethernet	~940 Mbps	~1.25 小时
云端，上行 50 Mbps	~45 Mbps	~26 小时
云端，上行 300 Mbps	~270 Mbps	~4.4 小时
云端，对称 1 Gbps	~900 Mbps	~1.3 小时

1 TB 首次备份

传输方式	有效吞吐	预计耗时
Wi-Fi 5，隔壁房间	~250 Mbps	~9.5 小时
Wi-Fi 6，同一房间	~800 Mbps	~3 小时
千兆 Ethernet	~940 Mbps	~2.5 小时
云端，上行 50 Mbps	~45 Mbps	~52 小时
云端，上行 300 Mbps	~270 Mbps	~9 小时
云端，对称 1 Gbps	~900 Mbps	~2.6 小时

有两点很突出。第一，良好条件下的 Wi-Fi 6 在备份上确实能与千兆 Ethernet 一较高下。第二，高速对称光纤也让云端备份具备竞争力——“云端太慢”是 2014 年的论调，而非 2026 年的。

另一件值得明说的事：这是你会运行的最长的一次备份。首次之后的每一次每小时备份都小到能在几秒到几分钟内于上述任何一种传输方式上完成。在 Wi-Fi、Ethernet 和云端之间的选择，绝大部分是关于首次备份和可靠性的——而不是日常性能。

可靠性与故障模式

速度是人人都纠结的部分。可靠性才是更要紧的部分。

Wi-Fi：丢包与 sparsebundle 损坏

Wi-Fi 备份方便但脆弱。真正困扰用户的故障模式有：

• 备份途中在接入点之间漫游，导致 SMB 连接短暂中断
• MacBook 合盖，使 Mac 在写入过程中进入睡眠
• 微波炉、婴儿监视器或邻居的网络引入 2.4 GHz 干扰
• 廉价家用路由器在负载下丢弃较老的客户端连接

这些通常都不会直接摧毁一个备份。Time Machine 在恢复方面总体上做得不错。但经过数月累积，在一台仅用 Wi-Fi 的 NAS 上，sparsebundle 最终陷入无法修复状态的概率明显高于 Ethernet。

Ethernet：稳如磐石，需留意什么

Ethernet 是最可靠的 Time Machine 传输方式。线缆问题是唯一常见的隐患：一根损坏的线缆、廉价交换机上的一个坏端口，或一次不匹配的协商而降到了 100 Mbps。在 Terminal 中执行 ifconfig en0 会告诉你实际的链路速度；如果在千兆配置下它没有显示 1000baseT 或更高，那么问题就出在线缆或交换机上。

另一件要留意的事：USB-C Ethernet 适配器上的省电功能。有些适配器在 Mac 睡眠时会断开链路，且在唤醒后未必总能干净地恢复。如果你看到备份在一次睡眠周期后立即失败，通常就是这个原因。

云端：SMB3 重连，断连后恢复

云端 Time Machine 目的地出人意料地健壮，因为它们必须如此——每一条家用互联网连接都会偶尔掉线。一个构建良好的云端 SMB 服务会通过恰当的 SMB3 会话重连、服务器端的预写日志，以及对部分写入的干净处理来应对这一点。以 Capsule Backup 为例，它对此透明处理——如果你的 Mac 在备份途中掉出 Wi-Fi，它会在重连后从中断处继续，不会造成 sparsebundle 损坏。

云端的故障模式则不同：ISP 中断、酒店 Wi-Fi 上的强制门户，或者没有正确实现 SMB3 重连的提供商。选择一家做到了这些的提供商，这些问题也就不复存在了。

每种方案何时适用

如果你只能选一种传输方式，下面是各自成为正确答案的场景。

• 通过 Wi-Fi 连本地 NAS：当你拥有 Wi-Fi 6 或 6E 路由器、NAS 就在几个房间之外，并且你备份的是台式机或固定不动的 MacBook 时。对 500 GB 以下的 Mac 是可接受的。如果你备份的是一台频繁移动、不断睡眠和漫游的 MacBook，则应避免。
• 通过 Ethernet 连本地 NAS：当你备份台式 Mac（mini、Studio、iMac）或固定桌面使用的 MacBook 时。原始速度和可靠性都最佳。前提是你得插上线。
• 仅云端：当你经常出行、在多地办公，或者干脆不想拥有一台 NAS 时。有了高速对称上行，云端本质上和本地 NAS 一样快。而在 50 Mbps 上行下，首次备份较慢，但后续备份则毫无察觉。

关于如何为你的工作流选择合适的目的地，参见我们的设置指南。

混合方案：多个 Time Machine 目的地

你其实并不需要做选择。自 macOS Sierra 起，Time Machine 就原生支持多个目的地，会在它们之间自动轮换。

macOS 多目的地如何工作

在系统设置 > 通用 > Time Machine 中，你可以添加任意数量的备份磁盘。每一次每小时备份轮流写入一个目的地。随着时间推移，每个目的地都会拥有完整的备份历史。如果某个目的地离线（比如你的 NAS 宕机，或你的笔记本不在家），其他目的地会继续工作。

推荐的混合方案：本地 NAS 加云端

大多数有经验的 Mac 用户最终收敛到的配置：

• 通过 Ethernet 连本地 NAS——快速的日常目的地。恢复是即时的。首次备份一个晚上就能完成。
• 云端 SMB 目的地——异地副本。可以在盗窃、火灾、洪水以及摧毁你本地网络的勒索软件中幸存。首次备份慢，之后则无感。

这满足了 3-2-1 原则（三份副本、两种介质、一份异地），而你除了把 Time Machine 指向这两个目的地、让 macOS 完成其余工作之外，什么都不用做。

轮换节奏及预期

Time Machine 在每次每小时备份时于目的地之间交替。所以如果你在正午添加了两个目的地，正午的备份写入目的地 A，下午 1 点的备份写入目的地 B，依此类推。在一天的过程中，两个目的地都会看到大致相同的数据，最多相差一小时。

首次备份在每个目的地上分别运行。如果你在仅本地 Time Machine 使用一年之后才添加云端，云端必须从头开始——Time Machine 无法把备份历史从一个目的地复制到另一个目的地。

针对特定使用场景的备份呢？

有些工作流有它们自己的答案。

视频剪辑师与创意工作者

如果你处理数 TB 的 Final Cut 或 DaVinci Resolve 项目，Wi-Fi 很少够用，甚至千兆 Ethernet 也开始显得慢。对工作集而言，连本地 NAS 的 10 GbE 才是答案；云端 Time Machine 则是异地层。我们在面向创意工作者的页面上有更深入的探讨。

开发者

开发者往往“真实”数据很少，缓存却极其庞大（node_modules、Xcode 构建文件夹、Docker 卷、虚拟机）。正确的做法通常是在 Time Machine 设置中排除这些缓存，然后把剩下的备份到任何方便的目的地。数据量小的情况下，即便是到云端的 50 Mbps 上行也足够。

拥有多台 Mac 的家庭

一台 NAS 加一份支持无限设备的云端订阅，很难被超越。每台 Mac 同时指向两个目的地；你既能获得快速的本地恢复，又能拥有可幸存的异地副本。关于无限设备究竟意味着什么，参见我们的定价。

把这一切串起来

诚实的总结很简单。Ethernet 是最快也最可靠的单一传输方式。对大多数 Mac 来说，只要你不在备份途中漫游，Wi-Fi 6 就“够快了”。如果你经常出行、想要异地可幸存性，或拥有高速对称上行，云端就是正确答案。而最强的配置并不是只选一种——而是让 Time Machine 在一个快速的本地目的地和一个云端目的地之间交替，这样你既有速度又有可幸存性。

我们见到的最常见错误，是人们为首次备份速度而优化，却忽视了可靠性。首次备份只是一个晚上。接下来十年的增量备份才是真正的产品。选择那个当你到了第三年、唯一重要的事情就是恢复是否有效时你会信任的目的地。关于云端 Time Machine 背后的安全模型，参见我们的安全概览；关于云端对 iCloud 的对比，参见我们的 iCloud 对比。