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.
Wsna
If you boot from the Leopard, Snow Leopard or Lion boot CD (or Lion Recovery Partition), it will ask you to restore from Time Machine.
Hi, Garth.
Thank you for great informations.
My sparse bundle disk is almost 900GB.
How long does it take first command (chflags -R nouchg /Volumes/{name of your network share}/{name of}.sparsebundle) ?
how can I know the percentage of progress?
Nori.
Solved the corruption on my FreeNAS-hosted time machine backup perfectly . . . thanks very much for the detailed instructions !
Method described in this post did work with my QNAP TS-119 NAS (firmware 3.5.2 Build 1126T). I had “NO WRITE” from fsck_hfs command so I added -readwrite option to ‘hdiutil attach’ command.
Thanks!
Nori – there is no percentage indicator – just wait until it finishes. you can open a new terminal window and use ‘top’ to make sure te chflags is still running
got it working…
Thanks, your instruction to fix the DIRTY volume saved me lot of pain
Hello! Great help! But I can’t find com.apple.TimeMachine.MachineID.plist… I checked in the sparse bundle and in the preference folder of lion…
Any idea?
Forget my question… I was looking for in the Mounted SparseBundle, but if I go in the folder with command line I can see it…
Hmm…mine doesn’t repair, instead I get left with “The volume Time Machine Backups couple not be verified completely. Volume check failed with error 7″. Drive failing, perhaps?
Garth
Worked like a charm, thanks a lot!
Alan.
I used the Furrybeard technique posted, using Disk Utility to repair the disk. Worked perfectly.
Jim – the repair may be possible via Disk Utility – it is just a front-end to fsck_hfs – but I have had timeout issues in the past with the GUI and have better results running the repair from the command line.
Hey Garth
I mean this is an incredible description! I was looking for weeks for something like that.. it just works really nice! Thanks a lot!
I’m still trying to understand why it keeps happening after a couple of weeks.. I have 5 Macs, all TM’ing on the same NAS (Synology 509+) and only my big iMac does it… could it be because I put it to sleep by hand without checking before if TM is running ?
thanks again!
G
I’ve a USB disk connected to a Synology NAS. Timemachine is making backups there, but every now and then it starts whining about how it couldn’t access the volume.
I tried this method, but the first time I perform:
“tail -f /var/log/fsck_hfs.log” it gets stuck (I forgot what it said, but it just didn’t do anything, nor did it finish after an entire night).
So I quit the process and did the:
“fsck_hfs -drfy /dev/diskxs2″
It started logging, but now it seems stuck at:
hfs_UNswap_BTNode: invalid node height (1)
I googled it, and it’s very associated with kernel panics and hard drive failure. The hard drive is brand new and it worked for a few weeks. I can still access it over AFP, and it just seems to work fine.
Is this fixable? I really hope you can help. Thanks
So I stopped the process
I restarted the process and it seems to work now!
Thanks for this amazing piece of information!
Thanks for this!
Works perfectly.
But still the problem comes up after a few days again.
It’s a bit annoying to do all of this again and again all the time.
Does anyone know the reason why this happens?
Is there no way to solve this once and for ever?
oraguru – if you are putting the machine to sleep without checking TM – that could be your issue.
My computer is named ‘User Name’s MacBook Pro’. My spare bundle is named ‘User Name’s MacBook Pro.sparsebundle’ in Finder but shows up as ‘User Name???s MacBook Pro.sparsebundle’ in Terminal when I do ls -l.
Both of these come back with ‘No such file or directory’ as an error message. Does anyone know how to properly type those file names in the command line? I am using quotes around the full path.
Dan – I think your apostrophe is really a smart quote, and a weird smart quote at that, so that is why it is showing up as question marks – the filesystem does not know how to read the quote.
There are a couple things to try. The first is in your Terminal preferences, go to the bottom of the Advanced tab in Settings and make sure your character encoding is set to UTF-8 (you’ll need to restart Terminal to see changes) – if it is set to UTF-8, try some other character sets.
The other option is to rename both your machine (in System Preferences->Sharing) and also rename the sparsebundle (via Finder) to the same thing.
Hello Garth,
Your article allowed me to save my Snow Leopard back-up, which I thought utterly beyond recovery!
Thanks a lot!
Alain
Garth,
Thanks for the write up. Certainly a mega time and headache saver!
-Jason
Last fall I had Time Machine trash my Macbook backups and either I flubbed something or things got into such a bad state that fsck_hfs tried once to repair the image and then subsequently would almost immediately give up and tell me that the volume could not be repaired. I ended up trashing the .sparsebundle and starting TM from scratch again.
I just had to do this again, this time for my iMac, on a .sparsebundle containing over 940 MB on my Time Capsule.
Two notes:
1. you only have to remove the “uchg” flag from the .sparsebundle directory itself, and the file “token” within it. That saves a good deal of time!
2. the fsck_hfs process ran even though I gave hdiutil the “-noautofsck” option — but that was OK for me this time because (a) I noticed it running before I tried to run it manually (though the manual run will fail gracefully and tell you that the volume is busy); and (b) it actually did the repair!
The fsck_hfs process ran for almost 24 hours. That’s with the target being a Time Capsule, connected by gigabit ethernet.
When I started Time Machine again the verify (another fsck_hfs run by TM) took almost 9 hours. I wonder if there’s a simple way to set the .plist file to indicate that all is well and no new verify is needed.
make that 940 GigaBytes
Garth,
I am receiving the following message on my TM: Something wrong with the volume’s CNID DB, using temporary CNID DB instead .Check server messages for details. Switching to read-only.
My TM is connected to a Buffalo Linkstation 2 terabyte NAS which is connected to an Airport Extreme (for 6 months now w/o problems). I realise now that’s probably not a good connection through wireless, but had no problems before now.
The sparsebundle is located on the backup folder of the NAS.
I have no clue how to repair the sparsebundle and am not very good at ‘programming’. Should I follow exactly what you have written or should I just delete the offedning sparsebundle in question? I would really appreciate your input
Tks
Patrick
Patrick,
The CNID DB is part of the AFP network protocol and is a small database file on your Linkstation share that tracks metadata about the AFP share to your Macs.
CNID DB corruption is not necessarily fatal, but I’m not sure how many tools you have available to fix it on the Linkstation.
If your Linkstation is still under warranty, I would try contacting their support area and see if they can help.
You might also check for a firmware update for your Linkstation.
If you get to the point where you think you just need to re-format your Linkstation drive, the last ditch step to regenerate the CNID DB is to delete all the .AppleDouble and .AppleDB directories.
Worked great!
The fsck end msg changed a bit, but everything works fine now,
Hi, just wanted to say thanks for fixing my backup!
Also, the other Dan that has the Name???s MacBook Pro problem, I too had the issue but if you type the first letter of the spares bundle’s name it will correctly autocomplete it for you (Usually it is “Example\342\200\231s\ Mac\ Pro.sparsebundle/” without the ” “).
Hi, just wanted to say thanks for fixing my backup!
Also, the other Dan that has the Name???s MacBook Pro problem, I too had the issue but if you type the first letter of the spares bundle’s name and then press TAB it will correctly autocomplete it for you (Usually it is “Example\342\200\231s\ Mac\ Pro.sparsebundle/” without the ” “).
Worked for me. The only difficulty I had was that the plist file would not show up in Finder even with hidden files shown. So, I could not use my plist editor. It did show up with ls in the termini. I had to use the VI editor in the Terminal. Since I hardly ever use the VI editor, it took a few minutes to make the simple edits. Time Machine required some time to verify the back up, but all is well.
Worked perfectly. Thank you very much for the instructions, much appreciated.