Apple - Repair Time Machine sparsebundle that will no longer mount

I have a write up on how to try and repair NAS-based sparsebundle errors on my blog. In summary:

1. hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your disk}/{name of}.sparsebundle

   You will then see something like

   /dev/diskx Apple_partition_scheme
   /dev/diskxs1 Apple_partition_map
   /dev/diskxs2 Apple_HFSX
   

   Where x is the disk id for the external disk. x might be 2, 3, 4 or higher. You are interested in the one labeled Apple_HFSX or Apple_HFS.

2. fsck_hfs -drfy /dev/diskxs2 using whatever relevant device was located in Step 1.

   Hopefully, you will eventually see

   The Volume was repaired successfully

3. hdiutil detach /dev/diskxs2

---

However, since OS X 10.6.3, Time Machine will refuse to write to a destination volume that fails its verification. Even if the process above succeeds in recovering the backup, you may still need to remove the black marks that Time Machine wrote when it failed verification.

4. Unlock the sparsebundle

   chflags -R nouchg /Volumes/{name of your disk}/{name of}.sparsebundle
   

5. Move it back to its original location

   mv /Volumes/{name of your disk}/{name of}_YYYY-MM-DD.sparsebundle /Volumes/{name of your disk}/{name of}.sparsebundle
   

6. At the top level directory of the sparsebundle, edit the file com.apple.TimeMachine.MachineID.plist.

   • Remove

     <key>RecoveryBackupDeclinedDate</key>
     <date>{whatever-the-date}</date>
     

   • Change

     <key>VerificationState</key>
     <integer>2</integer>
     

     to

     <key>VerificationState</key>
     <integer>0</integer>
     

Extended attributes on the sparsebundle may be preventing writes on the file:

Run

chflags -R nouchg flattop.sparsebundle

But be careful, the sparsebundle may have been protected because it genuinely is broken.

It's not that simple as chmod. First, it appears that 10.5 / 10.6 / 10.7 all have minor differences in how a sparse bundle is handled. Second, the flags and dirty/bad status of a sparse bundle are stored elsewhere. Third, you may need to attack the sparse bundle itself - not the filesystem that is contained within.

Your best bet is to let Disk Utility take a crack at repairing the image before you look at the filesystem embedded within. It works on both the bundle and the filesystems - as well as knows how Apple has stored things.

The details of the bundle are either proprietary or hard to discern from the developer docs - and it's certainly not something other third party utilities are keen to fix at this point. As long as you are using an equal or newer version of Disk Utility than the mac that made the backups, you should be fine. Once you've given up on Disk Utility - you might try something like Drive Genius or Disk Warrior - but I'd stick with Apple's tool if you hope to reuse this bundle.

The nature of sparse bundles - specifically the hard links as well as the concept that it's not compacted when files are deleted, there is a lot of work to be done. I have had DiskUtility run for two weeks and still not complete a repair pass on a 800MB sized archive.

In practice, you might be better off just reverting to a prior version of your NAS if it has snapshots or is backed up itself. In the end - if there are errors that fsck/Disk Utility can't fix, your sparse bundle will be marked as bad and it will be locked. You can then read things, but never write to it again. Do see if you can connect a machine to the storage and fix things (DAS or high speed connections are better - as is a machine that can have the time to fix things and not get rebooted is ideal)

Best of luck - this may not be recoverable from the details you provided.