Time Machine Frequent "Start New Backup"

But this time, for the first time tanks to Murphy I think, I seen the error live!

Something goes wrong...it will be checked in the next backup. The next backup told me that...guess it...

"Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you"

This is the first time that this happens after few hours.

But I am still ali

i

i

i

v

v

e

Knock knock? Anybody there?

May be I didn't find the right thread, but since Lion I must create new backups because "Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you."

I am a little bit ****** off to lose my (old) backups because this.

In the years, I changed the TimeCapsule HD (wired, not wi-fi), I used NAS hd, a shared PowerMac hd and a connected USB3 hd always with the same result: after some months, sometimes weeks, of backups I read the hated message

"Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you."

Now: does someone knows why this happens?

Looking at console log I didn't find nothing. As Ijust wrote, I used different destination disks (excepting firewire).

I know, I can change backup method but Time Machine interface is really snug to use...if it worked

(thanks)

(enjoy these lines)

Sep 30 00:08:32 iMac-Bum-Bum-2 backupd[4615]: objc[4615]: __weak variable at 0x7fad1fb003d0 holds 0x7fad1df00008 instead of 0x7fad1df00e80. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Sep 30 00:08:32 iMac-Bum-Bum-2 backupd[4615]: objc[4615]: __weak variable at 0x7fad1f821090 holds 0x7ffff04061a8 instead of 0x7fad1df00e80. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Sep 30 01:08:15 iMac-Bum-Bum-2 backupd[4731]: objc[4731]: __weak variable at 0x7fc3b3900bd0 holds 0x7fc3b390000a instead of 0x7fc3b3900560. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Sep 30 01:08:15 iMac-Bum-Bum-2 backupd[4731]: objc[4731]: __weak variable at 0x7fc3b1d09580 holds 0x706f2d6f74756111 instead of 0x7fc3b3900560. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 2 10:17:11 iMac-Bum-Bum-2 backupd[4841]: objc[4841]: __weak variable at 0x7f843ff0fa80 holds 0x7f843ff00019 instead of 0x7f843ff0fa20. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 2 10:17:11 iMac-Bum-Bum-2 backupd[4841]: objc[4841]: __weak variable at 0x7f8442000cd0 holds 0x7f8442020003 instead of 0x7f84420237c0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 2 10:17:11 iMac-Bum-Bum-2 backupd[4841]: objc[4841]: __weak variable at 0x7f843fc0d4a0 holds 0x7f843fc0e550 instead of 0x7f84420237c0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 2 10:18:18 iMac-Bum-Bum-2 backupd[4841]: objc[4841]: __weak variable at 0x7f8445c05be0 holds 0x7f8445c00003 instead of 0x7f8445c05b80. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 2 10:18:18 iMac-Bum-Bum-2 backupd[4841]: objc[4841]: __weak variable at 0x7f8445d05aa0 holds 0x7ffff0400002 instead of 0x7f8445c05b80. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 2 11:16:13 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): com.apple.backupd-auto: EnablePressuredExit is not compatible with KeepAlive=true. Ignoring EnablePressuredExit.

Oct 2 11:16:13 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.backupd-helper.status): The HideUntilCheckIn property is an architectural performance issue. Please transition away from it.

Oct 2 11:16:13 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.backupd-auto): This service is defined to be constantly running and is inherently inefficient.

Oct 2 11:16:17 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.prefs.backup.remoteservice[8350]): Service exited due to signal: Killed: 9 sent by com.apple.prefs.backup.remoteser[8350]

Oct 2 20:01:16 localhost com.apple.xpc.launchd[1] (com.apple.backupd-status): The HideUntilCheckIn property is an architectural performance issue. Please transition away from it.

Oct 2 20:01:18 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): com.apple.backupd-auto: EnablePressuredExit is not compatible with KeepAlive=true. Ignoring EnablePressuredExit.

Oct 2 20:01:18 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.backupd-helper.status): The HideUntilCheckIn property is an architectural performance issue. Please transition away from it.

