NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
glashoppah
Apr 10, 2012Aspirant
TimeMachine sparsebundle corruption fix
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.
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.
21 Replies
Replies have been turned off for this discussion
- boz0AspirantIf 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. - sphardy1ApprenticeWhile 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
- glashoppahAspirantI'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. - sphardy1ApprenticeI 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-ntgrNETGEAR Employee RetiredHopefully 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.
- sphardy1Apprentice
mdgm wrote: 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-ntgrNETGEAR Employee Retired
sphardy wrote:
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.sphardy wrote: 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. - boz0Aspirant
mdgm wrote: 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 ... :cry: - glashoppahAspirant
boz0 wrote: mdgm wrote: 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 ... :cry:
Bingo.
H. - mdgm-ntgrNETGEAR Employee RetiredWell 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/
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!