Time machine keeps creating a new backup

ahh I see,well if thats the case I'll delete them and start new ones, which is what I thought it was doing with this error anyway, can I just delete the image by mounting the Readynas?
I have down the repair again and it's working again, but for how long..

Quickest to delete from the SSH shell - finder is very slow when it comes to deleting large sparsebundles (lots of small files which finder doesn't handle well)

I am having the same issue with Time Machine wanting to create new backups after a verification. I have no problem allowing it to create a new backup--I am loosing historical data yes, versioning yes, but I am OK with that as most of what I want backed up is the current state of files.

I want to know if anyone has figures out the root cause. This appeared to be happening after both an update to the ReadyNAS software and the installation of OSX 10.7.3. My wife's Mac Air is still on snow leopard and has never seen this error. As an added note, she is solely on Wifi. I had once read that it had something to do with Wifi and my iMac is physically connected to my gigabit network and to WiFi.

Anyway, has anyone heard of the cause. I would like to fix it and avoid the recreation of the backup every 8 or 9 days.

Having the same problem. I'm hardly able to complete a new time machine backup (800GB) before the error pops up again. I've manually deleted the old snow leopard sparsebundle and created a new one from Lion, so it's not an issue of compatibility between SL and Lion.

Help Please.

I'm in the same boat. Deleted old bundle files via SSH after I kept getting requests for new backup. This has made no difference and I'm basically not using TM now cause I'm getting no more than a week before new backup request.

Have you opened tech support cases?

Also have you tried 4.2.20 beta to see if this makes any difference?: http://www.readynas.com/forum/viewtopic.php?f=51&t=57193

4.2.20 beta looks like it's probably nearly a production release so even if not willing to try the beta do keep an eye out for it and try it once it comes out of beta.

I must admit I haven't opened a support ticket but I will do so shortly. Thanks for heads up on beta, if it's near completion I may hold off I don't know enough about Linux to get myself out of trouble if beta caused me issues. Cheers...

I can confirm that this happens with Snow Leopard 10.6.8 too, ever since I updated to RAIDiator Sparc (for ReadyNAS Duo/NV+) 4.1.8.

As the system worked flawlessly before that update I have now restored Firmware Version 4.1.7 - may be not the option one usually wants to go for, but I hope it solves the problem.

And of course, I hope that Netgear takes these reports seriousely and comes up with a solution.

I too had this happening. After following the instructions to fix this, the problem re-occurred only few days later.
I then recalled that I did have something similar in the past. As far as I can tell, it then it was due to the sparsebundle advertising some room left, whereas the timemachine share was already completely filled up. This confused TImeMachine, as it thought it had sufficient room to create a new backup in the sparsebundle, but then halfway got a write error. Note that I don't have hard evidence of this; I couldn't find specific log messages that point to this.

So after the 2nd occurence of this, after fixing the image again, I resized the sparsebundle using "hdiutil resize" to the smallest size possible. That shaved off a few GB. I was afraid that TM would just increase the size again at first backup (there was lot of discussion on this "feature" when it first occured somewhere in 10.6.8 or so), but fortunately the size sticked:

14/4/12 1:45:17.307 PM com.apple.backupd: Resizing backup disk image from 441.0 GB to 449.9 GB
14/4/12 1:45:17.333 PM com.apple.backupd: Could not resize backup disk image (DIHLResizeImage returned 35)

So you can see TM is trying to resize the sparsebundle again (the actual TM share is 450 GB), but fails for some reason (it does this resize attempt each and every backup).
The first backup after the resize TM then had to remove some old backups (as it didn't have any room left for the new backup), but after that TM has been backing up hapily again for about 2 weeks now.

So maybe something has changed in the way actual share size is reported/handled in one of the RAIDiator updates (I'm on a NV+, 4.1.8 ), resulting in timemachine sparsebundles created on an older version now to be slightly too large (as TM has grown them to fit just within the share's size). I didn't check, but I guess that TM only tries to grow the sparsebundle when it detects the size is smaller than the share size, but doesn't do the reverse (shrinking when it detects the sparsebundle size is larger than the share size).

Paul