Fix Time Machine Sparsebundle NAS Based Backup Errors

time-machine-iconAs a avid Mac user. I utilize the built-in functionality of Time Machine along with my Synology DiskStation to maintain my backups. But occasionally you come across the worst feeling ever when Time Machine advises  you that you need to start a new back up  and prompts you with the following error:

Time Machine Start New Backup

The first time it happened, I complied and performed the new backup. But after it showing up a second time I delved into the Google searches to find an answer. That is when I stumbled upon Garth Gillespie‘s article Fix Time Machine Sparsebundle NAS Based Backup Errors. I wanted to add it to my site just as a reference for myself mostly, just in case something happened to his post.

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. Once complete 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’

If after running the initial command you get a message in the fsck_hfs.log along the lines of

RebuildBTree – record x in node y is not recoverable.

then try

fsck_hfs -p /dev/diskxs2

followed by

fsck_hfs -drfy /dev/diskxs2

Now you need to type:

hdiutil detach /dev/diskxs2

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.