TimeMachine sparsebundle corruption fix

[glashoppah]

Dear Colleagues,

Ever since upgrading my Mac to Lion I have had a curious problem which I've been working (for months) with Apple. Basically once every week or two, always on a Monday morning, the TM process would report that it could no longer read the backup due to corruption and would need to create a new one. This is the infamous "TimeMachine completed a verification" error. It would then delete the old backup set and start over.

This really drove me nuts. Clearly a change in Lion had caused this to begin, but I couldn't figure out why it was so predictably periodic. I never had a problem with TM under Snow Leopard, which ran for me just fine for well over a year.

Anyway, a few weeks ago when I was scratching my head for the 100th time on this problem I noted that the ReadyNAS was running its weekly RAID scrub during the time period in which TM was failing. Basically I kick off the RAID scrub at 04:00 AM and it usually runs until about 10:00 AM or so. The TM process would fail at between 08:00 and 09:00 AM during this scrub.

Clearly - to me - Lion is failing to verify its writes as assiduously as Leopard did, and the interaction between the very busy READYNAS and TM with Lion's filesystem was causing this corruption. I was now confronted with a new problem - TM's schedule is not configurable. It backs up every few minutes. So there was no way for me to "window" it to have it avoid the RAID scrubbing time.

Then a few Web searches later I found "TimeMachineEditor". This freeware utility lets you create complex schedules for TM. Perfect! I was able to not only have TM *not* back up during the RAID scrub, I was also able to set TM to back up once an hour rather than every few minutes, which is a lot more usable for me. This has fixed the problem.

So if you're having weird problems with TM backups getting corrupted and you can see that it's happening during your RAID scrub, try "TimeMachineEditor."

Sincerely,

H.

[boz0]

If this is actually the root cause, it is a remarkable find. I'll setup Time Machine Editor and re-activate TM to see whether it fixes the problem for me as well.

Thanks for sharing this, at any rate.

[sphardy]

While this may contribute to the issue, it is certainly not the root cause. I have seen this occur regularly on a NAS that is not configured for RAID scrubbing

[glashoppah]

I've done a lot of experimenting with this and I'm certain something was changed in Lion's filesystem code that caused the problem. I never had this problem with Leopard or Snow Leopard. Lion appears to not be doing enough to ensure its writes are uncorrupted. But Apple is ignoring the problem, so for me, this fix - which is a workaround - was valid.

H.

[sphardy]

I agree the issue appears more prevalent under Lion, and it is well known Apple made changes to AFP support for TM in Lion - but the issue is not limited to that OS. I have 2 machines running SL; both began to exhibit the problem since the new version of AFP was included within the latest NAS firmwares.

The only time I have NOT encountered the issue is when using TM with a direct attached disk.

[mdgm]

Hopefully Apple fixes this in 10.7.4 or in Mountain Lion. From what I've read it appears the problem also exists when backing up to a Time Capsule.

[sphardy]

Hopefully Apple fixes this in 10.7.4 or in Mountain Lion.

I think they'll have to. ML adds the ability to backup to multiple destinations simultaneously and I can see the majority of those secondary destinations being network attached, even if just backing up to a drive directly attached to another Mac on the network.

From what I've read it appears the problem also exists when backing up to a Time Capsule.

Yup - had that issue too

[mdgm]

I think they'll have to. ML adds the ability to backup to multiple destinations simultaneously and I can see the majority of those secondary destinations being network attached, even if just backing up to a drive directly attached to another Mac on the network.

Yes. Will be interesting to read how that works. I could backup to multiple ReadyNAS units at once which would be nice and maybe even to a ReadyNAS unit a remote location when I'm there. It's a welcome addition to the Time Machine feature set.

From what I've read it appears the problem also exists when backing up to a Time Capsule.

Yup - had that issue too

[/quote]
I don't currently have a Time Capsule and don't see the value in it for me as it has a single non-user replaceable drive and still has the issue.

[boz0]

Yes. Will be interesting to read how that works. I could backup to multiple ReadyNAS units at once which would be nice and maybe even to a ReadyNAS unit a remote location when I'm there. It's a welcome addition to the Time Machine feature set.

I'd settle for a Time Machine that works as well as it used to while running 10.5/10.6 ...

[glashoppah]

Yes. Will be interesting to read how that works. I could backup to multiple ReadyNAS units at once which would be nice and maybe even to a ReadyNAS unit a remote location when I'm there. It's a welcome addition to the Time Machine feature set.

I'd settle for a Time Machine that works as well as it used to while running 10.5/10.6 ...

Bingo.

H.

[mdgm]

Well it seems TM backups to network shares aren't that high a priority to Apple as it should be as there are still major issues with it on Mountain Lion DP3: http://www.macrumors.com/2012/04/18/apple-releases-os-x-mountain-lion-developer-preview-3/

[schalliol]

About a month later, any idea about whether a solution is in sight for Mountain Lion? Thanks!

[dmwarren]

Hello! (first post here after my first year with my immensely satisfying Ultra 6...)

I'm running Mountain Lion DP4 and ran into the same problem with Time Machine. I absolutely refused to believe that netatalk was somehow incapable of talking to Mountain Lion, so I dug a little deeper.

Long story short, I think I can point to mDNS/Bonjour discovery as the problem. backupd seems to insist on using Bonjour to find, then mount the TM volume.

Once I mounted the Time Machine volume manually and specified the manually-mounted AFP share as a backup disk, voilà: Time Machine works again! I didn't even need to start a fresh backup; it just picked up as though nothing had ever happened. There's no need to keep the Time Machine share mounted—backupd will mount it just fine on its own now. Of course, Netgear's patches to netatalk prevent you from mounting /c/.timemachine directory, so you'll have to specify it yourself in your AppleVolumes.default file.

I'm not going to post a step-by-step tutorial on how to do this because ... if you don't already know how to administer netatalk, you should cut your teeth somewhere else and not void your warranty by editing random unfamiliar config files.

I can't say it often enough: I love this unit because it's Just A Unix Box(tm) and I didn't have to build it. When I need to get under the hood, I can. Thanks, Netgear.

(Edit: added my theory about what's failing)

[schalliol]

It just works for me on DP3 (12A206j), nothing special needed.

[ITAVA]

Sorry guys, but I have sparsebundle corruption and do not see a fix in this thread.
I have been trying to delete the for many hours now, with no luck.

This MAC has OSX 10.6.8 on it still. The computer had a raid controller failure previously and was never able to reattach to the backup drive after the restore. The Time machine fails saying it cannot connect. I dont knwo what to do to get this to work. From the research I have done, deleting should bel all that needs to be done. It says it is a file size of zero but deletes take forever and never completes. Anyone have a clue how to resolve this? If this is wrong thread, please correct me.