I am using Time Machine on Mavericks, so this may not be relevant. However, both solutions worked so well, I thought I might share. There are tricks to make Time Machine work that may be applicable (NB This is only for Time Machine on NAS drives). If you get stuck forever at Preparing Backup, then mount the Time Machine so you get all the way to the .dmg. Mount that. If you see an xxx.inprocess, that is what is killing you. Use sudo rm -rf to nuke that thing. Sometimes it complains when you try that. You can also drag that .inprocess to the trash and empty. Both these operations will take a while. Note, one side effect is that Time Machine will never give the correct amount of space left on the drive again. Oh well.
One way to avoid Time Machine issues, is to try to avoid a situation where you start a backup, and then move the computer some place where it does not have wireless or ethernet access. You may want to turn Time Machine OFF when you are away from your network. Make sure that any backup is COMPLETED before you disconnect it. Or tell it to STOP the backup before you move. TM is supposed to know how to deal with this stuff, but I find it doesn't. Causing TM to start and stop leads to misery. The inprocess stuff sometimes fixes itself. Other times you have to force it.
Now, what about a nice big Time Machine (say, a 3 TB capsule) disk that has data that you still want to use but Time Machine has locked it, saying it is corrupt, and wants to erase it and make all new backups. Before you nuke it, or just put it away somewhere as an archive, note that, contrary to the myths, you can fsck a Time Machine volume. The instructions are here:
http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-b ased-backup-errors.html
For everyone's convenience, I have copied the contents of that website below. This worked PERFECTLY for me.
27.Aug.11
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
NOTA BENE FROM MUNGOBOMB, I had to fsck manually SEVERAL TIMES.
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.
PLEASE PLEASE FUND THIS GUY. HE IS A LIFESAVER:
https://www.paypal.com/us/cgi-bin/webscr?cmd=_flow&SESSION=Ntxgb3gK8mBcMxzUXsKrC nUys3ex7h94Sbjp09qgodfLMpWjsmQ-OFIXY6e&dispatch=5885d80a13c0db1f8e263663d3faee8d 66f31424b43e9a70645c907a6cbd8fb4