Previous 1 2 3 4 5 6 Next 81 Replies Latest reply: Jul 9, 2012 11:52 AM by EbkoTurpeinen Go to original post
  • Raf Level 2 Level 2 (195 points)

    I switched to the TimeCapsule on Feb 12, as the check that caused the issue is run monthly, I still have a few days to wait.

     

    I'll keep you posted.

     

    Raf

  • Dave Yeager Level 1 Level 1 (10 points)

    Again, sorry if this is not relevant, but I did find it interesting to read:

    http://support.apple.com/kb/HT4076http://

     

    The summary reads:

    "Apple has identified an issue on some Time Capsule systems that could potentially make previous backups unavailable. The Time Capsule Backup Update improves reliability of affected Mac OS X v10.6 systems by creating a new backup."

     

    This is for earlier software versions, but again, interesting.

     

    One other coincidence.  In my case, the 'error msg' appeared 2 weeks to the day after i installed the OS update 10.7.3.

  • hoppah Level 1 Level 1 (0 points)

    In reply to Mr. Yeager and the rest of this motley crew...

     

    Yes, as of today there have been no further problems.  This represents almost three weeks since my last issue without a breakdown.  Given that I had never gone more than two before, and for the last month and a half it was happening every week, I must conclude that this was the result of a bizarre TM issue which interacts with problems on the source with the files themselves.  This problem went away after the following three things happened:

     

    1.  Full clean single-user-mode fsck on the source drive.  It has to be run repeatedly until it comes back with no issues.  Mine required at least three passes to run clean.

    2.  Full permissions fix on the source drive.

    3.  Delete backup and start new.

     

    It was very hard to imagine that these problems were due to source file issues, given the odd periodicity of them, but clearly file problems somehow interact with TM to cause this issue.  The files are also clearly stored with issues in them, as the backup failed *after* I completed #1 and #2 - but once the bad backup (the one containing a week's worth of backups of the bad files) had been deleted, it ran clean and has done so ever since.

     

    Thanks to all, especially Podini, for your tireless efforts.

     

    G.

  • hoppah Level 1 Level 1 (0 points)

    I spoke too soon.  This morning, poof.  One month, again on a Monday.

     

     

     

    G.

  • Raf Level 2 Level 2 (195 points)

    Today, my backup has been verified (TimeCapsule-based) as part of the monthly "schedule".

     

    So it seems that the issue is located on non-TimeCapsule drives, at least in my case.

     

    On another side, my index is toasted:

     

    3/13/12 8:33:31.610 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:34:32.771 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:35:34.394 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:36:34.881 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:37:35.994 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:38:36.795 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:39:37.611 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:40:39.220 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:41:39.614 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:42:39.768 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:43:40.714 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:44:41.550 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:45:42.372 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:46:43.854 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:47:45.391 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:48:46.764 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:49:47.053 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:50:48.668 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:51:49.289 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:52:51.179 AM com.apple.backupd: Waiting for index to be ready (100)

    3/13/12 8:53:51.658 AM com.apple.backupd: Waiting for index to be ready (100)

     

     

    Raf

  • hoppah Level 1 Level 1 (0 points)

    Update:

     

    After the last "poof" I really started digging and found something interesting.  I was always puzzled at the periodicity of the problem (always Monday mornings).  I discovered that my NAS upon which the TM server is hosted runs a weekly RAID scrub starting at 4AM, which runs until around 11AM.  The TM failure always occurred in this time frame - around 8-9 AM.  For those of you new to this thread, TM was invalidating my backup history every week or two, on a Monday, and recreating a backup.  This problem started with Lion - it never existed before.  Something about Lion is less accurate when it comes to verification of writing, so the data is being corrupted when the NAS is busy scrubbing the RAID.

     

    I decided this must be the process which is the proximate cause (the main problem being some change in Lion's writing of the data).  But how to fix it?  TM backs up very often, so it won't do to just change when the RAID scrub occurs.  I found myself wishing there were a feature in TM that would let me "window" the backup schedule to avoid the RAID scrub time frame.  So I did some searching and found "TimeMachineEditor", a free utility that lets you build complex schedules to run TM.  I was not only able to window the TM process to avoid the RAID scrub, but I was also able to set TM to run hourly rather than every five minutes.

     

    So far this has worked.  I anticipate that this will solve my problem.  I will of course keep you all posted.

     

    Thanks for your time,

     

    H.

  • Lost In Austin Level 1 Level 1 (5 points)

    hoppah, this is excellent news. how long have you been using these scheme w/o seeing TM errors?

  • hoppah Level 1 Level 1 (0 points)

    Four weeks now, which is as long as its ever gone without a "poof".

     

    H.

  • Christof Birkenmaier Level 1 Level 1 (5 points)

    A simple way to repair TimeMachine Backups on a NAS Storage  (in this case a Synology DiskStation 210 j, typically used via WLAN from 2 MacBook Pros, running the latest version of Snow Leopard)  When it first happened to me, I tried to follow Garth’s recommendations, but somehow I seem to be too inadept with the terminal. I then tried around, using some of the facts that I learnt in different blogs. Since then, it has worked for me twice.  Here’s how:  First, inactivate TimeMachine or chose a different backup disk.  Next, you have to make the “broken” backup accessible by:  1.     Mount the NAS share on which the disk image resides. (There probably is a „locked“ symbol at the bottom left corner oft the image’s icon)  2.     Control-click the icon and select „Show Package Contents“. There probably are 2 files with a „locked“ symbol inside the package: „com.apple.TimeMachine.MachineID.plist“ and „token“.  3.     Select each one of them; call up the info window by either clicking „command-I“ or by using the menu. The checkbox „locked“ will be selected. Deselect it and close the info window. When you are done with both files, close the package window.  Next, you have to mount the disk image, which can take quite some time and which is best done using a LAN cable.  4.     Navigate through the folder levels until you find the folders, which are named after date and time of each individual backup.  5.     Assuming that something went wrong during the last backup, throw the complete contents oft the „Latest“ alias into the trashcan. This usually requires unlocking several of the contained folders using info window as described above. Empty the trash.  6.     Just to be on the safe side, I always removed the 2 most recent folders as well, but I don’t know whether this is really necessary.  7.     Write down date and time of the most recent folder you leave behind.  8.     Next, run Disk Utility to repair the image  9.     Eject the image  Now, you have to modify the „com.apple.TimeMachine.MachineID.plist“ file that you unlocked in step 3 to reflect the new status of the backup:  10.     Open the package contents  11.     Open the file with the “Text Edit” application.  12.     In the line “yyyy-mm-ddThh:mm:ssZ” adjust date and time to the date and time of the most recent folder left in the sparse bundle disk image.  13.     The line “number” may read “2”. Change it to “1”.  14.     Close and save the file.  15.     Close the package window.  16.     Activate TimeMachine and select the repaired NAS share. Option-click on the TimeMachine icon in the menu bar and select “Verify Backups”. After this has finished, you should be back in business.

  • BflatBlues Level 2 Level 2 (215 points)

    Today I received the message:

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

     

    Click Start New Backup to create a new backup. This will remove your existing backup history. This could take several hours.

     

    Click Back Up Later to be reminded tomorrow. Time Machine won’t perform backups during this time.

    I'm running a Mac Pro with OS X 10.7.3 and I'm backing up to a ReadyNAS Pro. I've had no problems with my TM backup in at least 8 or 9 months, maybe longer. I read here that there is at least one other user with similar problems. I know this is a long thread, but any suggestion on how to fix my backup and not lose it would be greatly appreciated.

  • Christof Birkenmaier Level 1 Level 1 (5 points)

    You may want to try, what worked for me under 10.6.8. I submitted it already a few days ago, but the formatting was not really nice. So here it is again:

     

    First, inactivate TimeMachine or chose a different backup disk.

     

    Next, you have to make the “broken” backup accessible by:

     

    1. Mount the NAS share on which the disk image resides. (There probably is a „locked“ symbol at the bottom left corner oft the image’s icon)
    2. Control-click the icon and select „Show Package Contents“. There probably are 2 files with a „locked“ symbol inside the package: „com.apple.TimeMachine.MachineID.plist“ and „token“.
       
    3. Select each one of them; call up the info window by either clicking „command-I“ or by using the menu. The checkbox „locked“ will be selected. Deselect it and close the info window. When you are done with both files, close the package window.
       

    Next, you have to mount the disk image, which can take quite some time and which is best done using a LAN cable.
     

    1. Navigate through the folder levels until you find the folders, which are named after date and time of each individual backup.
       
    2. Assuming that something went wrong during the last backup, throw the complete contents oft the „Latest“ alias into the trashcan. This usually requires unlocking several of the contained folders using info window as described above. Empty the trash.
       
    3. Just to be on the safe side, I always removed the 2 most recent folders as well, but I don’t know whether this is really necessary.
       
    4. Write down date and time of the most recent folder you leave behind.
       
    5. Next, run Disk Utility to repair the image
       
    6. Eject the image
       

    Now, you have to modify the „com.apple.TimeMachine.MachineID.plist“ file that you unlocked in step 3 to reflect the new status of the backup:

    1. Open the package contents (as above)
    2. Open the file with the “Text Edit” application.
    3. In the line “<date>yyyy-mm-ddThh:mm:ssZ</date>” adjust date and time to the date and time of the most recent folder left in the sparse bundle disk image.

    4. The line “<integer>number</integer>” may read “<integer>2</integer>”. Change it to “<integer>1</integer>”.
    5. Close and save the file.
    6. Close the package window.
       
    7. Activate TimeMachine and select the repaired NAS share. Option-click on the TimeMachine icon in the menu bar and select “Verify Backups”. After this has finished, you should be back in business.
  • drm31078 Level 1 Level 1 (0 points)

    Has anyone received any statements from Apple on this issue, perhaps via Applecare?  I have been unsuccessfull because I am using a Synology network drive, so Applecare immediatly says they don't support that drive and ends the applecare call...since of course its not a problem with an Apple product.

  • BflatBlues Level 2 Level 2 (215 points)

    Thank you for taking the time to present your solution. I'm not sure where to start with it, however. I'm running 10.7.3.

     

    Next, you have to make the “broken” backup accessible by:

     

    1. Mount the NAS share on which the disk image resides. (There probably is a „locked“ symbol at the bottom left corner oft the image’s icon)
    2. Control-click the icon and select „Show Package Contents“. There probably are 2 files with a „locked“ symbol inside the package: „com.apple.TimeMachine.MachineID.plist“ and „token“.
       
    3. Select each one of them; call up the info window by either clicking „command-I“ or by using the menu. The checkbox „locked“ will be selected. Deselect it and close the info window. When you are done with both files, close the package window.

     

    Are you saying that, in order to follow your instructions, I should take my NAS off the network and connect it (via ethernet cable) directly to my Mac Pro? I guess I'm also confused about what you describe as a "locked" symbol at the bottom of the image's icon, too.

     

    I can access the hidden ./timemachine directory via Terminal. Would there be a way to follow your instructions using Terminal?

     

    Thanks.

  • Christof Birkenmaier Level 1 Level 1 (5 points)

    Hi there!

     

    In my case, the NAS is attached to my WLAN router which also has ethernet ports. Since this repair process shifts a lot of data forth and back, it is faster and more reliable when you connect you Mac via an ethernet cable to the router and thus to the NAS rather than doing it all via WLAN.

     

    Depending on the view settings in your finder windows, a locked file will show a little padlock symbol in its bottom left corner. Mac OS locks the sparsebundle (by locking some files inside it) when it finds an error, so you cannot continue backing up and (according to what OS X wants you to do) would have to start a new backup from scratch.

     

    Can't comment on terminal - I found this way because I had trouble working with terminal

     

    Hope this helps, Christof

  • hansolo415 Level 1 Level 1 (0 points)

    I have just upgraded to 10.7.4 and have been experiencing similar problems on a 2011 Macbook Pro 13" connected via LAN to a time capsule set-up on a GO FLEX HOME AGENT.  Every few months the back-up fails the verification procedure and needs to re replaced.  I don't know if this happens at a regular interval, but it happens frequently enough that it makes the back-ups almost pointless.  My back-ups are 380GB so they take over a day to do and if something fails I have to start over so it's a real pain.  The drive I am using is 2TB and has about 600GB free for the back-up.

     

    Your descriptions are way beyond my technical know how so I don't have any idea what you mean by mounting drives or even what a sparsebundle is.

     

    Has anyone come up with a simple list of the most common things to do to prevent this from happening again and again and again. 

     

    It almost seems like it would be better NOT to allow time machine to make so many frequent back-ups on an hourly basis etc.  Perhaps it would be better to just tell it when you want an update.

     

    Thanks for whatever help and further explanation you guys can provide as to your solutions.