Oct 2 20:01:18 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.backupd-auto): This service is defined to be constantly running and is inherently inefficient.

Oct 3 00:00:33 iMac-Bum-Bum-2 backupd[220]: objc[220]: __weak variable at 0x7fd8f0407750 holds 0x7fd8f0400021 instead of 0x7fd8f04075d0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 00:00:33 iMac-Bum-Bum-2 backupd[220]: objc[220]: __weak variable at 0x7fd8f0704e80 holds 0x7fffb09c2928 instead of 0x7fd8f04075d0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 00:04:55 iMac-Bum-Bum-2 backupd[220]: objc[220]: __weak variable at 0x7fd8f9821670 holds 0x7fd8f9820019 instead of 0x7fd8f9821610. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 00:04:55 iMac-Bum-Bum-2 backupd[220]: objc[220]: __weak variable at 0x7fd8f991eab0 holds 0x800010060015821 instead of 0x7fd8f9821610. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 00:44:01 iMac-Bum-Bum-2 backupd[2120]: objc[2120]: __weak variable at 0x7fa8854312d0 holds 0x7fa885430003 instead of 0x7fa885436a80. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 00:44:01 iMac-Bum-Bum-2 backupd[2120]: objc[2120]: __weak variable at 0x7fa88550a550 holds 0x7fa885509c80 instead of 0x7fa885436a80. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 01:46:59 iMac-Bum-Bum-2 backupd[2181]: objc[2181]: __weak variable at 0x7fda6d535ca0 holds 0x7fda6d530003 instead of 0x7fda6d537710. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 01:46:59 iMac-Bum-Bum-2 backupd[2181]: objc[2181]: __weak variable at 0x7fda6d535610 holds 0x75612d70696b7320 instead of 0x7fda6d537710. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 02:44:25 iMac-Bum-Bum-2 backupd[2241]: objc[2241]: __weak variable at 0x7f9073523110 holds 0x7f9073520003 instead of 0x7f90735231e0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 03:44:34 iMac-Bum-Bum-2 backupd[2349]: objc[2349]: __weak variable at 0x7f917f507180 holds 0x7f917f500003 instead of 0x7f917f507270. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 03:44:34 iMac-Bum-Bum-2 backupd[2349]: objc[2349]: __weak variable at 0x7f917f436c90 holds 0x642d746e6567610e instead of 0x7f917f507270. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 04:44:40 iMac-Bum-Bum-2 backupd[2415]: objc[2415]: __weak variable at 0x7ff869827770 holds 0x7ff869810019 instead of 0x7ff869818d90. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 04:44:40 iMac-Bum-Bum-2 backupd[2415]: objc[2415]: __weak variable at 0x7ff867d02930 holds 0x7ff867d06290 instead of 0x7ff869818d90. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 05:44:28 iMac-Bum-Bum-2 backupd[2477]: objc[2477]: __weak variable at 0x7fa5b7509e30 holds 0x7fa5b7500003 instead of 0x7fa5b7509d00. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 05:44:28 iMac-Bum-Bum-2 backupd[2477]: objc[2477]: __weak variable at 0x7fa5b9900440 holds 0x7fffb08fcbb0 instead of 0x7fa5b7509d00. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 06:38:14 iMac-Bum-Bum-2 backupd[2536]: objc[2536]: __weak variable at 0x7fa04650b050 holds 0x7fa046500003 instead of 0x7fa04650af20. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 06:38:14 iMac-Bum-Bum-2 backupd[2536]: objc[2536]: __weak variable at 0x7fa04803e980 holds 0x7fa0480400a0 instead of 0x7fa04650af20. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 07:38:23 iMac-Bum-Bum-2 backupd[2597]: objc[2597]: __weak variable at 0x7f847de0fb20 holds 0x7f847de00003 instead of 0x7f847de0f9a0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 07:38:23 iMac-Bum-Bum-2 backupd[2597]: objc[2597]: __weak variable at 0x7f847dc365a0 holds 0x5441465f534f440c instead of 0x7f847de0f9a0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 08:39:39 iMac-Bum-Bum-2 backupd[2659]: objc[2659]: __weak variable at 0x7faa2f41e310 holds 0x7faa2f410003 instead of 0x7faa2f41e190. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 08:39:39 iMac-Bum-Bum-2 backupd[2659]: objc[2659]: __weak variable at 0x7faa2f514b90 holds 0x13 instead of 0x7faa2f41e190. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 09:33:05 iMac-Bum-Bum-2 backupd[2732]: objc[2732]: __weak variable at 0x7fee5341c110 holds 0x7fee53410003 instead of 0x7fee5341bfe0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 10:41:36 iMac-Bum-Bum-2 backupd[3477]: objc[3477]: __weak variable at 0x7f8aaff2ec80 holds 0x7f8aaff2de90 instead of 0x7f8ab2300ea0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 12:08:43 iMac-Bum-Bum-2 backupd[3722]: objc[3722]: __weak variable at 0x7fe2a3102f90 holds 0x7fe2a3000003 instead of 0x7fe2a3004850. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 12:08:43 iMac-Bum-Bum-2 backupd[3722]: objc[3722]: __weak variable at 0x7fe2a1728c90 holds 0x7fe2a16021f0 instead of 0x7fe2a3004850. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 14:00:08 iMac-Bum-Bum-2 TimeMachineScheduler[4291]: currentVolume: SKBackupVolume - name: TeraDo - isSharedVolume: 1

