Time Machine Not Working? 12 Fixes for the Most Common Backup Errors

Time Machine sits at an awkward intersection of subsystems. To complete a single backup it has to coordinate the file system, the file system events daemon, network mounts, SMB or AFP, the sparsebundle wrapper, encryption layers, snapshots, and the user's own assumption that none of those will fail simultaneously. When something does fail, the surface error is usually a generic "an error occurred" with no useful context, and the actual cause is one of about a dozen specific things.

This guide is the field-tested list of those twelve things. Each fix follows the same shape: what the symptom looks like, what is actually going wrong underneath, and the exact steps to get back to a working backup.

First: Read the Logs

Before you change anything, look at what Time Machine is actually saying to itself. Open Terminal and run:

log show --predicate 'subsystem == "com.apple.TimeMachine"' --info --last 1h

This dumps the last hour of Time Machine activity. Scroll for words like error, fail, denied, or copying. The actual root cause is almost always written somewhere in there, even when the user-facing dialog said nothing useful.

For a quicker triage, you can also run:

tmutil status
tmutil latestbackup

The first prints the live state of the backup engine. The second tells you when the last successful snapshot completed. If latestbackup is days or weeks old, your "Time Machine completed a backup" notifications are lying to you.

Fix 1: Backup Taking Forever

Symptom: The progress bar inches forward over hours but never finishes. Estimated time remaining keeps growing.

Diagnosis: Two common causes. Either it is genuinely the first backup of a large data set (in which case it really is just slow), or fseventsd has lost its mind and Time Machine is doing a full scan instead of an incremental.

Fix:

1. If this is your first backup ever, just let it finish. A 1 TB initial backup over USB 3 takes 6 to 12 hours; the same over Wi-Fi can take days. Plug into Ethernet if you have a cloud destination.
2. If it is not the first backup, suspect fseventsd. Run sudo rm -rf /.fseventsd on the source volume, then reboot. The next backup will be slow because it has to rebuild the events database, but subsequent ones will return to normal speed.
3. Check Activity Monitor for backupd and backupd-helper. If CPU is high but disk I/O is low, the bottleneck is metadata scanning, not data transfer. fseventsd is again the prime suspect.

Fix 2: Stuck on "Preparing Backup..."

Symptom: The status reads "Preparing backup..." for hours and never progresses.

Diagnosis: The "preparing" phase is where Time Machine snapshots the source volume and walks the change log to determine what to back up. If the change log is corrupt or the sparsebundle on the destination has stale metadata, this phase can stall indefinitely.

Fix:

1. Open the Time Machine menu bar icon, click Skip This Backup. This kills the stuck job.
2. Wait 30 seconds, then trigger Back Up Now from the same menu.
3. If the new run also stalls, eject and re-mount the destination disk.
4. If the stall persists, run a fsck equivalent on the source volume from Disk Utility (First Aid).
5. Last resort: regenerate the fseventsd database with sudo rm -rf /.fseventsd, reboot, then back up.

Fix 3: Backup Disk Full, Sparsebundle Keeps Growing

Symptom: Time Machine reports the backup disk as full, even though you set a generous size limit.

Diagnosis: Sparsebundles do not auto-shrink as snapshots are deleted. When Time Machine thins old snapshots, the freed space is reported inside the sparsebundle but the sparsebundle file itself stays the size it grew to. On a destination shared with other data, the host file system runs out before Time Machine notices.

Fix:

1. Compact the sparsebundle. Eject it from Time Machine first, mount it manually, then run: hdiutil compact /Volumes/Backups/MyMac.sparsebundle.
2. If you cannot compact, you may need to copy the live data out, recreate the sparsebundle smaller, and copy back.
3. Set a hard size cap on the sparsebundle if your backup destination supports it. macOS itself does not expose this in the UI; you have to use tmutil setdestination or an admin tool on the server.
4. Consider a destination dedicated to Time Machine so other files do not compete for space. Cloud destinations like Capsule Backup assign a fixed quota that cannot be eaten by anything else.

Fix 4: Time Machine Cannot Find the Backup Disk

Symptom: "Time Machine couldn't find the backup disk" even though you can see it in Finder.

Diagnosis: The disk is mounted but Time Machine has lost the persistent reference to it (UUID or volume identifier mismatch), or the SMB share dropped and the auto-remount failed.

