mountain lion breaks time machine

Very odd. 😟

This is the USB 3 disk, right? Perhaps all is not well with it . . .

Try erasing the eSATA and see if it will do the same initial and subsequent incremental backups as the one you're trying to do to the USB 3.

Yes it's the USB 3 one. I don't think there is much wrong with it though, since it backs up perfectly after every reboot. It is only subsequent back-ups on the same boot session that fail. That must surely be TM??? Here is the buddy report for today's attempt:

Starting automatic backup

Backing up to: /Volumes/Hengist TM HD and Video/Backups.backupdb

Using file event preflight for Macintosh HD

Will copy (1.8 MB) from Macintosh HD

Using file event preflight for Mac Files

Will copy (Zero KB) from Mac Files

Found 209 files (1.8 MB) needing backup

1.37 GB required (including padding), 488.28 GB available

Stopping backup.

Error: (-47) SrcErr:NO Copying /private/var/db/crls/ocspcache.db to /Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro/2012-10-25-134412.inProgress/82D7F918-A168-4497-A08A-B6A3A55517CC/Macintosh HD/private/var/db/crls

Copied 225 files (73 KB) from volume Macintosh HD.

Copy stage failed with error:11

Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro size:37

Backup failed with error: 11

Starting manual backup

Backing up to: /Volumes/Hengist TM HD and Video/Backups.backupdb

Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro size:37

Backup failed with error: 2

Starting manual backup

Backing up to: /Volumes/Hengist TM HD and Video/Backups.backupdb

Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro size:37

Backup failed with error: 2

Why does it need 1.37GB for a 1.8MB back-up?

rhjph wrote:

Yes it's the USB 3 one. I don't think there is much wrong with it though, since it backs up perfectly after every reboot. It is only subsequent back-ups on the same boot session that fail. That must surely be TM???

I'm not so sure. That didn't happen with the other drive, did it? And both were backing-up your boot drive, right?

Error: (-47) SrcErr:NO Copying /private/var/db/crls/ocspcache.db to /Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro/2012-10-25-134412.inProgress/82D7F918-A168-4497-A08A-B6A3A55517CC/Macintosh HD/private/var/db/crls

It's not clear exactly what error 47 is. 😟 Something to do with the connection to the backup drive, or the file system on it.

The SrcErr:NO means the problem is not with the drive/file being backed-up (a system file on your OSX drive).

Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro size:37

Again, a problem setting the Mac's UUID as an extended attribute on the Computer folder in your backups.

Found 209 files (1.8 MB) needing backup

1.37 GB required (including padding), 488.28 GB available

. . .

Why does it need 1.37GB for a 1.8MB back-up?

Excellent question. Prior to Mountain Lion, the "padding" was about 20%, apparently with a minimum of about 100 MBs. During beta testing of ML, I saw that backing-up exactly the same small amount of changes to 2 different drives resulted in wildly different amounts being added. I filed a bug report about the change. The response was that in some circumstances (no details, of course), TM has to duplicate the Spotlight index, so during setup, TM considers the size of the index on the destination drive.

Interestingly, I have now removed this disc from back-up and tried to eject it, but it steadfastly refuses. When I next reboot I shall change it for the other big USB 3 disc, erase it and then back everything up to it - that'll be 5- 6 hours I guess. We shall then see whether we have the same problem.

OK, so erased the 3TB USB3 disk and backed up everything. It worked fine and did several incremantals. Took that off and connected the troublesome USB3 2TB disk. Erased and repaired that, then made sure that I replaced the 3TB one in TM (rather than selecting the alternating option). Backed up to that, and it has now done several incrementals. So fingers crossed everything is now working as it should. The problem appears to have been that TM had got its knickers in a twist with the alternating option. It looks as if that should only be used when you have two similar disks both connected and each doing the same backup - i.e. same exclusions etc. I have not reinstated the "Put hard disks to sleep when possible" option, which was unmounting USB3 disks on waking them. I'll wait until someone has found a solution to that problem.

rhjph wrote:

. . .

It looks as if that should only be used when you have two similar disks

No. It doesn't matter. I have a partition on a directly-connected FW/800 drive, my Time Capsule's internal HD, and a partition on a USB drive connected to the TC, two different sizes, all in rotation. It works fine (and has since the first beta version of Mountain Lion in February):

each doing the same backup - i.e. same exclusions etc.

There's only room for one set of exclusions -- all disks "in rotation" will use the same one.

Although it's theoretically possible to have different exclusions for different drives via the tmutil command, I've never tried it and it's usually much better to simply use a different backup app.

Part of your problem, I suspect, was some error in changing exclusions.

Thanks, Pondini. All your assistance has been both most useful, and comforting.

Well how about this? After 20 hours and 11 incremental back-ups (and one overnight reboot) the problem has returned, with errors 2 and 11. I noticed yesterday that I had a 19h41 back-up, two 21h41 back-ups (nothing at 20h41) and then a 22h41 back-up. Today everything ran fine until 14h53 when it failed to create the back-up file. Rebooted and everything running again normally.

Here's the trail:

Starting automatic backup

Backing up to: /Volumes/Hengist TM HD and Video/Backups.backupdb

Using file event preflight for Macintosh HD

Will copy (2.1 MB) from Macintosh HD

Using file event preflight for Mac Files

Will copy (Zero KB) from Mac Files

Found 241 files (2.1 MB) needing backup

1.38 GB required (including padding), 492.88 GB available

Stopping backup.

