External storage is invariably sold with ‘up-to’ performance figures. In practice, you’ll seldom realise anything like some write or read speeds claimed. And when it comes to prolonged tasks like that first full Time Machine backup, no matter how fast you thought that drive would be, it always takes longer than expected.

Over the last few years I have tested and reviewed many examples of different types of external storage, from basic USB 3 hard drives, to the latest USB4 SSD enclosures, and NAS packed with fast SSDs. This article draws on all those test results to give you a better idea of what to expect when they’re being used with your Mac.

Results quoted here are typical for those tests performed mostly using a Mac Studio M1 Max, but unless otherwise indicated should be similar for recent Intel models. They’re summarised in this table.

Write speeds are given for:

• the single 50 MB write test performed by Time Machine before each backup;
• 500 multiple concurrent writes of 4 KB each, performed in those same Time Machine tests;
• calculated net write speed over a first full backup to APFS of at least 400 GB;
• general write speed measurement using my app Stibium, which gives broadly similar results to other leading benchmarking apps.

General read speeds are also obtained using Stibium, and similar to other apps. All speeds are given as MB/s for consistency.

Before looking at individual types of storage, one obvious and important result is the effect of throttling by macOS on Time Machine backup performance. Considering Time Machine’s own tests, writing a single 50 MB file is performed consistently at around 200-225 MB/s to local storage of whatever type, and multiple concurrent writes of 4 KB files reach around 20-23 MB/s regardless of local storage type. Those hold good even when you back up to a fast Thunderbolt 3 SSD, and backing up to a NAS is little quicker unless it’s over 2.5GbE to an NVMe SSD. Local transfer speeds only differ more substantially in general tests, when they aren’t throttled as they are in Time Machine.

Hard disks

When writing to or reading from a local hard disk, performance varies substantially according to which sectors on the hard disk are being accessed. This is a well-known phenomenon, and the result of geometry, as sectors are faster at the periphery of the disk’s platter, and slower in the inner part. Ranges given here take that into account: the lower figure is for inner sectors, and the higher for outer ones. Some users compensate for this effect, and only ever use the outer half of a disk’s sectors to obtain better performance, but that reduces their available capacity, and effectively doubles their cost per TB.

SSDs

SATA SSDs may be cheapest, but they’re also slowest, and with Macs they generally don’t enjoy Trim or SMART health indicator support. Of the two, Trim support is usually the more important, as without that, they can accumulate blocks waiting to be erased and returned for further use, and as a result their write (but not read) speed can fall as low as 100 MB/s. Unless used for largely static storage, this is a significant risk.

NVMe SSDs deliver twice the performance of SATA models, and generally enjoy Trim but not SMART indicator support. This makes them far better suited to general use, as their write speeds should be sustained from new throughout their working life.

USB 3.2 Gen 2, Thunderbolt 3, USB4

Translating commonly quoted transfer speeds for these three protocols into real-world speeds turns out to be complex. In practice, these are what you can expect to see:

• USB 3.2 Gen 2 at 10 Gb/s is slightly less than 1 GB/s
• Thunderbolt 3 at 32 Gb/s is up to 3 GB/s
• USB4 at 40 Gb/s is up to 3.4 GB/s.

All recent models of Mac, both Intel and Apple silicon, should realise full performance over USB 3.2 Gen 2 and Thunderbolt 3, but support for USB4 is limited to Apple silicon. Unless a drive or enclosure specifically includes Thunderbolt 3 as a fallback, when connected to an Intel Mac, you should expect it to fall back to USB 3.2 Gen 2 at just under 1 GB/s, less than a third of the speed of USB4.

NAS

Although I haven’t made any systematic comparison between AFP and SMB network protocols, I can see no consistent difference in their performance, when used with the latest versions of macOS and NAS software. The latter, though, can be critical: older versions of NAS software can perform poorly when used over SMB with recent macOS. Keeping your NAS software up to date is important.

Throttling of Time Machine backup writing isn’t supposed to occur when backing up over a network, and there is some evidence here to support that, with significantly better results for 50 MB test files. However, those are only apparent when using NVMe SSDs in the NAS, with a wired Ethernet 2.5GbE connection to provide sufficient bandwidth.

Check TM performance

Provided that your Mac is running a recent version of macOS and backing up to APFS, it’s simple to read the two write performance tests that occur at the start of each Time Machine backup using my free T2M2. Alternatively, you can also read them using the Time Machine custom log extract in Mints. In T2M2 they should look something like:
Destination IO performance measured:
Wrote 1 50 MB file at 238.02 MB/s to "/Volumes/ThunderBay2" in 0.210 seconds
Concurrently wrote 500 4 KB files at 35.58 MB/s to "/Volumes/ThunderBay2" in 0.058 seconds

Check general performance

