Fixing Slow Time Machine Backups on macOS

Time Machine, built on APFS snapshots underneath, is usually fast for incremental backups — a backup that’s consistently slow, or seems permanently stuck “Preparing,” almost always has an identifiable, specific cause rather than being inherently slow.

Step 1: distinguish a slow first backup from a slow incremental one

The very first backup to a new destination copies your entire selected data set and can reasonably take many hours, especially over Wi-Fi — this is expected and not a sign of a problem. A backup that’s slow every time, well after the first one completed, is the actual thing worth troubleshooting.

Step 2: check “Preparing Backup” specifically

Apple menu → System Settings → General → Time Machine →
  click the Time Machine menu bar icon for backup status

“Preparing Backup” involves comparing the current state of your disk against the last backup to determine what changed — this step can take a long time if a very large number of files changed since the last backup, or if local snapshots have accumulated and need reconciling.

Step 3: check for accumulated local snapshots consuming space and time

tmutil listlocalsnapshots /

macOS keeps local APFS snapshots on the internal disk between backups to an external/network destination — an unusually large number of these can slow down the comparison Time Machine does before each backup. Thinning happens automatically under normal conditions, but can fall behind if backups have been failing or skipped for a while.

Step 4: check network conditions for a network-based backup destination

tmutil destinationinfo

A Time Machine destination on a network drive or Time Capsule is naturally far more sensitive to Wi-Fi signal quality and network congestion than a directly-attached external drive — testing with a wired connection, or moving closer to the access point, isolates whether network conditions are the actual bottleneck.

Step 5: check Activity Monitor for what’s actually consuming resources during the backup

Applications → Utilities → Activity Monitor → Disk tab

Confirm backupd (Time Machine’s backup process) is the process actually consuming significant disk I/O — if something else entirely is dominating disk activity at the same time, that’s a separate, unrelated performance problem worth addressing on its own.

Step 6: check the destination disk’s own health

diskutil verifyVolume /Volumes/YourBackupDisk

A failing or heavily fragmented backup disk can slow down every single backup meaningfully — worth ruling out directly, particularly for an older external drive that’s never been checked.

Step 7: exclude large, frequently-changing, or unnecessary data from backup

System Settings → General → Time Machine → Options →
  add folders to exclude (caches, large VM disk images,
  local development build artifacts)

Data that changes constantly and doesn’t need historical backup versions (build caches, large VM disk files) can meaningfully slow down every single backup cycle if included — excluding it addresses the root cause directly rather than just tolerating longer backup times indefinitely.

Why distinguishing first-backup-slowness from ongoing slowness matters most

Treating an expected, one-time slow first backup as a problem leads to unnecessary troubleshooting of something that isn’t actually broken; conversely, dismissing a persistently slow incremental backup as “just how Time Machine is” misses a real, fixable cause. Confirming which situation you’re actually in, before working through the steps above, is what keeps this troubleshooting focused on the right problem.

Step 8: compare what actually changed between two backups directly

tmutil compare

If “Preparing Backup” specifically is the slow phase rather than the actual copy, tmutil compare (run without arguments, comparing the two most recent local snapshots) lists exactly which files and directories changed between them — a direct, concrete answer to “what does Time Machine think changed” rather than guessing. An unexpectedly enormous changed-file list, especially one dominated by a single application’s cache or data directory constantly rewriting itself, points directly at a specific app worth excluding via Step 7 rather than a genuine Time Machine problem at all.

Step 9: check whether Spotlight indexing is competing for the same disk I/O

Because Spotlight indexing and Time Machine both perform sustained disk I/O, a backup that coincides with an active Spotlight reindex (after a large data restore, a new external drive, or a recent mdutil -E) competes for the same disk bandwidth and can slow both operations noticeably. Checking mdutil -s / for active indexing before assuming Time Machine itself is the sole cause of a particular slow backup window rules out this specific, easily-confused overlap.

Related:

Sources: