Fix Time Machine Sparsebundle NAS Based Backup Errors

Time Machine

This is a modification of an original post for use when you have a corrupt sparsebundle backup on a NAS (as opposed to an external drive attached to a router) and it needs to be repaired. The NAS is likely a hardware product from the likes of Netgear, Synology, Buffalo or QNap – or for those of us with a home-grown backup server running FreeNAS.

The error you may see is “Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you.” This can be fixed by following the below.

From your Mac, connect to the network share that houses the sparsebundle.

At the top level of the drive are the various sparsebundles that make up your individual computer backups.

Do not double click on these sparsebundles or try to repair with Disk Utility.

Open Terminal and then switch to root by typing


sudo su -

and then enter your password.

The verication that has already run has marked your sparsebundle as bad, so first we need to make it look normal.

From the command line


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

This may take a little while.

Now type


hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your network share/{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. You are interested in the one labeled Apple_HFSX or Apple_HFS. It might be 2, 3, 4 or higher.

At this point, I have found that the filesystem check is already happening. You can check for activity by tail’ing the fsck_hfs.log


tail -f /var/log/fsck_hfs.log

If fsck is going then in my experience it will be able to repair the sparsebundle. Go away for a few hours and let it chug away.

When it is done, you will either see

‘The Volume was repaired successfully’

or

‘The Volume could not be repaired’

If the latter you can run disk repair again:


fsck_hfs -drfy /dev/diskxs2

Make sure to replace x with whatever number your disk is from the output above.

The letters “drfy” tell the filecheck utility different things. d for ‘Show Debug’ – r for ‘Rebuild Catalog Tree’ – f for ‘Force’ and y for assume ‘yes’ to any prompts.

Now go do something for an hour or two. Come back and


tail -f /var/log/fsck_hfs.log

If all went well, the last output you will see is

‘The Volume was repaired successfully’

Now you need to type

hdiutil detach /dev/diskxs2

You can redo the above for any other Time Machine sparse bundles you have permission to modify while you have the network share attached to your computer.

Final step.

When complete, you need to edit an plist file within the sparsebundle that records the state of the backup. On the top level of the sparsebundle find a file called com.apple.TimeMachine.MachineID.plist. Edit it and remove these two nodes


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

Finally you want to change


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

to

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

Now you can eject the network share and have Time Machine give it another go. After the (long) verification step, backups should proceed once again.

Notes:

Ideally this should be done over a gigabit wired network connection. Do not attempt using Wi-Fi. You also want to make sure your machine does not go to sleep during the above operation.

110 thoughts on “Fix Time Machine Sparsebundle NAS Based Backup Errors

  1. Hi, I’m having an issue to perform the first command and think that the issue is linked with the name of my sparse bundle file which is: (Volumes/BilSig_Server/BilSig’s iMac.sparsebundle)
    The error message I receive is the following:
    /Volumes/BilSig_Server/BilSigs iMac.sparsebundle
    hdiutil attach -nomount -noverify -noautofsck /Volumes/Volumes/BilSig_Server/BilSigs: No such file or directory

    I see that the <> is gone from the file name.
    Any idea to avoid this?
    Thx in advance for your answer

  2. @ Chris K,
    Thanks for the tip about using Console to view the fsck_hfs log file. That was a big help. I don’t know what a tail is, but I do know how to use the Console app:-)

    @ Garth,
    THANK YOU so much for publishing the detailed recipe, and providing the blogspace for us all to exchange comments. Your procedure fixed my TM problem (Snow Leopard 10.6.8, TM backing up to Netgear ReadyNAS with 2x2TB Raided drives). My TM sparesbundle is around 400 GB. The fsck repair ran overnight, so more than 4 hours but less than 10. Fsck reported “invalid free block count”. Was 137781235, should be 137783098. Problem repaired.

    After following your procedure, I turned TM back on and started a backup. The pre-backup verification step took about 20 minutes, then TM successfully backed up about a gig of files that had been accumulating since it first went off the rails.

    My tip: I used TextWrangler to edit the plist file, which I found by Showing Contents of the sparseimage file on the mounted NAS volume.

  3. Thank you for your help…. I am not sure to be successful here. Typing “fsck_hfs -drfy /dev/disk4s2″ I get
    “Unable to open block device /dev/disk4s2: Resource busyjournal_replay(/dev/disk4s2) returned 16
    ** /dev/rdisk4s2 (NO WRITE)
    Using cacheBlockSize=32K cacheTotalBlock=16384 cacheSize=524288K.(….) ** Checking extents overflow file.
    ** Checking catalog file.
    ** The volume Time Machine-Backups was found corrupt and needs to be repaired.”

    Does this mean that the repairing has started, or does the NOWRITE make this impossible.

    I tried to attach a “readwrite” but get a “attach failed”.

    Can someone please help me????
    Thank you!
    JENS

  4. [EDIT - This is included for some who may find this easier - I'm not sure I subscribe to the theory that the corruption occurs in the most recent backup - but if this works for some, all the better.]

    A simple way to repair TimeMachine Backups on a NAS Storage

    (in this case a Synology DiskStation 210 j, typically used via WLAN from 2 MacBook Pros, running the latest version of Snow Leopard)

    When it first happened to me, I tried to follow Garth’s recommendations, but somehow I seem to be too inadept with the terminal.
    I then tried around, using some of the facts that he explains in his blog.
    Since then, it has worked for me twice.

    Here’s how:

    First, inactivate TimeMachine or chose a different backup disk.

    Next, you have to make the “broken” backup accessible by:

    1. Mount the NAS share on which the disk image resides. (There probably is a „locked“ symbol at the bottom left corner oft the image’s icon)

    2. Control-click the icon and select „Show Package Contents“. There probably are 2 files with a „locked“ symbol inside the package: „com.apple.TimeMachine.MachineID.plist“ and „token“.

    3. Select each one of them; call up the info window by either clicking „command-I“ or by using the menu. The checkbox „locked“ will be selected. Deselect it and close the info window. When you are done with both files, close the package window.

    Next, you have to mount the disk image, which can take quite some time and which is best done using a LAN cable.

    4. Navigate through the folder levels until you find the folders, which are named after date and time of each individual backup.

    5. Assuming that something went wrong during the last backup, throw the complete contents oft the „Latest“ alias into the trashcan. This usually requires unlocking several of the contained folders using info window as described above. Empty the trash.

    6. Just to be on the safe side, I always removed the 2 most recent folders as well, but I don’t know whether this is really necessary.

    7. Write down date and time of the most recent folder you leave behind.

    8. Next, run Disk Utility to repair the image

    9. Eject the image

    Now, you have to modify the „com.apple.TimeMachine.MachineID.plist“ file that you unlocked in step 3 to reflect the new status of the backup:

    10. Open the package contents

    11. Open the file with the “Text Edit” application.

    12. In the line “yyyy-mm-ddThh:mm:ssZ” adjust date and time to the date and time of the most recent folder left in the sparse bundle disk image.

    13. The line “number” may read “2”. Change it to “1”.

    14. Close and save the file.

    15. Close the package window.

    16. Activate TimeMachine and select the repaired NAS share. Option-click on the TimeMachine icon in the menu bar and select “Verify Backups”. After this has finished, you should be back in business.

  5. Thank you – you saved my backup. This is the second time this has happened to me since I switched to wireless backups on a Synology NAS. The first time I accepted deleting the backup and starting again. I was not so willing to do that the second time.

    Now I’ve just got to find out what is causing this so I can stop it happening again. Some seem to think putting the Mac to sleep while a backup is in progress might be a cause.

  6. I’m getting the same error as Starkos, above: failed with error 7.
    http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-based-backup-errors.html/comment-page-2#comment-57027

    Here’s the full end of the log:

    ** Checking extended attributes file.
    hfs_swap_BTNode: invalid forward link (0xB0B3D200)
    /dev/rdisk2s2: hfs_swap_BTNode: invalid node kind (-75)
    /dev/rdisk2s2: hfs_swap_BTNode: invalid node height (179)
    /dev/rdisk2s2: hfs_swap_BTNode: invalid record count (0xD200)
    /dev/rdisk2s2: Invalid record count
    (8, 66372)
    /dev/rdisk2s2: ** The volume Time Machine Backups could not be verified completely.
    volume check failed with error 7
    /dev/rdisk2s2: volume type is pure HFS+
    /dev/rdisk2s2: primary MDB is at block 0 0×00
    /dev/rdisk2s2: alternate MDB is at block 0 0×00
    /dev/rdisk2s2: primary VHB is at block 2 0×02
    /dev/rdisk2s2: alternate VHB is at block 976767934 0x3a384bbe
    /dev/rdisk2s2: sector size = 512 0×200
    /dev/rdisk2s2: VolumeObject flags = 0×07
    /dev/rdisk2s2: total sectors for volume = 976767936 0x3a384bc0
    /dev/rdisk2s2: total sectors for embedded volume = 0 0×00

  7. @Billy

    EDIT – General note for everyone – if your machine name has an apostrophe s, or a space in the name, you will need to enclose the entire path in quotes – i.e. “/Volumes/BilSig_Server/BilSig’s iMac.sparsebundle”

    But in general – life is much easier on the command line if you go into the ‘Sharing’ panel of System Preferences and make your machine name something short with no spaces.

  8. @David Cher – Those are two different disks. You can sometimes get the ‘quickcheck only; filesystem clean’ message but you still want to run the fsck_hfs command to really start the repair process

  9. @Jason – you really should be doing this from the command line – there isn’t anything you can fix inside your Time Machine sparsebundle.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>