Although there are other apps that will do this, I developed Stibium for this purpose. Follow the ‘gold standard’ procedure detailed in its Help Reference to obtain the most accurate and reproducible results. Stibium can test any storage you can access in the Finder, including all local devices and networked systems such as NAS.

Further reading

Which external drives have Trim and SMART support?
How to evaluate an external SSD
You can read my reviews in MacFormat and MacLife magazines, available in the App Store.

I have recently seen reports of very low speeds when copying large files such as virtual machines, in some cases extending to more than a day, even when they should have been sparse files, so requiring less time than would be expected for their full size. This article teases out some tests and checks that you can use to investigate such unexpectedly poor performance.

Expected performance

Time taken to copy or duplicate files varies greatly in APFS. Copies and duplicates made within the same volume should, when performed correctly, be cloned, so should happen in the twinkling of an eye, and without any penalties for size. This is regardless of whether the original is a sparse file, or a reasonably sized bundle or folder, whose contents should normally be cloned too. If cloning doesn’t occur, then the method used to copy or duplicate should be suspected. Apple explains how this is accomplished using the Foundation API of FileManager, using a copyItem() method. This is also expected behaviour for the Finder’s Duplicate command.

Copying a file to a different volume, whether it’s in the same container, or even on a different disk, should proceed as expected, according to the full size of the file, unless the original is a sparse file and both source and destination use the APFS file system. When an appropriate method is used to perform the copy between APFS volumes, sparse file format should be preserved. This results in distinctive behaviour in the Finder: at first, its progress dialog reflects the full (non-sparse) size of the file to be copied, and the bar proceeds at the speed expected for that size. When the bar reaches a point equivalent to the actual (sparse) size of the file being copied, it suddenly shoots to 100% completion.

Copying a sparse file to a file system other than APFS will always result in it expanding to its full, non-sparse size, and the whole of that size will then be transferred during copying. There is no option to explode to full size on the destination, nor to convert format on the fly.

External SSDs

When copying very large files, external disk performance can depart substantially from that measured using relatively small transfer sizes. While some SSDs will achieve close to their benchmark write speed, others will slow greatly. Factors that can determine that include:

• a full SLC cache,
• failure to Trim,
• small write caches/buffers in the SSD,
• thermal throttling.

Many SSDs are designed to use fast single-level cell (SLC) write caching to deliver impressive benchmarks and perform well in everyday use. When very large files are written to them, they can exceed the capacity of the SLC cache, and write speed then collapses to less than a quarter of that seen in their benchmark performance. The only solution is to use a different SSD with a larger SLC cache.

Trimming is also an insidious problem, as macOS by default will only Trim HFS+ and APFS volumes when they’re mounted if the disk they’re stored on has an NVMe interface, and won’t Trim volumes on SSDs with a SATA interface. The trimforce command may be able to force Trimming on SATA disks, although that isn’t clear, and its man page is forbidding.

Trimming ensures that storage blocks no longer required by the file system are reported to the SSD firmware so they can be marked as unused, erased and returned for use. If Trimming isn’t performed by APFS at the time of mounting, those storage blocks are normally reclaimed during housekeeping performed by the SSD firmware, but that may be delayed or unreliable. If those blocks aren’t released, write speed will fall noticeably, and in the worst case blocks will need to be erased during writing.

For best performance, SATA SSDs should be avoided, and NVMe used instead. NVMe is standard for USB 3.2 Gen 2 10 Gb/s, USB4 and Thunderbolt SSDs, which should all Trim correctly by default.

Disk images

Since Monterey, disk images with internal APFS (or HFS+) file systems have benefitted from an ingenious combination of Trimming and sparse file format when stored on APFS volumes. This can result in great savings in disk space used by disk images, provided that they’re handled as sparse files throughout.

When a standard read-write (UDIF) disk image is first created, it occupies its full size in storage. When that disk image is mounted, APFS performs its usual Trim, which in the case of a disk image gathers all free space into contiguous storage. The disk image is then written out to storage in sparse file format, which normally requires far less than its full non-sparse size.

This behaviour can save GB of disk space in virtual machines, but like other sparse files, is dependent on the file remaining on APFS file systems, otherwise it will explode to its full non-sparse size. Any app that attempts to copy the disk image will also need to use the correct calls to preserve its format and avoid explosion.

Tools

Precize reports whether a file is a clone, is sparse, and provides other useful information including full sizes and inode numbers.

Sparsity can create test sparse files of any size, and can scan for them in folders.
Mints can inspect APFS log entries to verify Trimming on mounting, as detailed here.
Stibium is my own storage performance benchmark tool that is far more flexible than others. Performing its Gold Standard test is detailed here and in its Help book.

备份的意义

我想大家都多多少少遇到过设备死机、进水、被偷，甚至被黑客勒索的事情吧。从概率上来说，数据丢失只是早晚的事情。这就是为什么要备份，不然可能青春的回忆，各种美好就再也不见了，那会很痛，可能比失恋还痛。

