Q: time machine very slow with mountain lion

Oh I also want to point out that the clean install was with 10.8.2, since that's what downloaded when I did the install. So I can't say it wouldn't have worked with 10.8 or 10.8.1.

That is interesting that it wouldn't still work with a clean install. You should try to open a case with AppleCare. That points to a problem with OS X or a hardware problem in your case.

However, I want to point out that CCC uses a completely different method of backing up than does TM. So, I wouldn't draw any conclusion that because one works and the other doesn't that X is true. When I was still having the TM problems, CCC also worked for me.

Believe me, I use my MBP all the time as well. It was extremely painful to take so much time. I had to do it evenings and weekends as I had time. In the end, it was worth it to me to have a working TM backup (which I prefer over CCC).

One other reason why I'm sticking with CCC is that TM had other problems on Mountain Lion. My biggest gripe was that it would make the Mac very unresponsive when it was backing up. If I was going to be busy for a while, I would have to shut TM off so I could actually get work done.

CCC on the other hand runs smoothly in the background and I wouldn't even know it was running if not for the window that pops up. I have it running once at the end of the day, and that's been enough for me. I have already used it to retrieve files I had deleted or changed using its archive feature.

So except for the cool interface, I haven't missed TM.  CCC is doing what backup software is supposed to do, while TM, which was working great for me for a long time, isnt.

I can tell you in my particular case that it did seem to help. Transfers went from about 1kB/s to 5MB/s.  Did you happen to do the full defrag out of curiosity?  It's not the default.  I took a long time for me at 2-3 hours with 128GB SSD.

The reason why I would believe that fragmentation would have an impact is that time machine looks like it works on the file level and not the block level. I assume this is true because after a full defrag where everything gets moved around a block level snapshot would require a full resync to time capsule. The delta in my case was about 15GB, so I assume that's about the size of MacOS and some email resync that changed between the upgrade and the successful backup.

However, if this were true then another app should suffer as well. You point out that CC doesn't. I wonder if some kind of index gets trashed.  This could explain why the initial prep time takes longer than it did before. At 128GB the amount of data isn't large by today's standards. I wonder if the SSD's speed plus smallish capacity is making something normally unbearable bearable.

@LegalGeek

I hate to disagree with you, but the underlying disk technology has no bearing on whether a file system will fragment or not. The speed of an SSD may mask the need for it for a while (perhaps a very long while), but after years of operation any file system will fragment, and the nice clean extents that you had when the drive was new and fresh smelling will be broken up. That said, Unix file systems don't fragment as fast as say our Windows friends, so most people never get to this stage.

@DanHambone: You should never defrag an SSD. The benefit of having an SSD is near-instantaneous access time to get to the data. Platter dirves, on the other hand, do suffer inherent performance degradation when data is scattered across the drive.

Here is a blog post from Coriolis Systems, the maker of iDefrag. See footnote 1.

http://www.coriolis-systems.com/blog/2009/04/real-world-fragmentation.php

"For avoidance of doubt, we strongly recommend that you don’t try to defragment your SSD-based volumes."

Here is an article from another defrag software vendor...

http://blog.raxco.com/2011/06/20/ssd-optimization-not-ssd-defrag/

"While there has been much discussion around whether or not to defrag a SSD – the consensus is in. Do not defragment an SSD. In fact, you can do more harm than good by performing a defrag on an SSD."

My 1 TB harddrive was fully defragged. It has about 600GB of data on it. That took about 12 hours. The backup drive had been reformatted several times, and obviously when I did my clean install I had reformatted the boot drive. Therefore there was zero fragmentation. I keep my drive defragged (I do it once every few months) because I do multi-track audio recording, and disk performance is important. Since this incident I use an external drive for the audio files.

One reason why I know it has nothing to do with fragmentation is that my hard drive was already backed up in TM. At that point TM was just recording the changes, and they are fairly small. And they are written at where the free space started on my hard drive. So it would not be hard for TM to copy them.

The other reason is that TM had been running fine, and then just stopped. Three whole days went by and it was not able to complete an hourly backup. I don't recall how big that backup was, but I posted it earlier in the thread. It wasn't big. After I erased the backup drive, it was going to take over a month to back up.

