NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
boomish
Oct 21, 2011Aspirant
Time machine keeps creating a new backup
My TM keeps saying it can't verify backup and needs to create a new one, not sure on the gap in between a new one being finished and the next but it's not long and it takes 2 days to create it so effe...
lieverse
Apr 14, 2012Aspirant
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:
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
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
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!