「不同裝置都有相同的資料才叫作資料備份，只是換個裝置存放不叫做備份^[1]」

我和一些网络上厉害的家伙聊过，发现他们也没有做到真正的备份。把数据一股脑丢进硬盘，把数据丢进各种网盘/云服务，甚至程序员也只是把代码放在 GitHub 上。这些都不是备份，国内的网盘不说了，诸如 iCloud 和 Google Drive，本质是个同步盘。历史上不管是 iCloud 还是 Google Drive 都出现过宕机问题，不把鸡蛋放在一个篮子里，要狡兔三窟。

备份的目的是为了可以「无损」还原，如果不能还原，储存再多的数据也没有意义。

备份类型

• 全部备份（Full Backup，包括系统）备份数据量大，备份所需时间长。
• 增量备份（Incremental Backup）自上一次完全备份后有变化数据的备份
• 差异备份 (Differential backup) 提供完整备份后变更的文件

第一种全盘备份，举个例子，从一台电脑上一模一样搬迁到另一台电脑上。有些备份是不包括系统设置数据的，还原数据后需要重新设定应用设置、字体大小、系统语言啊，种种……准备系统备份的好处在于带有一个开机系统，比如 Windows 的 WinPE，macOS 的可引导安装器。

差异备份与增量备份的区别在于前者包括上一次完全备份、差异备份或增量备份，后者仅是上一次完全备份后有变化。挺绕的……

3-2-1-1-0 原则

• 至少做三份数据副本（一份本体，两份 copy）
• 存储在至少两种不同类型的存储介质上
• 在异地位置保留一份备份副本

在 3-2-1 原则再加两点^[2]，

• 将一份媒体副本离线或隔空
• 确保所有可恢复性解决方案没有错误（刚说备份之目的）

在这个科技高度发展的年代，其实最安全的储存方式还是用磁带保存，埋在一个角落（比如 GitHub 埋在北极的胶片^[3]）。

云备份

当然我们不用这么极端，用个靠谱的云备份就行了，也是一种异地备份。刚刚讲过，常规的那些网盘不算备份，要选择专门用来备份的云存储服务，那么靠谱的备份服务有哪些呢，可选的不多。

大家公认的有 Backblaze Personal Backup。每月 $7，不限备份容量，从 2007 年运营至今，稳定。懒人首选，只要后台开着软件就可以无感备份，手机端有 App 也可以备份。

对于国内用户来说由于网络封锁，需要耗费代理流量，第一次备份需要注意流量。从国内访问，稳定性一定要考虑，可是目前无解。

还有一个严格意义来说不算提供云储存服务的软件——Arq， 2009 年运营，$49.99 买断单设备，Premium $59.99/year（提供 1 TB 云空间，不推荐）

搭配第三方云端空间使用，官方描述：Use it for encrypted, versioned backups of your important files. 有加密功能不错。

硬盘备份

推荐用硬盘来储存，硬盘分为 HDD（机械硬盘）和 SSD（固态硬盘），硬盘可是大有学问，这里不展开了，感兴趣的可以在本 blog 搜索 SSD。

相比之下 SSD 的优势在：

1. SSD 读取写入速度快，快就是王道
2. SSD 的寿命（写入和擦除）长
3. SSD 可以在使用中移动

缺点：

1. 售价贵
2. 恢复数据困难

不管是 HDD 还是 SSD，「任何的存储装置都是消耗品」，说不定哪天就挂掉了，所以多准备一块硬盘吧。虽然 SSD 也能抢救资料，但是恢复难度大（要看硬盘哪里损坏）关键是数据恢复又贵（基本 ¥2000 以上）又麻烦还不安全（冠希哥艳照门）。

Time Machine

用 Mac 的同学可以用一下这个，免费，但是不太好用，设定逻辑太简单，Apple 没有好好做，所以有下面的软件推荐。

搭配硬盘使用的备份软件

• SuperDuper (2004 年 $27.95 买断制，有免费版功能少一点也可以用，优点是可以把 SSD 作为一个启动盘，支持差异备份。

• Carbon Copy Cloner 6 $39.99 更加老牌的一个软件，官方的口号是「A leader in Mac backups since 2002」，速度和稳定性比 Time Machine 好，口碑不错。

上述备份软件和 Backblaze 都提供试用，可以选择一款适合自己的。

NAS 备份

我没有使用 NAS，这方面不了解，根据需求选择。用 NAS 也要有双保险，做好异地备份。虽然硬盘不怕坏了，但是也有一些不可抗力因素。

备份内容

除了全盘备份，还需要注意保存在云上的数据，比如我存在 Bitwarden 上的密码。暂时好像没有别的了。

看了那么多，今天你备份了吗？Just do it！