How to fix a Corrupted Time Machine backup

I use a dual G4/1000 running the Mac OS X Server software to provide TimeMachine services over our home network. There is an external firewire hard drive connected for the network users and their TimeMachine virtual back up disks.

This has been working out pretty well (as far as I knew) until this week when an iMac G4 crashed and was not able to start up again. When I looked at it, the iMac did actually boot up – once. I saw the desktop, saw the icons, and that is when I checked to see when the most recent TimeMachine back up was (last night at 7:42 pm). Because the user of this computer uses Entourage 2004 for her email, and Entourage 2004 keeps all it’s mail and attachments in one huge database glob, and it probably does not get a good backup of that glob unless Entourage was quit/closed during backup, I was concerned that we might not have a good backup. So I pulled the TimeMachine menu to get that started.

And within a minute, the iMac had kernel panic-ed. Oof! That can’t be good. Tried booting from a firewire hard drive, which also kernel panic-ed right away. Could be the internal hard drive is really corrupted, or maybe the computer is toast.

“Oh well” I said stoically, “At least we have hourly TimeMachine Backups!” … Except we apparently didn’t.

Because when I booted up an old G4 eMac with the Leopard installer CD to “Restore System from Backup” it was not able to mount her TimeMachine backup. Something about “operation not supported on socket” which did NOT sound good. Disk Utility was completely unable to fix anything. Even more scary – when I went to the Xserve & looked at the TM Sparsebundle file it was not openable there and the size was reported as 0, ZERO MegaBytes. I also did not like the “date modified” as June was several months ago!

Oh man! This is getting worse all the time! It is days like this that make me question why I do tech support professionally, much less as a hobby. But otoh it’s not like anyone else around here is going to do any better than I do. But it physically hurts me – pow- right in the lower gut, when things are not working well and I might have to deliver bad news. I really like it when things are working well. Luckily for me, things usually do go well, and I rarely get that painful feeling. (And as it will turn out, the modified date of the sparsebundle file apparently does not get updated by TimeMachine – so that is not to be worried about).

So, I searched the internet for “operation not supported on socket” and “time machine sparsebundle error“. i also tried using “get info” to give myself permmissions to that sparsebundle, but although it seemed like it ought to work, it did not.
The winning answer was a combination of several things I read, plus a couple of necessary additions of my own.

Here is what I did to fix that damaged TimeMachine SparseBundle file, so I could restore it to a different Mac that does work.

Begin by going to the XServe and disabling TimeMachine to prevent it from trying to mount this unmountable volume while I’m working on it. The rest of this also takes place at the Xserve keyboard.

Open Terminal and type;
hdiutil attach -nomount -readwrite /path/to/Louise123456.sparsebundle
(Substitute the path & name of your own sparse bundle of course.)
In my case this did not work. It failed as not being possible.
Tried again as SUDO without success.

Rebooted, (not just logged out/in… Rebooted to release the damaged volume which may have still reported itself as “busy”).

Opened Terminal, login root

While logged in as ROOT, then tried that command again, Hey! Here we go! It returned:
/dev/disk1 Apple_partition_scheme
/dev/disk1s1 Apple_partition_map
/dev/disk2s2 Apple_HFSX

So I now knew the unix name of the disk volume that needs fixing; disk2s2 (the one that is not the partition map nor scheme). Yours may be different.
So now type;
fsck_hfs -rf /dev/disk2s2
(substituting your disk’s unix name at the end there). R&F are to “Force” the repair on a journaled system, and “Rebuild” whatever is broken.
and expect to wait 5 to 55 minutes for the repairs to take place. (That time over 10bt for a 120gb TM volume). What you’re hoping to see is:
** /dev/rdisk2s2
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive catalog.
** Checking Extents Overflow file.
** Checking Catalog file.
** Rebuilding Catalog B-tree.
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive catalog.
** Checking Extents Overflow file.
** Checking Catalog file.
blah blah blah…. And then –

** The volume Backup of Louise was repaired successfully.

At this point – if you’re really lucky, you can double-click the sparse bundle file open. But I couldn’t. It gave me that same old dumb error we started with; “operation not supported on socket“. And the stupid thing still said it was zero mb in size. But after seeing that it knew some names of files inside the sparsebundle, I wasn’t fooled. But I ran the repair command again while I considered what to do next.
fsck_hfs -rf /dev/disk2s2

I logged out of the XServe, and logged in as Root. Some people will be quick to tell you that sudo is a better way, but I tried sudo and it did not work. But logging into the effing machine as root did work. Once logged in as ROOT, I was able to see that this file was 120GB (better than zero!), and simply double-click open that SparseBundle file which opened…. after several minutes. *WHEW*!!! and HOORAY!!!! I looked in there, and sure enough, it looks like a TimeMachine back up is supposed to look like.

Ok, so moving forward! I have a spare eMac that wasn’t doing anything important, so it is going to be her replacement Mac for now. I booted it up from the Leopard install DVD, (actually an external fw drive with a SuperDuper clone of that Leopard installer dvd – runs faster), selected my favorite language, and
Pulled the “Utilities” menu to “Restore from Backup“.
It asked what backup I want to restore from, and
I choose the Xserve volume, providing the username and password.
After several minutes of “checking” it finally comes back with the correct name of her backup volume (another good sign!) After informing me that this operation will completely erase whatever drive I select in the next step, I select the eMac’s internal HD as the destination and proceed.

As I write this, the replacement eMac reports that the “System Restore” with all user data will be finished in 19 hours or less. Wonderful. Everybody is going to be happy.

A chain is only as strong as its weakest link, and a network is only as fast as its slowest hub. So that is wired 10baseT speeds. I’ll be sleeping while the computers are working tonight!

Epilogue:

The Restore from Time Machine Backup went just fine, working from 10pm Sunday evening to 3pm Monday afternoon. So it guessed 22 hours, and only took 20. This on an eMac 1.42Ghz 1.5 Gb ram, over 10bt wired Ethernet, getting it from the firewire400 external hard drive attached to a Dual G4/1000 Tower running Leopard Server & TimeMachine services. When the eMac was restarted, everything was just as expected, even Entourage is ok. *Whew* and double *whew*! :-) What a relief. Btw, her sparsebundle file on the server never did update its modified date, and I guess it never will.

At some point I’ll take apart the errant iMac G4 and see if replacing its hard drive makes is useful again. I will also be putting a larger hard drive into service as the network TimeMachine Server. Moving a TimeMachine backup to a new hard drive is another article – (hint: Turn off TM, then use DiskUtility to “Restore” the old hd to the new hd, disconnect the old TM drive, and enable TM). Link