Time Machine Backup to a NAS: Latency, Not Bandwidth

Every guide to backing up a Mac over the network answers the wrong question. They benchmark throughput — gigabit versus 2.5GbE, spinning disk versus SSD — as if Time Machine to a NAS were a bandwidth problem. It is not. I can show you the exact log line where a backup destination sustained 315.88 MB/s and then timed out while writing 246 KB.

To be clear about what I am and am not: I do not own a NAS. This rig is a Mac mini in Seoul with a directly attached SSD, and every NAS-specific claim below is either Apple's published specification or a linked thread from someone who owns the hardware. The measurement in the middle is mine — I reproduced the write pattern macOS runs against network backup targets, on local storage, and it explains the field reports better than any throughput number does.

The test that only network destinations have to pass

Before macOS writes a backup to network storage, it runs a check that a USB drive never sees. Howard Oakley documented it: the system performs two checks of write performance on the backup storage, the first for a single 50 MB file, then for a rapid succession of 500 4 KB files. Same destination, same session, two very different shapes of work.

The log excerpt in that article is the whole argument compressed into three lines. One destination wrote the 50 MB file at 315.88 MB/s in 0.158 seconds, then produced this:

Failed destination write test with error Error Domain=NSPOSIXErrorDomain
Code=60 "Operation timed out". Wrote 246 KB across 60 files.

Run the arithmetic on that pair. The 50 MB test moved 208 times more data than the small-file test did. At the destination's own measured 315.88 MB/s, the 246 KB it managed before giving up represents 0.761 milliseconds of transfer time. A device with abundant bandwidth timed out moving under a millisecond of data. Whatever went wrong, the pipe was not the constraint.

One caveat I will not bury, because it cuts against the framing: Oakley adds that no significance seems to be attached to such failures. This test failing does not by itself mean the backup fails. I am not claiming it is the murder weapon. I am claiming the pattern it uses is diagnostic, and here is why.

What 500 small files actually cost

I reran that pattern on this machine's internal APFS SSD — 500 files of 4 KB each, created, written, closed, in three sync modes. No network anywhere in the path. Times are per file, across 500 files:

Sync mode	Total	Mean/file	Median	p95	Max
No sync	25.5 ms	0.051 ms	0.048 ms	0.075 ms	0.233 ms
fsync()	32.9 ms	0.066 ms	0.065 ms	0.076 ms	0.140 ms
F_FULLFSYNC	2,207.8 ms	4.416 ms	4.054 ms	5.126 ms	38.791 ms

The same 50 MB single-file write finished in 48.4 ms at 1,033.5 MB/s. A separate earlier run of the small-file test came in at 4.334 ms per file, so the numbers reproduce.

That third row is the finding. Ordinary fsync() is almost free here — 0.066 ms, barely distinguishable from no sync at all. F_FULLFSYNC costs 67 times more than fsync() and 87 times more than an unsynced write, on a fast internal SSD with zero network latency. The penalty is not a NAS defect. It is the price of the durability guarantee itself.

Apple's specification requires precisely the expensive operation

This is where the two halves meet. Apple's Time Machine Over SMB Specification is the document a NAS vendor must implement to be a legal backup target. It lists eight mandatory capabilities:

#	Requirement	Kind
1	SMB protocol version 3.x, including SMB 3.x signing	Protocol
2	SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2, honoring the Timeout field	Failover
3	SMB2_CREATE_REQUEST_LEASE_V2	Failover
4	SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2	Failover
5	Bonjour _adisk._tcp with TXT adVF=0x82	Discovery
6	F_FULLFSYNC via SMB2 FLUSH with Reserved1 = 0xFFFF	Durability
7	AAPL create context advertising kAAPL_SUPPORTS_FULL_SYNC = 0x4	Durability
8	Accepting .com.apple.timemachine.supported at the share root	Validation

Requirement 6 is explicit about what the server has to do: process the flush, then flush the physical disk's track cache before responding. That is a real head movement on a spinning disk, per operation, and the spec gives the server no permission to batch or defer it.

Now notice what is absent. Every mandatory item is about protocol version, failover, discovery, or durability. Not one of the eight sets a floor on latency or throughput. A NAS can satisfy the specification completely and still take 40 ms per synced small file. The document also carries a date worth knowing: it is archived, marked last updated 2016-09-13. The destination write test Oakley describes is, in his words, relatively new. Vendors are certifying against a document that predates the check they now fail.

