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
(Optionally if you have the available RAM, you can set a RAM cache in the command above to help speed up this command like so:
fsck_hfs -drfy -c 750 /dev/diskxs2
This will use 750MB of RAM – feel free to change this amount to best fit your system (amount of RAM vs size of your Time Machine Sparsebundle). If you are unsure about this, use the first command.
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.
[Update: 1.1.2013]
I appreciate all the warm feedback from people all over the world who have been helped by this post. This site helps to fund my hobbies, so if this post has helped you please consider a USD $1.99 donation to my hobby fund.
[Update: 12.23.2012]
If after running the initial
fsck_hfs -drfy /dev/diskxs2
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
And see if that works. It did for me today.
Hello Garth Gillespie,
I promise to domate if this starts working again!
I went through a lot to get to this point – only to get the ‘must make new backup.
Here’s what is happening. I beliwve theres a permissions error. I am not sure how to change the permissions.
localhost:~ root# chflags -R nouchg /Volumes/ReadyNAS/Macintosh.sparsebundle
localhost:~ root# hdiutil attach -nomount -noverify -noautofsck /Volumes/ReadyNAS/Macintosh.sparsebundle
/dev/disk2 Apple_partition_scheme
/dev/disk2s1 Apple_partition_map
/dev/disk2s2 Apple_HFSX
localhost:~ root# fsck_hfs -drfy -c 1000 /dev/disk2s2
Unable to open block device /dev/disk2s2: Permission deniedjournal_replay(/dev/disk2s2) returned 13
** /dev/rdisk2s2 (NO WRITE)
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
Executing fsck_hfs (version diskdev_cmds-557.3~1).
Journal is empty
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
The volume name is Time Machine Backups
** Checking extents overflow file.
** Checking catalog file.
** The volume Time Machine Backups was found corrupt and needs to be repaired.
volume type is pure HFS+
primary MDB is at block 0 0×00
alternate MDB is at block 0 0×00
primary VHB is at block 2 0×02
alternate VHB is at block 838860734 0x31ffffbe
sector size = 512 0×200
VolumeObject flags = 0×07
total sectors for volume = 838860736 0x31ffffc0
total sectors for embedded volume = 0 0×00
CheckHFS returned 7, fsmodified = 0
localhost:~ root#
any ideas?
@Peter Davies
I’m guessing that you are worldranger in the post on the apple discussions page?
Did I read your posts correctly that after your reinstall of OS X you are using a different username than you used when these backups were made?
This is probably the cause of the ‘permission denied’ error.
It is possible to change the permissions in the sparsebundle but in its current state, that is not advised.
I would try
1 – Disconnect the share (or just reboot)
2 – Create a new user with the same username you used prior to reinstall
3 – login as this new (old) user.
4 – try the repair steps again.
I also see you are trying to have OSX associate your existing backup with your reinstalled OS. I think part of the decision tree is the username.
A hint for all those who do not get past the first step:
The path to the sparsebundle has to be typed absolutely correct, i.e. in Terminal language. In my case the name of the sparsebundle is Baldur & Halla.sparsebundle In this case the path in Teminal language is:
/Volumes/Data/Baldur\ \&\ Halla.sparsebundle
The correct path to the sparsebundle can be extracted with the help of a utility app. In my case I used PathFinder (a Finder repalcement), which offeres the possibility to extract file paths in different programming languages.
Hi guys!
My volume (Synology 212) doesn’t want to repair:
sh-3.2# fsck_hfs -p -c 750 /dev/rdisk1s2
Executing fsck_hfs (version diskdev_cmds-557.3~3).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
The volume name is Time Machine Backups
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
Incorrect number of directory hard links
** Checking volume bitmap.
** Checking volume information.
Invalid volume file count
(It should be 1366023 instead of 1194640)
Invalid volume directory count
(It should be 203753 instead of 196891)
Invalid volume free block count
(It should be 171144763 instead of 178953736)
Volume header needs minor repair
(2, 0)
** Repairing volume.
Invalid first link in hard link chain (id = 754316)
(It should be 2160180 instead of 2153111)
Invalid first link in hard link chain (id = 755702)
(It should be 2160600 instead of 2153535)
Invalid first link in hard link chain (id = 755705)
...
(It should be 2163625 instead of 2149975)
Invalid first link in hard link chain (id = 764259)
(It should be 2163655 instead of 2150006)
Invalid first link in hard link chain (id = 764323)
(It should be 2163656 instead of 2150007)
Invalid first link in hard link chain (id = 764386)
(It should be 2163657 instead of 2150008)
Invalid first link in hard link chain (id = 764453)
(It should be 2163663 instead of 2150014)
Abort trap: 6
Do you have any ideas what can help me?
Appreciate any help.
@Roman – I would try running the command again – if it errors in the same place then your sparsebundle may be unrepairable.
Are these instructions applicable for a TimeMachine file on a TimeCapsule?
I find myself coming back again and again to refresh my memory on how to do all this. It seems to happen frequently enough to annoy (which is to say more than once) but not so much I can remember the steps.
I have been working around this by backing up to two different volumes to ensure corruption or whatever the &^&(* keeps happening doesn’t cost me all my data (I have been using Time Machine since the 1st Generation Time Capsules came out but my oldest backup is from December 2012, such has been my struggle).
But that poses its own problems if you want to see what backups are stored with
tmutil listbackups, for example. The volume name is always Time Machine Backups, no matter where it lives. So I used the steps here to give them unique names, based on the volume where they are kept. You still only get a list of backups from one of the repositories, if you use more than one, but at least between that andtmutil destinationinfoyou can check up on the process.Anyone want to translate this howto for ubuntu? So far every command is different and resulting in hours of research. If anyone out there knows the command equivalents off hand, I would be eternally grateful.
Thanks for this.. it just saved my bacon.. again.
This kind of thing could probably be automated fairly easily in an app. It would allow a lot more people to be helped as it’s so common for this to happen (used to happen to us about once a month even on genuine apple TCs).