Time Machine Frequent "Start New Backup"

Okay my Time Machine is now asking me to re do the whole backup. The actual date it started was 11th July.

My last post on this forum saying that I had no problems after upgrading to Lion was July 3rd.

And yes, here we go again ! I am good again for yet another backup. The weird thing is that it is every time my iMac, connected over Gigabit network. The MacBook Air (over Wif) works fine for almost a year now, and has never had this issue. THis is very annoying. I really hope Apple wil fix this ! 😠

I'm having exactly the same problem - I'm using LION Sever as the Time Machine target with a 2011 MBP - and it happens whether the MBP uses WiFi or Gigabit Ethernet - useless!

I switched from Windows and WHS because of my experience with ios devices - WHS was simple and reliable for everything I needed from it, including backup - regretting my decision.

Just started having this problem after about 6 months of flawless backing up to a DS212j running DSM 4.0, from a host MBP Late 2008 running 10.7.4, going over wireline ethernet.

Over 10 days it has asked me to create a new backup three times.

Strange.

Hi all,

Thanks for all the good information on what is seeming to be a rather frustrating issue.

I have come to this forum just today and I apologize if I'm simply regurgitating old news, but I came across something yesterday on someone's very well done blog, MacSynology, hat might shed a wee bit of light on this topic. A respondent to the blog author's write up on the virtues of Rsync as a hedge against Time Machine failures "Rsync when Time Machine Fails" pointed out that it has been determined this error (or something like it) is the result of a bug in Netatalk, which has been resolved in the latest release, i.e. v2.2.3. The respondent posted the relevant verbiage from the release notes along with the link; both of which I've included below:

“UPD: afpd: Changed behaviour for TimeMachine volumes in case there’s a problem talking to the CNID daemons. Previously the volume was flagged read-only and an AFP message was sent to the client. As this might result in TimeMachine assuming the backup sparse bundle is damaged, we now just switch the CNID database to an in-memory tdb without the additional stuff.”

http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2.3.html

The respondent, Simon, went on to say that he contacted Synology about the problem and they promised to look into it. He followed up a few weeks later reporting that Synology has in fact included Netatalk v2.2.3 in the DSM 4.1 beta.

So, hopefully this is not a red herring and as NAS vendors begin to incorporate this Netatalk update into their maintenance updates, this Time Machine verification issue might begin to subside. Of course I'm not counting on it, but I am cautiously optimistic at least.

Hey LitterMines,

your post is very interesting.

there are several repair instructions like the one on garth.org, it requires in its last step to tell TimeMachine that the Backup is ok (by editing com.apple.TimeMachine.MachineID.plist).

So if the original problem is based on that afpd/cnid thing, and the sparsebundle isn't corrupt, would it maybe sufficient to change the com.apple.TimeMachine.MachineID.plist ?

MacPear:

Ha! I would be doing this thread a great disservice if I were to even TRY to answer that. lol In other words I really have no idea. Although I am of the fairly technical and computer savvy ilk, I've worked primarily with Windows since the '95 days, and my prowess in the Linux and Mac OS X realm is closer to "your granny on AOL" level in comparison. I just made the jump to the Dark Side a little over a year ago, and although I dearly love my Mac OS and iOS devices, I'm finding that in my old age, I'm not all that motivated to get too close to what's going on under the hood. All that I know about plists are that from time to time I come upon some set of how-to instructions that I carefully follow and which involve editing a plist file. 😕

OTOH, there appears to be some pretty knowledgeable Apple tech gurus on this thread someone might come along with a reply to your speculative thoughts.

At any rate, I am hoping that this Netatalk update makes this problem just go away, because I'm not sure if I want to use my new Synology DS412+ for TM (instead of my FW800 EHD) as planned if I'm going to have to deal with this issue all the time. 😟

Hi folks,

I too am having this issue. First, let me give my configuration in case it is helpful to others.

I use a Synology DS209 NAS for my Time Machine backups. All machines (2008 Mac Pro, 2011 Mac Mini, 2006 Mac Book) were all running Lion when problem first noticed. Mac Pro now running Mountain Lion and problem occured within a week of last occurance (previous one was on Lion, latest was on Mountain Lion)

