Over the past 14 years I’ve accumulated a ridiculous number of digital photos and files, the disappearance or corruption of which would likely be a serious blow to my mental health. Since switching to a Mac I’ve felt secure in the knowledge that Time Machine is watching my back, all I have to do is remember to plug in my trusty Drobo and let OS-X do its stuff. But then the Drobo started behaving erratically, often not backup up more than a few kb over a weekend.
So I bought a NAS, a reputable one which claimed Time Machine compatibility, and filled it with four lovely 3TB disks. Backups were much faster than the Drobo and have been more reliable too, until recently. It now seems I can’t go for more than a fortnight without seeing this dreaded message:
What’s happened here is that some kind of discrepancy has arisen between the data that’s been backed up and the data that’s on my machine, leaving me with two choices: don’t back up any more, or start a new backup and lose all backup history up to this point. Now I don’t really care about backup history. The main reason I do this is so that I have a complete, up to date copy of all my stuff in the event that my laptop gets stolen or my Thunderbolt disk catches fire – historical version data is a nice-to-have but by no means essential. So why is starting again with a fresh backup such a big deal? Because even over gigabit ethernet it takes around two days to do one, ask me how I know.
There’s an ongoing debate over the cause of this problem. Some way that it’s a recent update to OS-X that’s to blame, others maintain that such data discrepancies are par for the course when you’re pushing terabytes of data around a network, citing this as a potential reason for Apple’s reluctance to allow NAS to be valid Time Machine targets in the first place. Whatever the cause, Garth Gillespie has found a solution and I’m extremely grateful to him. It goes a little something like this:
- Unlock all files in your Time Machine sparsebundle by changing some flags
- Mount the sparsebundle as a volume
- Run fsck to check for (and fix) filesystem errors
- Unmount the volume
- Edit the plist within the sparsebundle that stores the backup state
Once you’ve completed the above steps you should be able to run a Time Machine backup as before, though if you want to set your mind at ease you can always verify the backup first by clicking the Time Machine icon in your menu bar while holding ALT.
One thing worth noting is the amount of time it takes to rattle through the steps on Garth’s blog. I would have expected these to take much longer than they did, given the length of time it takes to do a full backup. Yet the changing of flags in step #1 was by far the longest part of the process at around 35 minutes.