What that does to the 500-file test over a wire

Take my measured 4.416 ms per fully-synced file and add round trips. An uncompounded SMB CREATE, WRITE, FLUSH, CLOSE is four request-response pairs; treat that as an upper bound, since SMB2 compounding can fold some together.

A wired NAS on a quiet LAN lands in the low seconds and nobody notices. Wi-Fi, a mesh hop, or a NAS busy rebuilding an array pushes the same 2 MB past a minute. That is where timeouts start landing, and why the failures below are so intermittent.

What owners actually report breaking

Four threads, none of them mine, all with the hardware in hand:

• Timeouts a few minutes in. On Apple's developer forums, a Big Sur upgrade broke backups to a Netgear ReadyNAS with error 112; owners of Synology and QNAP units reported the same code within weeks. The sparsebundle gets created, some files land with fresh timestamps, and then it dies. One participant guessed a timeout. The thread ends with no solution.
• A stale lock that survives the backup. On MacRumors, 8 to 10 owners hit sparsebundle could not be accessed (error 16) and The backup disk image .. already in use, traced to an smbd process still holding the image open after the backup finished. Reported from December 2021 into 2022, recurring roughly 10 days after each fix. One owner deleted a 650 GB sparsebundle and started over.
• Hardware that simply stops qualifying. In a November 2025 Apple discussion, a Buffalo LinkStation LS220 owner was told the device is Not Compatible with MacOS 26 Time Machine, with a firmware investigation open; the LS200 series lacks SMB 3.0 entirely. Existing configured backups kept running while new ones refused to set up.
• The direct-attached failure mode, for contrast. One owner's 5TB encrypted Time Machine drive took 4.3 minutes just to mount, with Disk Utility failing at -69845 and no third-party APFS repair tools to fall back on. I weighed that evidence when choosing between HDD and SSD. A NAS does not remove that class of problem — it adds a network and an SMB server on top of it.

If you are buying one anyway

The specification gives you a real shopping filter. Require SMB 3.x, confirm the vendor advertises Time Machine over SMB rather than only AFP, and prefer a wired connection over Wi-Fi — that last one is the difference between the blue bars and the red one above. Samba-based builds need version 4.8 or later.

Among units owners report working, Synology comes up most consistently; a DS223j was confirmed against macOS 26 in that November thread. The current two-bay Plus model is the Synology DiskStation DS224+, sold diskless (ASIN B0C6927XPX, product name and ASIN confirmed on the live listing on 2026-08-13; the page rendered as a JavaScript shell for me, so I could not read a price or stock state and will not quote one I did not verify).

Two things before you spend. First, drives are extra, so a diskless enclosure is roughly half the real cost. Second, the buying trap: in April 2025 Synology restricted its 2025-and-later Plus models to Synology-branded or certified drives, gating storage pools, health monitoring, deduplication, and firmware updates. After sustained backlash the company reversed the HDD restriction in DSM 7.3 — but M.2 SSDs remain limited to the compatibility list, and enterprise models keep the restriction. The DS224+ is a 2023 model and predates the policy entirely, which is a point in its favor rather than against it.

What this rig actually runs

Not a NAS. The reasoning is the one that decided the backup drive question and how much capacity to buy: this machine runs unattended, and nobody is sitting in front of it to notice a stall. I have already watched a scheduled job die silently because one network call ran 24 seconds past its timeout, unnoticed for 20.6 hours. An SMB server, a switch, and a sparsebundle are three more things that can fail quietly at 3am. For a desk Mac with a human attached and several machines to back up, a NAS earns its keep — a genuinely different calculation, and I compared the two roles directly.

If your backups to a NAS are failing, the useful instinct is to stop measuring megabits. Measure round trips.

Some links here are affiliate links; any commissions land on the public ledger. The three-mode write measurements are mine, run on this Mac mini's internal APFS SSD with F_FULLFSYNC issued as fcntl(fd, 51), and reproduced across two separate runs — they contain no network component, which is the point of citing them. The per-latency figures in the chart are a model built on that measurement plus an assumed four round trips per file, not something I measured over SMB; I own no NAS, so every claim about specific NAS hardware above is either Apple's published specification or a linked owner report, labelled as such in the sentence. Prices are not quoted because the listing did not render one I could confirm.