All machines connected via Ethernet (i.e. no backup done via wireless).

I did see the mention of the update to the Synology OS so I downloaded and installed it. I will let you know if I see any more issues.

Regards,

John

Sadly, just started a fresh backup to my Time Capsule, after just a couple of months..

I was thinking, could a periodic "archive" of the sparsebundle to an external drive (or maybe even the same one) help to recover from such failures?

And is there any way to check whether it's a hardware problem, besides noting that s.m.a.r.t. is "verified"?

Thanks

cicuz wrote:

Sadly, just started a fresh backup to my Time Capsule, after just a couple of months..

I was thinking, could a periodic "archive" of the sparsebundle to an external drive (or maybe even the same one) help to recover from such failures?

Yes, archiving to an external will preserve the sparse bundle, and you can always view and restore from those backups, via the Browse... option, per #E2 in Time Machine - Troubleshooting.

That's assuming you do the copy before there's damage; if not, you can still probably restore individual items, and perhaps an entire backup, unless you encounter the damage.

And is there any way to check whether it's a hardware problem, besides noting that s.m.a.r.t. is "verified"?

You can do a "Zero Out Disk" while erasing it. That won't necessarily catch all problems, but if it fails, you know the disk is failing. See the green box in #Q5 of Using Time Machine with a Time Capsule.

But the problem causing the backups to fail verification isn't necessarily hardware; it can be power or network -- bad connection, interference, etc. See #C13 in Time Machine - Troubleshooting.

I had similar issues with my Synology NAS as well hence I moved my backups to be done to a Mac OS X server based on a Mac Mini with an attached disk.

Unfortunately I have to report that this also fails with the same error message. Today my backup from my Macbook Pro over wireless to my Mac Mini OS X Server failed with the same error message.

I have to say it happened more often with the Synology than with the Mac OS X Server but it shows that it's more a Time Machine problem than anything else.

To my knowledge my setup is a fully supported solution and it still doesn't work.

I guess that rules out the Netatalk v2.3 (or whatever) update in DSM 4.1 will fix it gambit. Bummer.

Well it probably provides some improvement, as I said it happened more often on the Syno than the Mac Mini.

I have also found that on the Synology using the trick of a "timemachine" user with limited quota makes it worse than just using the Synology administrator account instead. Yes you lose the control over backup size restriction as admin can use the whole Syno box but it fails less often.

The reason for above is that the issue we see is actually not happening at the point we see when it says the backup needs to be started new. The problem happenes on the backup just before that when Time Machine tries to delete older backups and fails which causes it to schedule a fsck on the next backup that then fails with the error message we see.

BTW this is also the reason why not all backups fail or people see this in regular interval as it's only happens when Time Machine tries to delete older backups. Hence using the admin account with full access to DS and more space somewhat mitigates the problem.

I have reported this to the Synology support engineers and they are looking into it.

I'm been using Synology with the new 4.1 DSM beta since release and still having the issues about once a month.

I have a quota on the timemachine user but not nearly using all of it before it fails, so I think it is failing before it needs to delete any old backups.

In reading the whole thread, this is clearly not just a Synology thing.

Ah, be careful here because having more than enough space does not mean Time Machine is not deleting any backups. The way it works is that the hourly backups it doesn't need eventualy get consolidated to weekly and monthly backups. When it does this it deletes the backups in between it doesn't need. So you say that happens monthly for you could be when Time Machine does it monthly backup consolidation.

The point about the admin user is not so much the additional disk space but rather permissions to delete anything and everything as needed. You can also make your time machine user part of the admin group on the DS that should work as well. But again the disk quota limit won't work anymore as admin group has no limits.

Re if this is a Synology thing or not I am divided. The root cause for this is with no doubt Netatalk which is the free public implementation of the AFP that is needed for your Macs talking to the Synology box. Now that's is open source software that everyody uses and hence all have the same problem. However Synology as a company has come out and made a statement that they do support Macs and Time Machine backups hence in my opinion they cannot just turnaround and say, oh that's a fault of the open source code we use. There needs to be some responsibilities to their claims, maybe even contributing to the open source project and fixing it up if it has to be done.