time machine very slow with mountain lion

Thanks Jardar.

The backup never stopped or even slowed down at any one step in the process. The output lines displayed in Terminal were always flying by too fast to read, so there weren't any times significantly longer than a second or so. The lines were scrolling by quickly even when no data was being transferred and the backup appeared to be stuck.

In my case it seems that the sheer number (many thousand) of strange (to me) operations is slowing down my backups. That is just an uninformed guess on my part. This is relatively recent behavior, so it's all very puzzling to me.

Sorry for sending this post twice, but at my email-notification it didn't appear some days ago.

So, here it is again:

I called the German Apple Support!

The Apple-Engenieers know about the problem and are working on it, but the priority is not at much as high as we, the consumers, would like it.

So, please write your comments to this adress. They will be read, but not responded. But there will be a counter, so maybe we are climing at the priority-ranking. 🙂

http://www.apple.com/feedback/

With regards and apologize for my bad english

Frank

<Edited By Host>

I've got a MacBook Pro and a MacBook Air and this is an incredible problem. Three days to do a clean backup of 300 gigs to an airport usb drive makes this a useless feature.

We certainly hope Apple gets this fixed, however since Apple is a consumer electronic company, MacBooks and MacPros seem to take a back seat since they are not huge cash flow products like iPods and iPhones.

I would like to share that I fixed the problem by either using "sudo tmdiagnose" in Terminal or quitting dropbox. I'm not too sure what fixed it!