What ever the differences are in the way TM and CCC work, one thing is clear; TM is broken, and CCC is not.

My configuration is nearly identical to yours, but my backups with Time Machine are EXTREMELY slow -- so slow as to be totally impractical.

I just enable Time Machine in the server. Before I started working with server I did not see such horrendous performance.

I've seen reports that disabling Spoltlight gets rid of the problem, but I saw absolutely no change with Spotlight disabled.

I read, perhaps on this thread, that resetting the PRAM solved that posters problem with Time Machine backup performance. I was leary but tried it anyway. As expected, reetting PRAM had no effect. I've got an 86 Gb initial backup that Time Machine says will take 3 DAYS, if you can believe it!!!!!!!!!!

This extremely poor performance of Time Machine has been noted for months, and it's incredible that there has been no fix in all that time. I was just wondering if maybe the "spotlight" needs to be turned on at Apple, if you catch my drift.

Hi Folks.  I have been struggling over this for days.  I have had all the same problems reported here and elesewhere.

I am backing up to a network drive, which in my case is a shared drive using AFP from a 10.6 machine.

Starting a clean backup appears to work correctly, but somewhere along the process the transfer drops down to just a few k/s and the time to finish backup mounts to hours, then day, then years. :S

Normal backup speeds over gigabit eithernet are between 15-95MB/s

My backup set is ~ 900 gigs.

Previous to this fix I was never able to get more than 20-30 gigs backedup (many times a lot less) before the backup slowed to a crawl.

I began to suspect it had something to do with network negotation, especially since some people had reported that ML Server seems to fix things. Basically just the backup drive network link would slow to a crawl, but everything else on the network was running perfect.

What I did was simple,   Turn IPV6 off.

System Prefferences -> Network -> (your network interface you are backing up over) -> Advanced -> TCP/IP -> Configure IPv6,  Link-local only

Please note I did start with a fresh backup, so you may need to go delete your previous failed (halfway?) backup...

I am very interested to see if this works for anyone else.. It seemed to be the difference between night and day for me.

*EDIT*

I should add that the successful backup took ~5 hours for ~900gigs.

Message was edited by: The_Master121

I totally agree! Been an IT profesisonal for years. Redundancy is key.

I had this problem today. I use a USB 3.0 external drive for my backups. It all worked well for the first backup, but for the second one it was copying data at 1 KB/s. I had to format the drive for it to work again properly. I believe that it's a problem beyond network issues with Time Capsules, since my connection is USB.

Apple should take a closer look at this.

I've read a lot of the posts and tried a number of suggestions - nothing worked for me. I've been trying to backup via a network mounted drive using ethernet (gig switch).

I've given up for now and resorted to using Wi-Fi connection - instead of 84k/s I'm getting consistent 8.4Mb/s!!! 111GB backup likely take 1 to 4 hours (fluctuates a bit). Nearly 1 million files. For me it's clearly ethernet connection problem. I'd tried the sudo commands, permissions, spotlight exlcude discs, specific login users etc etc.

Until Apple fix I'm quicker just using Wi-Fi and getting on with my work & life. Those having ethernet issues try the Wi-Fi approach, if Wi-Fi don't work for you hope you can find a workaround, good luck. I'm running 10.8.2 on MBP connecting to MacMini (2012) 10.8.2 with USB3 brand new 3TB (partitioned to 3x 1TB drives).

Springy, since yor problems is the same as mine (ethernet as opposed to the other types of conections) have you tried switching DHCP modes on the client computer (the one that's being backed up)?  I  didn't see that in the list of things you've tried.

I switched from DHCP to "DHCP with manual address" and then back to DHCP and this seems to have kicked my ethernet into  high gear.

I am also running server on all of my computers, but this does not seem to have had any effect.

But there was a direct causal change when I switched DHCP modes in the network preference panel.

After my post above I found that the IPV6 change did not fix things.  What seemed to fix it while connected to eithernet was when having a slow backup, to go into the network prefferences and change the IP to a static ip then click apply.  The moment you do that and the ip is refreshed, it starts backing up at full speed...