Previous 1 8 9 10 11 12 Next 174 Replies Latest reply: Feb 18, 2014 8:41 AM by bernuli Go to original post
  • Pondini Level 8 (38,740 points)

    stBorchert wrote:

    . . .

    Yes, TimeTracker indeed gave me a hint about a large change: its MySQL inside my MAMP. The data file for InnoDB is about 9GB and is changing very often (since I'm developing on my MacBook there are a lot of databases which changes regulary).

    It's strange that this hasn't been a problem before I upgraded to Mountain Lion.

    Good question -- just a guess -- did any of that software change when you upgraded to ML? 



    On the other side the largest backup made yesterday (42.2GB) includes the complete Application folder. For development purposes I'm running Apache Solr (located in a subfolder of /Applications). Is it possible that this causes the Application folder to marked as changed so it is backed up?

    Another good question.  Again, I'm not familiar with the software, much less how it works, but it shouldn't be doing anything to cause that.  You might check with the maker.


    The log you posted earlier included the "Using file event preflight..." message, which means TM used the File System Event Store to figure out what changed (see the blue box in How Time Machine works its Magic

    for an explanation).  Double-check whether everything in the Applications folder was backed-up -- ie, were the Utilities and/or other sub-folders backed-up in full?  Those sub-folders wouldn't have been backed-up unless they were also marked as changed.


    I will try to see how to prevent MySQL from changing the data file or how to reduce its size

    That's likely to be difficult or impossible.    Do you have other backups (always a good idea)?  If so, and they're updated fairly often, you could just exclude the file from being backed-up by TM, per Time Machine - Frequently Asked Question #10.  If not, consider that, per #27 in the same link.

  • stBorchert Level 1 (0 points)

    Seems I could fix the problem for now.

    I excluded "ibdata1" from backup (the file will be recreated automatically when importing the backed-up databases, so I see no problem here) and deactivated "XtraFinder" (I remember I had to reinstall this after upgrading to Mountain Lion).

    Now the backups are very small:


    Thanks for your help and the hints.

  • Pondini Level 8 (38,740 points)

    Ah, great! 


    Glad it's sorted out, and thanks for the feedback.

  • Yeehat Level 1 (40 points)

    Pondini wrote:


    PierrickL wrote:

    . . .

    Node requires deep traversal:/ reason:contains changes|must scan subdirs|fsevent|

    That's the same message Stephen is getting, and is quite odd to get it twice in the same backup.  It sounds like a very high volume of file changes, which could happen for the first "pass," but makes no sense for the second.


    Well, I'm going to add my own experience to this old thread. It was quite a brand new issue for me after years of 10.6.8 and am grateful for having found a (temporary?) solution here. I had "only" 1712 files in .fseventsd but the command rm -rf /.fsevenstd/* in single user mode did the trick (I had already tried unsuccessfully booting in safe mode).


    I'd like to add that since a few weeks I had noticed that the number of files copied in the first and the second pass was identical and that sounded weird. Even weirder the many MB copied in the second pass when compared to the size of the first (I keep my main volume pretty slender, exclude from backups a few critical folders subject to lots of changes and the second pass used to amount to less than 1 MB). Unfortunately I haven't the logs anymore, but I remember no other odd messages. Just 2 or 3 days ago the Node requires deep traversal thing began.


    Of course I can't tell what happened. It might be useful for future reference reporting that over last months backups were getting slower and slower (I'm using a 3rd generationTime Capsule). I resolved to give a try with DiskWarrior 4.4 connecting with cable. While reading the backup volume's directory DW signaled speed inhibited by disk malfunction and its log reported a bad block. While checking for differences in files and folders (step 9), the process got stuck and I had no other choice than forcing shutdown. Then I erased and zeroed out Time Capsule's disk and for maybe two weeks everything ran smooth. Until the above new issue. I really don't know whether an impending disk failure can be related to Time Machine always requiring deep traversals.

  • bernuli Level 1 (50 points)

    I found the solution to my Time Machine problem, though mine may be pretty unique.  The cause appears to be the Partition function of Apple’s Disk Utility.


    When I first installed Snow Leopard on my MBP, I used Disk Utility to delete the existing partition, then I created a new partition using the + sign in the Partition tab.  I have always done this with fresh installs or new disks.  For some reason, boot disks (and perhaps non boot disks) that are freshly partitioned with Disk Utility from the 10.6.3 retail DVD will confuse Time Machine and cause it to run slower and slower.  Slower as in 20 minutes to complete a backup with no files changed, and nothing running.


    I reinstalled Snow Leopard, but this time simply used the Erase function to erase the entire HD, not just the partition.   After erasing the HD and reinstalling Snow Leopard, TM runs MUCH faster.  Backups complete on the first loop in under a minute.  I am no longer seeing:


    Needs new backup due to change in /

    Some filesystem changes made during the course of the backup may not be accounted for. Still busy after 2 retries.


    in Backup.log


    It seems like this is a bug with Apple’s Disk Utility, perhaps not accounting for the hard drive’s Last Block correctly.  Or maybe you are just not supposed to use the Partition tab to create new partitions, only resize?


    Anyway I verified the problem on 3 different machines each with different hard drives, none of them liked a partition created by Disk Utility’s Partition function. 





  • ZX48 Level 1 (0 points)

    Hi Bernuli. That is interesting. The disk I have trouble with is also partitioned using Disk Utility. I've pretty much abandoned Time Machine since it takes over an hour to complete each run (with the fans spinning).


    I have a Mac mini with 2 disks inside. Both are partitioned, but I only would like to use Time Mchine on the main partition (the otheres are manual backups and separate installs of Lione etc). Do you think it would be OK if I kept multiple partitions on disk 2 (and exlcuded them all from Time Machine), and reformatted Disk 1 (SSD) with just my main Snow Leopard Install?


    Plan: I can temporarily clone Disk 1 (SL partition) to a new partition on Disk 2 and then erase all of Disk 1. But then I would like to simply clone the Snow Leopard partition back from Disk 2 onto Disk 1. Do you think this would work to resolve the situation? I want to avoid reinstalling the OS and all my files. Do you know if there is a way to clone it back without first having to use Disk Utility to make a partition on Disk 1?

  • Yeehat Level 1 (40 points)

    Just to be sure, your Time Machine backups were getting slower and slower because a double deep traversal was always required or hung generically? Be that as it may, my issue is not related to Disk Utility partitioning.

  • ZX48 Level 1 (0 points)

    Hi Yeehat. My backups are just continually slow, whether or not I make any changes to the files. It is NOT performing a deep traversal.

  • bernuli Level 1 (50 points)



    I am not sure we have the same problem.  The fans on my Macbook Pro never sped up, and the backups never quite hit an hour.  When my backups slowed down, I would delete /.fseventsd.  This was a temporary solution as over time the backups would slow down. 


    I don't remember seeing the Deep Traversal note in .Backup.log, though I was not specifically looking for it.


    You can tell if you have the same problem as me by creating a new folder and putting a text file in it.  Then run TM.  Then edit the text file.  Then run TM 3-4 times, but do NOT make any more changes to the text file.  After you have a little history, run:


    stat -f %i%t%N /Volumes/YOURTMDRIVE/Backups.backupdb/NAMEOFCOMPY/*/MacHD/Users/USERNAME/TMTEST DIR


    That will display the inode and full path to the folder you are checking.  You should see mostly the same inode number.  If it is different for each TM run, and you have not made any changes, then your problem is the same as mine.


    Also I think the following log entry will coincide with the problem.


    Needs new backup due to change in /

    Some filesystem changes made during the course of the backup may not be accounted for. Still busy after 2 retries.


    I think cloning your drive will work.  What utility do you plan to use?  I will try it out and see if TM works okay after format and clone restore.


    I only have one HD in my Mac Pro which I have been using as a test machine, so I can't speak to that now.


    My Macbook Pro has the one internal, I am just finishing up a fresh install so I will let you know how that works.  The problem affecting me is easily repeatable though so I am sure I will be good after fresh install complete.



  • bernuli Level 1 (50 points)

    Well it turns out my 2008 MacBook Pro is still having Time Machine issues even after applying disk partioning work around. I also installed a new internal HD but I am still seeing the TM slowdown.


    I am now partitioning with the original 10.5.4 DVD.  Will see if that makes a difference. 




Previous 1 8 9 10 11 12 Next