I was trying to do my first time machine backup of around 200gb over USB 2.0 and it said it would take 9 days. In 5 hours it transferred 5gb. I then ran "sudo tmdiagnose" in Terminal, restarted my Macbook and quit Dropbox and it took around 4-5 hours to complete the whole backup (:

I hope this helps someone!

For those of us with slow ethernet backup performance that is fixable by switching to a manual ip configuration instead of DHCP, I have written a little script that does this automatically.

The script first disables WiFi to make sure the backup will continue to use the Ethernet connection.

It then switches the ethernet connection to manual config, then back to DHCP (this seems to be enough to kick the connection into full speed).

After a pause, the WiFi adapter is turned back on again.

Have fun!

#!/bin/sh ETH=`sudo networksetup -listallnetworkservices | grep "Ethernet" | head -1` WIFI=`sudo networksetup -listallhardwareports | grep -A 1 "Wi-Fi" | awk '/Device:/ { print $2 }'` if [[ $ETH == "" ]]; then     echo "No Ethernet network adapter found" >&2     exit 1 fi if [[ $WIFI == "" ]]; then     echo "No Wi-Fi network adapter found" >&2     exit 1 fi echo "Turning Wi-Fi off" sudo networksetup -setairportpower "$WIFI" off echo "Resetting $ETH" sudo networksetup -setmanual "$ETH" 192.168.178.99 255.255.255.0 192.168.178.1 echo "...\c" sleep 1 sudo networksetup -setdhcp "$ETH" for a in 1 2 3 4 5 6 7 8 9 0; do     echo "...\c"     sleep 1 done echo echo "Turning Wi-Fi back on" sudo networksetup -setairportpower "$WIFI" on

I've tried these tips, and unfortunately, my Time Machine backup is showing 44 days for 354 GBs. I'm backing up to a freshly formatted external firewire 2 TB drive.

After hours of mucking around trying to eliminate causes of the slow backup (on a MacBook Pro upgraded from L to ML) I decided to check the console log and see what was going on. Noticed a heap of sandboxd errors and all sorts of weird permission issues. Used Disk Utility to try and fix ... nothing.

Stumbled onto another log about booting into Safe Mode and it does some really useful stuff in particular:

- It forces a directory check of the startup volume.

- Mac OS X v10.5.6 or later: A Safe Boot deletes the dynamic loader shared cache at (/var/db/dyld/). A cache with issues may cause a blue screen on startup, particularly after a Software Update.

- etc

Note: takes a while to reboot too ( http://http://support.apple.com/kb/HT1564 )

Anyway went back to fiddling with Backup and noticed immediate benefits for the painful backup issue:

- preparing for backup took only about 20 seconds instead of hours

- backup is now ripping along and instead of quoting 30 days to finish is down to 4 hours (currently ripping along at 15-20 MBytes / s).

- I have a feeling this removes rubbish left over from previous versions which is causing the issue (anecdotal)

Also it is worth opening the sparse bundle on the Time Capsule (view package contents) for the initial backup and check the bands directory.

- it should rip out about ~160 new 8.4MB bands in about 20 - 30 seconds ..... this is the preparing for backup stage

- then backup should start which will smash out huge numbers of 8.4MB files as it progresses

- if the preparing for backup writes less than 10 files in the first 20 seconds you know you are in trouble as it will spend forever on preparing for backup - which is the system of the original problem

It is a widespread bug that it is not related specifically to Time Machine/Capsule (it also happens with Carbon Copy Cloner, CrashPlan, etc) or with different brands of external drives connected by USB (2.0 or 3.0), FireWire, Thunderbolt, a ethernet or wifi (abg or n) network, etc, or even in different partition of your internal hard drive. Till now there is no magical solution proposed in this forum that works for everybody (just for a few).

The supplemental update to 10.7.5 seems to have solved the problem to those that are with Lion.

The best that you can do is keep insisting with Apple till they release a supplemental update for ML that specifically deals and solves this issue.

So, please write your comments to any of these adresses. Apple will be read it, but they won't answer it (Tim might 😉). May be if manny of us write, Apple might give a top priority to this bug. 🙂

You can complaint here (Apple general complaints):

http://www.apple.com/feedback/

or here (OS X general complaints):

http://www.apple.com/feedback/macosx.html

or here (Time Capsule complaints):

http://www.apple.com/feedback/timecapsule.html

<Edited by Host>

cfsdoriga wrote:

It is a widespread bug that it is not related specifically to Time Machine/Capsule (it also happens with Carbon Copy Cloner, CrashPlan, etc) or with different brands of external drives connected by USB (2.0 or 3.0), FireWire, Thunderbolt, a ethernet or wifi (abg or n) network, etc, or even in different partition of your internal hard drive. Till now there is no magical solution proposed in this forum that works for everybody (just for a few).

I'll have to disagree with you here. I was having no problem with a USB connected drive, until Apple broke something. On the other hand Carbon Copy Cloner is having no problem at all.

All the various things that seemed to have fixed some users Macs, such as booting into safe mode, changing the network settings, etc., did nothing for me.

The fact that nothing changed on my system except an OS update shows where the problem lies. And, it was fine after the update for a while, and then just stopped working one day. And I'm talking about an incremental backup, not a full backup. I probably posted how big that was, but it wasn't very big. So just out of nowhere an hourly backup stalled for three days. When I wiped the backup drive and tried to start over (after trying many things) it was going to take over 30 days. Carbon Copy Cloner took about 12 hours, from what I remember.

And now CCC does a single nightly backup, and it takes 20 to 30 minutes.

So this really is a Time Machine problem.

We agree that is a general problem. Of course that the problem started after Apple changed something.

I also agree with you that there is no a magical solution that works for all of us (such as booting into safe mode, changing the network settings, etc.).

Your CCC might work, but mine stop working after ML instalation. That's what I meant when I say it's a widespread and general problem that involves Time Machine, but goes beyond it.

I think that the best strategy is not to divide us discussing if is a TM problem or a CCC problem or if such solution works or not. For me the best strategy is to let Apple know with as many ways a we can that ML produced a problem to us, their customers, and that they are obly to give us a solution (as they usually, but not always does).

cfsdoriga wrote:

Your CCC might work, but mine stop working after ML instalation. That's what I meant when I say it's a widespread and general problem that involves Time Machine, but goes beyond it.

That's interesting. I had already been running ML when this happened. It was sometime after the first ML update (10.8.1) that it broke. The next update (10.8.2) did not fix it. After I updated to ML Time Machine was fine. The only thing different from Lion was that TM would slow down the Mac to the point where I could hardly work when it was doing a backup. I often had to stop the backup so I could keep working. But it backed up as quickly as usual until it just stopped one night.

CCC is a stand alone app, unlike TM, so I can't see why that would happen. Have you tried deleting CCC's preference files?

I really have NO problems at all, and believe me, I use many Macs myself, and with clients of me.

If problems occur on earlyer versions, they sure are solved with installing ML.

No. I haven't. I will. Thanks. 😉

dolfke wrote:

I really have NO problems at all, and believe me, I use many Macs myself, and with clients of me.

If problems occur on earlyer versions, they sure are solved with installing ML.

See for me, I didn't have any problems until installing Mountain Lion. It wasn't an upgrade installation, either- I wiped the hard drive first.

I'm going to try doing a safe boot and seeing if that makes any difference, as suggested earlier.

I've seen the same issues with slow TM backups on 10.8.2. I tried the "sudo tmdiagnose" which didn't work, but copying my current network location and using the new location (with no changes) kicked the backup into gear. I'd also tried rebooting to no avail prior to learning of the "sudo tmdiagnose" and network location tricks.