Oct 3 14:00:08 iMac-Bum-Bum-2 TimeMachineScheduler[4291]: autoBackup: 0 - requiresACPower: 0, localizedDiskImageVolumeName: Backup di Time Machine

Oct 3 14:00:08 iMac-Bum-Bum-2 TimeMachineScheduler[4291]: backup phase: (null)

Oct 3 14:05:57 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): com.apple.backupd-auto: EnablePressuredExit is not compatible with KeepAlive=true. Ignoring EnablePressuredExit.

Oct 3 14:05:57 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.backupd-helper.status): The HideUntilCheckIn property is an architectural performance issue. Please transition away from it.

Oct 3 14:05:57 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.backupd-auto): This service is defined to be constantly running and is inherently inefficient.

Oct 3 14:06:21 iMac-Bum-Bum-2 com.apple.xpc.launchd[1] (com.apple.prefs.backup.remoteservice[3962]): Service did not exit 5 seconds after SIGTERM. Sending SIGKILL.

Oct 3 15:13:23 iMac-Bum-Bum-2 backupd[4476]: objc[4476]: __weak variable at 0x7fddfb50c890 holds 0x7fddfb500006 instead of 0x7fddfb50d5a0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

Oct 3 15:13:23 iMac-Bum-Bum-2 backupd[4476]: objc[4476]: __weak variable at 0x7fddfb640750 holds 0x2 instead of 0x7fddfb50d5a0. This is probably incorrect use of objc_storeWeak() and objc_loadWeak(). Break on objc_weak_error to debug.

I have been having the same issue. I get the following message and need to create a new backup; it happens about once a month.

"Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you"

I also have a Synology NAS (DS209 current firmware). I contacted Synology support and they had me send them my Time Machine logs and kernel logs from the disk station. I received the following response from Synology today...

"I looked over the logs and the time machine logs,

and there isn't any errors with the disk station.

So the data over the network is somehow being corrupted, but your mac is initiating the scan.

are you using wireless?"

So it looks like Synology support is implying the corruption is due to Lion and wireless (I am using wireless). I have Applecare, I wonder if it's worth contacting them? I have since performed a new backup, so I am currently not having a problem. Perhaps the next time it gets corrupted, I will call Applecare.

Think I have a similar / the same.

For a while (post Lion) I had ****-and-all problems getting a stable backup regime running from my Macbook Pro to my Synology Diskstation 710+. However I got it working finally by:

- Adding 10.7.2 upgrade to the Mac

- Setting the Diskstation to a static IP