Fix:

1. For local disks: open System Settings → General → Time Machine, remove the destination, re-add it. Time Machine will detect the existing backup folder and continue rather than start fresh.
2. For network shares: eject and reconnect via ⌘K in Finder. Save credentials to Keychain so the auto-remount works in the future.
3. Verify the disk's filesystem is one Time Machine supports: APFS or HFS+ for local disks, SMB3 for network. exFAT and NTFS are not supported destinations.

Fix 5: "An Error Occurred" with No Other Information

Symptom: The classic generic error dialog with nothing actionable in it.

Diagnosis: This is the macOS UI giving up. The actual error is in the logs.

Fix:

1. Run the log query above to find the underlying error.
2. The error is usually one of the other items in this list: permission, network, sparsebundle corruption, full disk, or post-update breakage. Match it and apply the relevant fix.

Fix 6: Sparsebundle Corruption

Symptom: Time Machine refuses to mount the destination, or mid-backup it complains the sparsebundle is damaged.

Diagnosis: A sparsebundle is a folder of small "band" files that together form a virtual disk. If a band is corrupted (often because the source was unplugged mid-write or the network dropped during a critical metadata update), the volume becomes unmountable.

Fix:

1. Mount the share, locate the sparsebundle, and try mounting it manually by double-clicking. If macOS prompts for repair, accept.
2. From Terminal: hdiutil verify /path/to/MyMac.sparsebundle. This reports whether the volume is salvageable.
3. If verify fails, try: hdiutil attach -noverify -nomount /path/to/MyMac.sparsebundle to attach without mounting, then run Disk Utility First Aid against the attached image.
4. If repair succeeds, immediately run a fresh backup to a different destination. A sparsebundle that needed repair once is on borrowed time.
5. If repair fails: your snapshot history is gone. Start a new backup to a new destination. Read more about this in our restore guide.

Fix 7: Network Share Keeps Disconnecting

Symptom: Backups start, run for an hour or two, then fail with a network error. Often paired with a Finder notification that the server has disconnected.

Diagnosis: The SMB session is dropping. Causes range from Wi-Fi flakiness to router NAT timeouts to the server's idle disconnect policy to a misbehaving energy-saver setting that puts your Mac to sleep mid-transfer.

Fix:

1. Switch from Wi-Fi to Ethernet. Wi-Fi packet loss over a multi-hour transfer adds up.
2. System Settings → Energy Saver → uncheck "Put hard disks to sleep when possible" and "Wake for network access".
3. System Settings → Energy Saver → set "Turn display off after" to a longer interval, and confirm "Prevent automatic sleeping when display is off" is enabled if you are on a desktop.
4. For SMB-specific connection drops, edit (or create) /etc/nsmb.conf and add: [default] notify_off=yes signing_required=yes. The first reduces a chatty notification path that some servers handle poorly.
5. If your server enforces an idle timeout, schedule keep-alive activity or move to a destination designed for long-running Time Machine sessions.

Fix 8: Slow Incremental Backups

Symptom: Hourly backups that should take seconds are taking 20 to 40 minutes each.

Diagnosis: Either fseventsd is rebuilding (see Fix 1) or the source disk has so many small files that the metadata phase is naturally slow.

Fix:

1. Add common offenders to the exclusion list: node_modules, ~/.gradle, ~/.m2, virtual machine disk images, large container caches. These regenerate easily and are pure noise in a backup.
2. From Terminal, exclude programmatically: tmutil addexclusion ~/projects/big-monorepo/node_modules. Repeat for each path.
3. Confirm the exclusion took: tmutil isexcluded ~/projects/big-monorepo/node_modules.

Fix 9: Permission Errors (Operation Not Permitted)

Symptom: Logs report "Operation not permitted" on specific paths. Common targets are ~/Library/Mail, ~/Library/Messages, or third-party app sandboxes.

Diagnosis: macOS uses TCC (Transparency, Consent, and Control) to gate access to certain user data. backupd needs Full Disk Access to read these locations.

Fix:

1. System Settings → Privacy & Security → Full Disk Access.
2. Confirm Time Machine appears in the list and the toggle is on. If it is missing, add it manually using the + button and navigate to /System/Applications/Utilities/ or just search for it.
3. For some macOS versions you must add backupd directly. The path is /System/Library/CoreServices/backupd.bundle/Contents/MacOS/backupd.
4. Reboot. Run a manual Back Up Now and check the logs for residual permission errors.