Error: (-47) SrcErr:NO Copying /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist to /Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro/2012-10-30-145258.inProgress/CBB01766-8E1A-[****]-[****]-533C91DA0C68/Macin tosh HD/Library/Application Support/CrashReporter

Copied 29 files (48 KB) from volume Macintosh HD.

Copy stage failed with error:11

Backup failed with error: 11

Starting automatic backup

Backing up to: /Volumes/Hengist TM HD and Video/Backups.backupdb

Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro size:37

Backup failed with error: 2

Starting automatic backup

[and then the same thing twice more]

rhjph wrote:

. . .

Backing up to: /Volumes/Hengist TM HD and Video/Backups.backupdb

That's the USB3 drive?

Error: (-47) SrcErr:NO Copying /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist to /Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro/2012-10-30-145258.inProgress/CBB01766-8E1A-[****]-[****]-533C91DA0C68/Macin tosh HD/Library/Application Support/CrashReporter

That's the same Error -47 on the destination drive (TM happened to be copying a different system file, a .plist).

Error: (22) setxattr for key:com.apple.backupd.HostUUID path:/Volumes/Hengist TM HD and Video/Backups.backupdb/Richard’s Mac Pro size:37

And OSX can no longer write to the drive.

If this is the same USB 3 drive you've been having trouble with, there does seem to be some sort of intermittent problem with it (or the connection or power to it).

Yes this is the one I have had trouble with. But I previously had trouble with the other USB3 drive - not being recognized or spontaneously unmounting. So far, after erasing that one and starting with TM on it from scratch I've had no problems. Then I did the same thing with this drive, and it worked perfectly for 20 hours, then this problem returned. It doesn't unmount and I can read it OK- it's just that TM won't continue to back up to it until I have rebooted. In fact once TM rejects it, I can't unmount it. This doesn't have the hallmark of a mechanical fault to my way of thinking and I'm using the same lead and power supply that I use for the other USB3 drive.

rhjph wrote:

. . .

In fact once TM rejects it, I can't unmount it. This doesn't have the hallmark of a mechanical fault to my way of thinking and I'm using the same lead and power supply that I use for the other USB3 drive.

Since it seems limited to that drive, it sure sounds like something is wrong with it. And it could be the electronics or even a marginal connection inside the enclosure, not necessarily the hardware.

As you will appreciate I am no expert, but the repeatability of the parameters of the phenomenon suggests to me that if it is in the disk, then it is a firmware incompatibility problem, or something similar, rather than a dodgy connection or component. When the disks were spontaneously unmounting I was pretty convinced there was a malfunction in the USB3 card or its driver, but now that's disappeared it seems it was only the Apple software after all.

I'm having the same problem. My wife's iMac is running 10.8.2. Our Time Machine is a partition on a QNap network attached box (which has a special setup just for Time Machine). As others on this thread have noted, Mountain Lion creates a second entry in the disks list for Time Machine. Occasionally the backup is successful. More often, however, Time Machine is unable to find the QNap.

What makes this more interesting is that I use a MacBook Pro running snow leopard 10.6.8. I have never had a problem backing up to the QNap. Both the MacBook and iMac are connected to the network through a gigabit ethernet switch box. Apple really needs to do something about this. Thanks.

Tony Lima

😕

I believe this solves it! After working on this for weeks & weeks & weeks! I have two OS 10.5.8 Macs both running Time Machine (TM) via Wi-Fi to back up on a third Mac running OS 10.8.2. The third Mac has four external backup drives available. When I upgraded the third Mac to 10.8.2 (Mountain Lion), one of the 10.5.8 Wi-Fi TMs stopped backing up to the 10.8.2 Mac but the other 10.5.8 Mac continued to back up via Wi-Fi just fine. I've tried just about everything suggested in the numerous threads on this topic - different drives, repairing the sparsebundle image, deleting the sparsebundle image (I kept copies), changing privileges, changing rights, sleep/no sleep, etc., etc., etc. Nothing worked. The weird thing is that the other TM kept running without a hitch.

Today I found this posting:

http://superuser.com/questions/249611/how-to-forceably-unmount-stuck-network-sha re-in-mac-os-x

That's the answer!! The Volumes folder on the failed 10.5.8 TM Mac was full of failed backup entires. So, to clean out the bad Backup entries (there were a hundred - really!) and move them to the desktop, I used Terminal to move all the bad entries into a folder called "Back", and TM started working again! (I subsequently deleted "Back".)

Here are the Terminal commands (note: case matters):

• To check the contents of the Volumes folder:

ls /Volumes

• To create "Back" on the desktop and move all the bad entries into it that start with "Backup":

sudo mv /Volumes/Backup* ~/Desktop/Back/

Be careful, of course, that there's nothing in Volumes that starts with "Backup" that you don't want to move...

Good Luck!!

BillPatsy wrote:

. . .

That's the answer!! The Volumes folder on the failed 10.5.8 TM Mac was full of failed backup entires. So, to clean out the bad Backup entries (there were a hundred - really!) and move them to the desktop, I used Terminal to move all the bad entries into a folder called "Back", and TM started working again! (I subsequently deleted "Back".)

Yes, that happens sometimes, apparently when OSX loses track of a volume at just the wrong time, and creates a folder in the /Volumes folder instead of an alias to the external volume. And it happens with local drives, too, and other backup apps, not just Time Machine.

You probably don't want or need Terminal, or to move the bogus folders to your Desktop. You can just delete them via the Finder. See the blue box in Where did my Disk Space go?