- Upgrading to the (then) latest Diskstation firmware

AND THEN FINALLY

- Repairing the sparsebundle on the Diskstation.

What I found strange was WHY was the sparsebundle needing repair in the first place? It was newly created by my Mac. Strange that, almost immediately, it was corrupt and in need of repair (elsewhere on these forums I reported all the errors produced in the Disk Utility logs when I did the repair).

Anyway, it stabilised. Then, after the Mac was away from the network for a while, the next time it connected to our LAN the error reappeared. I don't know if it was this passage of time which created the issue.

I will now try (again) the sparsebundle repair to see if that works.

What worries me is how we (as Mac and Synology users) avoid being bounced between Apple and Synology, which neither producing a satisfactory response and each saying the error is down to the other.

Has anyone made any progress with this?

Thanks

UPDATE

Sure enough once again the sparsebundle is corrupted.

The error in Disk Utility when verified was:

Invalid sibling link

The volume Time Machine Backups was found corrupt and needs to be repaired

However when I then attempted to repair (as instructed), the Repair button was greyed-out and the utility says I need to reboot using the system disk bla bla bla...

Just happened to me again. Synology is saying it's Apples problem and that the diskstation is working fine. He seems to think data is getting corrupt via wireless connection. Which lends itself to the theory that it happens when backup is happening while it goes to sleep. This is absolutely ridiculous.

Received another reply from synology pointing to Lion as the problem...

Here is what I received from my engineers.

This problem seems to have happened since OSX 10.7.

We use the open source - netatalk to support AFP and

it summarized that this problem also exists on Apple Time Capsule too.

(http://www.netafp.com/tn005-10-7-lion-time-machine-and-netatalkafp-620/

https://discussions.apple.com/thread/3696035 )

For the Macs that doesn't trigger "Start New Backup" YET,

users may use the following method to try and fix the verification flag and avoid wiping out all old backup history.

http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-b ased-backup-errors.html

http://pondini.org/TM/C13.html

Hey Apple are you seeing this?!?!

I'm am seeing this on new Macbook Air with Lion. In fact, it just did new Backup LAST NIGHT and this morning it tells me it needs to create a NEW one! (My wifes MB Air with snow leopard is NOT having this issue.) So definitely pointing to a Lion issue. I just upgraded to 10.7.3. Will that fix it, Apple?

FWIW I'm seeing the same issue on a MacBook Pro (i7) running 10.6.8. Backing up to a Linux NAS via SMB over wireless (Linksys WRT54G). I frequently close the lid on my MBP while a Time Machine backup is in progress because I don't notice that it's running.

Hello

I am seeing more frequent requests to start a new backup on our Macbook running Snow Leopard 10.6.8. Time Machine is backup up to our QNAP NAS.

I am not sure why this is happening more frequently though.

Joining this group of people with the same problem: I have had it on my Synology DS211, and this on my iMac and my iBook. All after Lion. I hope Apple will sort this one out. Luckily it is at home, so the 3 times it has happened I have just re-created it.. but it doesn't give a good feeling.

I'm seeing this on two MacBook Pros - one (15" old case) on Snow Leopard and the other (15" unibody) on Lion - backing up to a Synology DiskStation DS212j over wireless. It has happened more often on Lion, but it has definitely happened on Snow Leopard.

I now have a UPS on the DiskStation, but that has not solved it. I was thinking that I might have to get a Time Capsule, but from what others have said, this won't solve it either.

C'mon Apple - what is the point of the best backup system if it regularly trashes your entire backup history?

Thanks for this thread, I have the same issue with my Time Capsule. About once a month it creates a new backup and deletes all my previous backups. I have a 2010 MPB with updated software (10.7.3). I am looking forward to hearing the solution.

I have the same problem. I am using a 13" macbook pro with a GOFLEX Home Agent from Seagate.

10.7.4 operating system. Every few months I get the verification failed message and have to start over. I access this mostly wirelessly. There are 2TB of space of which about 1.4 TB is used and the back-up takes 2 days and is about 380GB