After working quite happily for months, Time Machine running with a NAS as a backup destination has suddenly decided that my backup is "corrupt" after failing a check for "runtime corruption" and is insisting that I must delete the entire (4 terabyte) backup and start again!
What I want to know is how Time Machine determines "runtime corruption", and can I in some way reset or disable this check?
I have already checked the disk image itself using the following commands:
hdiutil attach -nomount /Volumes/Path/To/Backup.sparsebundle diskutil verifyDisk diskN diskutil verifyVolume diskNs2
Substituting paths and disk numbers where appropriate, and have found no errors whatsoever. So what exactly is Time Machine checking?
I've also checked almost all of the most recent backup (using
shasum, ignoring files with newer modified times) and everything is fine; I can't find any evidence that anything is corrupted in any way, certainly not any of the files I care about most.
It's laughable really, as the only processes to touch the bundle are Time Machine and related components, there has been no sign of any kind of network connectivity issue, no other errors in the logs, and every other backup for the same day was completed without issue. Which means that any "runtime corruption" is most likely the fault of Time Machine itself!
It's also even more ridiculous that the only option presented is to wipe everything, rather than perform a deep traversal to compare the contents in detail (to find anything that may indeed be corrupted and replace it, not that I believe there is any corruption at all).
I don't want to have to discard 4 terabytes of backups for some vague, unspecified "corruption" that doesn't even appear to exist, so is there some way I can remove whatever data Time Machine is using to detect its mythical "runtime corruption" (a check it doesn't even appear to do with direct attached drives) so that I can just continue backing up?
So I've gained some new information, which is that the Time Machine "runtime corruption" check is actually just running
fsck_hfs -q, which has nothing to do with corruption whatsoever, it is merely a test of whether a disk image was unmounted "uncleanly", which is no guarantee of corruption (as I have already confirmed).
Unfortunately despite managing to clear the "inconsistent" bit (which indicates an unclean unmount) using
fsck_hfs -p time machine is still refusing to use this backup, despite the runtime corruption check no longer failing. Meaning some other data must be stored somewhere.