SyncToy slowed tremendously after deleting files RRS feed

  • Question

  • I use SyncToy to backup a small office file server. I use two external drives on a rotational basis and have two pairs defined, one for each drive. I configured the action to 'contribute', so I would never lose a file even after deletion from the server. The usual run time for the backup has typically been well under 2 minutes. 

    Two days ago I deleted several never-used folders from the server, thinking that eliminating several thousand files from the scan would increase the run time of the backup, although it was really more about eliminating needless file scanning than wasting some fragment of two minutes. 

    Ever since deleting those files, SyncToy has practically choked on the subsequent backups. It hangs for several minutes at several different parts of the process, both scanning for differences and in creating actions. 

    I checked this forum and decided to turn off "Save overwritten files in the recycle bin", because there actually were hundreds of files in the trash. I emptied the trash, turned this option off and reran the backup, but it is still hanging in several spots. It doesn't stop or fail altogether, just hangs for a few moments in these places, then finally picks up and flies along to the next stop point. 

    Subsequent runs has revealed that the hangs are at the same points in the process. I have examined those folders and files and nothing is wrong with them. They are accessible, usable, changeable in every normal way, yet cause SyncToy some mysterious consternation when encountered during a sync. 

    I have also noted that the PC is definitely working hard at something, because response to any other task while it's syncing is extremely slow, while this was never the case before. 

    What's going on? How did deleting files cause this slowdown? What can I do to eliminate this condition and streamline the process (which is what I thought I was doing by eliminating some 'least used' files from the server in the first place)? 

    Any help or insight would be appreciated. 
    Friday, January 9, 2009 3:39 PM

All replies

  • I too am having the same issues syncing to my fast USB stick.


    I recently upgraded from Synctoy 2 beta to Synctoy 2.0. I deleted all the synctoy sync files & then setup the folder pair & ran it for the first time. It would run for about 40 mins (far longer than normal) & appeared to be hanging in the same spot every time... Once though I let it run for over an hour & when I came back it had moved on to another folder... so even though I thought it had locked up, it was only extremely slow. The folder it seems to choke on has thousands of small files in quite a few sub-folders - so it seems it's the number of files/folders that's causing my issue.


    I deleted the main cuplrit folder & while it did work (did about 14,000 files = 1.5 GB), it took over an hour, whereas before it only took about 20-30 minutes.


    I'm still searching for a solution...

    • Proposed as answer by FireOx Monday, February 9, 2009 3:06 AM
    Sunday, January 11, 2009 9:53 PM
  • can you look at and post text from the synctoy log? that will help us look at what exactly synctoy is doing ...




    Monday, January 12, 2009 6:34 PM
  • Thank you for your response. After today's normal, daily run, I reran SyncToy 3 more times using my own timer and watching the screen for any hang spots. These subsequent runs obviously had no changes, no copies to make, etc, since nothing changed between the runs - this is the fastest possible scenario.

    It is interesting to note that in each case, the actual elapsed time was longer than the reported time, logged as "SyncToy run took...". In the run log below, SyncToy reported that it took 5 mins and 7 secs, but my timing showed 6 mins and 40 secs. That's a significant discrepancy, but I don't know how that's relevant to the issue, ig at all.

    I also can report that for the 3 additional runs, the display stopped updating progress in the same two spots: the first for about one minute while "Looking for changes in..."; the second for a bit over 5 minutes while "Adding an action for..." !! FYI, the file at the scan hang spot was not the same as the file at the action hang spot. Below is the log from the last run. If you need before and after logs (before and after I deleted the folder, hping to speed things up), let me know.


    SYNC: 01/13/2009 09:01:09:953: SyncToy run of RAPCBU1 (C:\RAPCSHAREDFILES\, E:\RAPCBU1\) completed at 1/13/2009 9:01:09 AM.

    SyncToy action was 'Contribute'.

    SyncToy options were:

    Active for run all

    All files included

    No files excluded

    Do not check file contents

    Include read-only files

    Do not include hidden files

    Do not include system files

    Do not backup older files

    All subfolders included

    SyncToy run took 00:05:07:515.

    Copied 0 bytes in 0 files in 00:05:07:515.

    Bytes per second 0.0, files per second 0.0.

    Avoided copying 37,350,811,832 bytes in 41,892 files that did not require action.

    Saved approximately 20:45:01:00 by not copying all files.


    Tuesday, January 13, 2009 2:55 PM
  • Hello, Sid, 

    I am just wondering if my post of the sync log was helpful, or if you need more of the log. Is there a way I can reclaim SyncToy's speed, in this situation? 

    If not, what would be the best way to recover archived files (I have SyncToy set to 'contribute'), then start over with a fresh set of sync sets and then re-archive the contributed files? 

    And last, how did deleting the folder from the server cause SyncToy to work harder? Was there a process or procedure that should be followed when deleting from the server that would ensure SyncToy's optimum performance? 

    Thank you for any assistance... 

    - Kevin
    Monday, January 26, 2009 1:17 PM
  • Morning MrSHOVEL,

    I encountered the same problem after upgrading from SyncToy 2 Beta to SyncToy 2.0.  I am glad that I am not alone (just kidding), and managed to get back on track after struggling for a few days.  I would like to share with you and other guys who suffered the same of how to get over the hurdle.  First of all, let me spend a little bit of time explaining what happened after the upgrade.

    Although the source files and destination files were synced before the upgrade, they would be overwritten after the upgrade due to a difference in time stamp (for unknown reason to me) after you ran Preview by SyncToy 2.0.  It was the overwriting that took up most of the time, I supposed.

    I deleted all the folder pairs by SyncToy 2.0.  Then I deleted all the destination folders with theirs files by Windows Explorer.  Recreated the destination folders by Windows Explorer.  Recreated the folder pairs by SyncToy 2.0 and Preview the actions.  This time no files will be overwritten.  The speed was as fast as if the folders and files were copied by Windows Explorer.

    You can try this if you like.  I wish it worked for you too.

    Good Luck
    Monday, February 9, 2009 3:52 AM
  • Hello, FireOx, 

    Thank you for your suggestion to rebuild the folder pairs. In my case, I was trying to avoid that because my backups are set to 'contribute'. The main way this is different from 'synchronize' is that contribute is a one-way process, while sync is bi-directional. Additionally, with contribute, when a file is deleted from the server, the file is never deleted from the backup. This protects the backup from inadvertent deletes. 

    Because I did not want to lose files on the backup that may have been deleted from the server, I did not want to rebuild the pairs, since all knowledge of old, deleted files would be lost. Therefore, to be completely safe in reestablishing a new folder pair, I must keep the old backup files as well as the new - twice the space required before this issue cropped up, and if I ever need a deleted file, I'll need to remember to look in two different locations, instead of just the one. 

    With all this understood, I did go ahead and create a new folder pair and began to use that instead. It runs fine, fast and as expected. I just know to never make major moves or reconfiguring of the directories on the server, unless I am willing to risk the slowdown happening again. 

    So, it's a work-around, not a fix, but seeing the lack of interest in a real fix,it looks like this is as good as it's going to get, for the forseeable future. 

    - Kevin
    Wednesday, February 25, 2009 3:28 PM