Time Machine ridiculously slow after El Capitan upgrade

Question

I recently updated to El Capitan, and told Time Machine to backup. It got stuck on Preparing Backup for hours, so I stopped it, deleted the InProgress file, rebooted and tried again. After ~30 mins, Time Machine was still preparing. I looked into activity monitor and backupd had only read ~140Mb, in 30mins... Looking into iStatMenus, I find that backupd tends to have a read speed between nothing, and 120Kb/s (If I'm lucky. It sometimes peaks up to to 500kb/s, and very rarely 1Mb/s). Spotlight is not indexing (As I heard sometimes Spotlight gets in the way of backupd), and the hard drive has gone to sleep in the time that I wrote this, rarely waking up for my Mac to briefly read something from it.

Here's what comes up in the console when searching for backupd:

I'd rather not have to reformat my hard drive, in case I ever want to downgrade back to Yosemite, however I am willing to if it solves the issue.

Also, it seems like whenever I reboot my Mac, the hard drive loses its Time Machine icon, and reverts back to an orange drive.

Screenshot of Activity Monitor, Disk mode at ~50 min mark:

EDIT: I've tried disabling and reenabling Spotlight for the disk, and I have also wiped the .Spotlight-V100 folder and rebooted. No change.

EDIT 2: What seems to be some errors has appeared in the console

EDIT 3: After many, many hours, Time Machine has finished scanning and is now backing up! I'd still like to know why it took so long (I didn't expect updating to El Capitan to take so long. I excluded system files as well, although I guess I'm in for another long wait since I just removed them from the exceptions list)

Answer 1

Part of the issue is that low priority input/output-operations (I/O) now seems to get throttled heavily. You can check it via Terminal (can be found via Spotlight (usually bound to ⌘Space) and entering terminal) then entering at the bash prompt:

sudo fs_usage backupd

and look for the THROTTLED entries. If you see them, the backup is throttled.

So if you have a ton of files, just the time it takes to do the I/O takes forever, even if the files are small (because it performs a bunch more I/O operations around xattrs etc. than it used to).

Go to a Terminal and enter:

sudo sysctl debug.lowpri_throttle_enabled=0

For me, this speed it up from 72 hours to ~4 hours on an filesystem with 2.5 million files.

It's also a good idea to re-enable the throttling after your backup finished successfully with the following command

sudo sysctl debug.lowpri_throttle_enabled=1

Answer 2

I confirm that the command:

sudo sysctl debug.lowpri_throttle_enabled=0 

works perfectly.

If you want to make it permanent across reboot, you can do the following.

• create a file under /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>Label</key>
      <string>fix-el-capitan-slow-time-machine-speed</string>
      <key>ProgramArguments</key>
      <array>
        <string>/usr/sbin/sysctl</string>
        <string>debug.lowpri_throttle_enabled=0</string>
      </array>
      <key>RunAtLoad</key>
      <true/>
    </dict>
  </plist>
  

• make sure the file belongs to root

  sudo chown root /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist
  

• issue the command

  sudo launchctl load /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist
  

You can find the content of the file at this gist

Answer 3

I found this article on the Apple discussion forums about the message that appears in the Console (while it's doing nothing or backing up at 10 bytes/second):

com.apple.backupd: Waiting for index to be ready (100)

In my case I was able to discard all old backups, so I dismounted the volume from the troublesome Mac, mounted the drive/network share from another computer (not a Mac), deleted the entire .sparsebundle directory (which took a surprisingly long time) and then started the backup again. It created a new .sparsebundle and it's now backing up at around 10 MB/sec.

If you didn't want to delete your existing backups, you could try one of the other suggestions on that page:

• rebooting in Safe Mode and then back to normal;
• tell Spotlight not to index the Time Machine volume/disk;
• deleting the Spotlight index, .Spotlight-V100 (which I didn't have);
• using mdutil to disable and re-enable Spotlight indexing on the volume:
  • sudo mdutil -i off /Volumes/Time\ Machine\ Backups
  • sudo mdutil -i on /Volumes/Time\ Machine\ Backups

(see that discussion for more details and ideas).

Answer 4

I had similar problems after moving to El Capitan - backups (even small incremental ones) slowed to a real crawl. So I did a wireshark dump of the chatter between the Mac and the NAS, and saw numerous failed FPGetFileDirParms requests. AFP is (was?) the protocol time machine uses to talk to NAS drives, but I've read that they're moving to SMB.

174 0.390744    192.168.0.9 192.168.0.10    AFP 107 FPGetFileDirParms request: Vol=3 Did=62779 Name=._1b6c
176 0.391729    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object not found (-5018)[Malformed Packet]
178 0.392002    192.168.0.9 192.168.0.10    AFP 101 FPGetFileDirParms request: Vol=3 Did=93632
179 0.392909    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object is the wrong type (-5025)[Malformed Packet]

I have no clue why these requests failed, but the number of these failed attempts is HUGE - the actual data transferred is minuscule compared to the number of these failed requests - and hence the slow, crawling, speed.

What worked for me was:

1. I went to Time Machine Preferences->Select Disk and removed the currently associated disk (which was connected to afp://MyBookLive.local/TimeMachine)
2. Went to Finder->Go->Connect to Server. Typed in the ip address of the NAS drive in the "Server Address" space (smb://192.168.0.10 for me)
3. Connect. It threw up a list of volumes to mount - chose the volume used for time machine (TimeMachine for me). TimeMachine got mounted in /Volumes.

4. From terminal, ran:

   sudo tmutil setdestination /Volumes/TimeMachine
   

That's it. Time machine is now associated with /Volumes/TimeMachine instead of afp://MyBookLive.local/TimeMachine. Previous backups were good, and incremental backups that happened after this have been FAST. A wireshark dump I did after this showed no failed AFP requests (although AFP was still the protocol being used).

Answer 5

I wasn't able to fix problem, however, I have found out that my time machine slows down when it backups data of other users (not logged in one). Might be some problem with permission exists in the other's Users's folder files. When I added that user into exception list, TM rocks.

Answer 6

Related to Daniel Berlin's answer, above (but I'm new here so don't have enough cred to just comment there), I found his terminal command to work GREAT for me in OSX 10.11.3. Turned 30-hr backup into 4-hr! However, it doesn't remain after a restart.

I didn't want to have to type into terminal every time I restart, so...

Since I'm not very versed on shell scripts, I googled around enough to create an Automator workflow that prompts for user to input the root password, then executes the terminal command. I chose to confirm success with a notification center alert.

I saved the workflow as an application, and added it to my login items. So now at every login I'm prompted to enter my password again to "un-throttle" Time Machine.

There are ways to make the process invisible with shell scripts, but it's a bit complicated needing the root access gained by the sudo command. One could also hard-wire the password inside the Automator app if unconcerned about security. (Not recommending.)

I'd post the workflow app here but apparently can't upload a file to this answer. So I'll attach a jpg of it for anyone to recreate if they like. P.S. Note the Pass Input "as argument" for the shell script

Answer 7

My problem was remedied by D.W.Hoard's article: restart to safe mode, then back (for me, the computer seemed to shut itself down during safe boot).

Macbook Air mid-2011, OS X 10.11.3, backing to Time Capsule.

---

Edit: Actually, it seems after the safe-boot & normal boot, Time Machine only got to about 41/55GB (within an hour) and became crawling again (has progressed only 2,75GB within 12 hours since then. Too bad - I bought the Time Capsule simply to avoid this kind of incompatibilities and here I am - all Apple devices and a lousy experience, waste of time. I hope you others find a lasting solution.

The console is getting a new entry for mdworker about every second - is this normal while backup is happening?

---

Edit 2: Succesful! The laptop has two user accounts and it may be that logging into the second caused the rest of the backups to proceed. Worth testing if you're in a similar situation.

Answer 8

I've got the same issue, and I've found what looks a solution (not wonderful but it works)

format your external HDD and check that you have a real good bandwith (test your usb3) pay attention of your TM settings, here I forgot so much other partitions and disk images that I don't want to back up, it would increase bck time. launch the first backup. EVERY 2-3 hours, restart your computer.(yeah, not fun, but I noticed that the first hour is usually fast, and after this time it becomes slower) that's all, I was able to backup 1,5To in a morning..

Answer 9

Please see this note from Apple:

OS X El Capitan: If Time Machine is slow

Try these suggestions if Time Machine is slow.

• The first time you use Time Machine, set it up in the evening so that the initial backup can be done overnight.

• If your backup disk is a Time Capsule, leave your Mac in the same room as the Time Capsule for the initial backup, or use an Ethernet cable to connect your Mac to one of the Ethernet ports on the Time Capsule.

• Virus scanning software can make Time Machine backups very slow. If you use Norton AntiVirus or a similar product, try to exclude your backup disk from automatic scanning. Also make sure you are running the latest version of the virus scanning software.