Fix 10: Exclusion List Not Respected

Symptom: You added a folder to the exclusion list, but it still appears in the backup or counts toward backup size.

Diagnosis: The exclusion was added against an old path (the folder was renamed or moved), or the exclusion was added through one mechanism and Time Machine is reading from another.

Fix:

1. List current exclusions: sudo tmutil listexclusions.
2. If the exclusion is wrong, remove it: tmutil removeexclusion /path/to/folder.
3. Re-add against the canonical absolute path.
4. Force a fresh size estimate by running tmutil calculatedrift or simply waiting for the next scheduled backup; the exclusion will take effect immediately.

Fix 11: Encrypted Disk Will Not Unlock

Symptom: Time Machine prompts for the encryption password every backup, or refuses the password you know is correct.

Diagnosis: The Keychain entry for the backup disk has been removed, corrupted, or replaced. This happens after a major macOS upgrade, after a Keychain sync conflict via iCloud, or after restoring the system from another backup.

Fix:

1. Open Keychain Access and search for the name of the backup volume. Delete any duplicate or stale entries.
2. Run a Back Up Now and re-enter the password when prompted. Check "Save in Keychain".
3. If the password is rejected with an error like "wrong password" but you are confident it is right, try entering it via Disk Utility instead. Mount the sparsebundle through Disk Utility's "Mount" button and use the password there. If Disk Utility accepts it, the issue is purely a Keychain entry mismatch and re-saving fixes it.
4. If Disk Utility also rejects: confirm you are not entering the FileVault password by mistake, and read the Mac backup encryption explainer for the difference between the two layers. There is no recovery path for a genuinely forgotten Time Machine encryption password.

Fix 12: Time Machine Broken After a macOS Update

Symptom: Backups worked yesterday. Today, after a Sequoia point release, they fail.

Diagnosis: macOS updates routinely tweak the SMB stack, the TCC database, or the Time Machine internals. The breakage almost always falls into one of three buckets: lost Full Disk Access, dropped SMB credentials, or a sparsebundle that needs to be re-blessed for the new version.

Fix:

1. Re-grant Full Disk Access to backupd as in Fix 9.
2. Re-mount the SMB share manually via ⌘K and re-save credentials to Keychain.
3. If the destination is a network sparsebundle, eject and re-attach. macOS sometimes needs to re-validate the sparsebundle metadata against the new OS.
4. If none of that works, remove the destination from System Settings → General → Time Machine and re-add it. The existing snapshots will be detected and continued, not erased.

Preventive Maintenance

Most Time Machine failures are preventable with a small ongoing investment.

• Verify backups quarterly. Restore one random file via the Time Machine browser. Confirm the contents match. Do this on the calendar. If you have not done it in six months, do it today.
• Run hdiutil verify against your sparsebundle every month. Mount it, eject from Time Machine first, then verify. Catches corruption before it eats your history.
• Keep two destinations. Local USB SSD for fast recovery, plus an off-site cloud destination for disaster recovery. macOS rotates between them automatically.
• Document your encryption password. In a password manager. Today. The day you forget it is the day you also need it.
• Watch the menu bar icon. Click it daily. If the last successful backup is more than a day old, investigate.

When to Start Fresh (Last Resort)

If you have applied every fix in this guide and Time Machine still fails, the right move is sometimes to start a brand-new backup. Before you do:

1. Add a new destination on a separate disk and let it complete a full initial backup.
2. Verify the new backup with a test restore.
3. Only then remove the broken destination.

Never delete the only copy of your snapshot history hoping the new backup will work, because if it does not, you are now without backups at all. For details on choosing a fresh off-site destination, see the cloud Time Machine setup guide, or jump straight to our setup walkthrough.

The Bigger Picture

Time Machine is brilliant when it works and frustrating when it fails because the fail modes are so opaque. The dozen fixes above cover roughly 95 percent of the failures we see in the wild. The remaining 5 percent usually trace back to actual hardware death, in which case no fix is going to revive the disk and the right answer is a different destination, ideally one that you control end-to-end. Capsule Backup exists in part because cloud-based Time Machine destinations sidestep many of these failure modes by removing the disk-as-failure-point entirely.