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."
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.
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
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.
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.
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.
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.
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:
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:
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. 🙂
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.
I was working this in the Apple forums and just realized that I had not updated this thread with all of my experimentation and results. The bottom line: my backups were failing during my weekly ReadyNAS resync. Something about the interaction between v10.6 and later Mac OS X's AFP and NAS writing corrupted the bundle during the ReadyNAS resync op. I installed a third party tool on my Mac that avoids running TM during the resync window and my problem went away.
Since I've upgraded to Mountain Lion I've seen many more TM corruption issues from my Air than before (possible PowerNap cause?)
Anyway, I dug around on the net and managed to fix the sparsebundle with a few mounts/file system checks. I wrote a post about it in case I needed to do it again.
If you are using a Mac Air also check that you are not having issues with the SSD. I have had repeated issues with the SSD developing orphaned blocks. Restart into recovery and run Disk Utility. I have a feeling that when this starts to happen TimeMachine tries to verify the backup and finds these errors and assumes it is a corruption of the backup when in fact the backup is true, it is the source that has the issue. Only a hunch and I am not sure how to confirm this.
I was able to rename the .sparsebundle file (I chose .xx) but I could never delete it. After the rename, I restarted Time Machine on the Mac and, miraculously, a new uncorrupted .sparsebundle file was created on the NAS. The trick will be to get rid of the .xx file, it's still stubborn, but at least now I have TM functionality back online. Open to suggestions on alternative techniques to delete these files - the SSH software would not run on my iMac with Mountain Lion.
I just found this fix on the Internet last night, but I haven't tried it yet. Others report that it has worked. If anyone attempts the fix, please post the results here.
I have just converted from PC to Mac and I think I have run into this problem.
I setup time machine and all was well until my Mac went to sleep in the middle of a back up. Since then my Mac mini will not connect to my Nas for back up. I have tried resetting everything and still will not connect. Unfortunately I'm not good with command line.
Could somebody please tell me in lay terms what has gone wrong and if the issue on this tread might be what I'm experiancing?
