Slow incremental cloning

[fabius]

I back up two drives to partitions on an external drive.

One of the drives to be backed up has around 50GB of MP3s and the incremental backups of that take a matter of seconds, as it whizzes through, finding little new to backup.

But the other drive to be backed up, containing 35GB of the System, User files (in fact, everything except music) takes rather longer - every time I do an incremental backup Super Duper sits there for 6-10 minutes doing nothing. Where the filepaths appear later it just says "Cloning [Drivename] to [Drivename2]".

Is this normal? Is it just because of the much larger number of files? Thanks.

[dnanian]

Hm. That doesn't sound terribly normal. When you say it sits there doing "nothing", what does SuperDuper! look like?

It sounds to me like you might have a *huge* number of temporary files, which are being examined in the early stages of operation. Have you rebooted this system recently?

[macfeller]

My daughter had a similat situation. There was one huge file whose permissions were hosed. In Get Info she was not the owner, nor was anyone/thing else. Said file was copied each time.

[dnanian]

It's possible that could be the problem here, of course... but it sounds like -- in his situation -- the delay is before the copying even starts. Hopefully we'll find out more shortly.

[macfeller]

and doing so steadily.

BTW, I did give up on Synk and bought my own SD. Looking forward to v.2!

[dnanian]

Great to hear! Thanks for the support...

[macfeller]

my pleasure

[fabius]

Hm. That doesn't sound terribly normal. When you say it sits there doing "nothing", what does SuperDuper! look like?

Well, it says "Copy Files from [Drive1] to [Drive2]" then it has the progress bar (not moving) and then it says "Cloning [Drive1] to [Drive2]". Then there's a "Stop" button.

It sounds to me like you might have a *huge* number of temporary files, which are being examined in the early stages of operation. Have you rebooted this system recently?

Yeah, I've rebooted in the past since using it, and have just tried rebooting again. After rebooting this time SuperDuper! only took 4.57 before the above situation changed and it began displaying file names... so maybe it's gradually getting quicker!

[dnanian]

OK. This is quite unusual, and I have one other user reporting something semi-similar (though in his case there's a weird, hour-long delay).

Let me ask you to do the following:

* Open Terminal
* Type "sudo sample SVUClone 5", hit return, type your password but don't hit return yet.
* Start the backup.
* At the pause, switch back to the terminal and press return.
* Allow it to complete, and send the sample file (it'll tell you the name), SuperDuper!.log and System Profiler report to support.

Thanks!

[fabius]

Hmm, annoying... this time, for the first time, SuperDuper! didn't have that wait, and went straight into copying files. I'll try doing as you suggest when I next do a backup.

[dnanian]

Drat. Well, a watched pot never boils, and all that.

Let me know if it does pause later, and try to capture the info. Thanks!

[fabius]

Well, I'm trying it again, and I have the pause. But when I try your command I get this:


phil@PhilsPBG4:~$ sudo sample SVUClone 5
sample cannot find a process you have access to which has a name like 'SVUClone'
syntax: sample <pid/partial name> <duration (secs)> { <msecs between samples> } <options>
options: {-mayDie} {-wait} {-subst <old> <new>}*
-file filename specifies where results should be written
-mayDie reads symbol information right away
-wait wait until the process named (usually by partial name)
exists, then start sampling
-subst can be used to replace a stripped executable by another
Note that the program must have been started using a full path, rather than a relative path, for analysis to work, or that the -subst option must be specified


Any ideas?

[dnanian]

Strange: no prompt for your password, either. Was this the 2nd time you tried?

It certainly looks, from that, that the cloner isn't even running, which is quite strange. Can you try again, and at the pause do:

ps -auxww | grep SVU

[fabius]

Yes, sorry, that was the second time I'd tried, hence no password prompt.

It seems to work smoothly the second and subsequent times I run it, so I'll wait again until next time there's a delay.

[dnanian]

OK. Could you check for a crash log for SVUClone as well? Check in both the local (off your Home) and global (off /) Library/Logs/Crash Reporter folders.

[fabius]

I just tried again, and the pause wasn't that long this time (45 seconds), which may be because I restarted the machine only an hour or so ago. Anyway, I tried these commands:


phil@PhilsPBG4:~$ ps -auxww | grep SVU
root 530 26.7 0.2 74980 2236 ?? R 11:08PM 0:00.43 /Applications/SuperDuper!.app/Contents/MacOS/SVUclone -v -v -v -v -p -c different -x -d /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Backup - all files.dset -u Phil Gyford -k SPSD001001-AFFB-0JB1-N3P3-2TE1-455L / /Volumes/Hachiji Backup
root 506 0.0 0.0 28364 428 ?? S 11:08PM 0:00.04 /Applications/SuperDuper!.app/Contents/MacOS/SVUagent
phil 532 0.0 0.0 18172 336 std S+ 11:08PM 0:00.01 grep SVU
phil@PhilsPBG4:~$ sudo sample SVUClone 5
Password:
sample cannot find a process you have access to which has a name like 'SVUClone'
syntax: sample <pid/partial name> <duration (secs)> { <msecs between samples> } <options>
options: {-mayDie} {-wait} {-subst <old> <new>}*
-file filename specifies where results should be written
-mayDie reads symbol information right away
-wait wait until the process named (usually by partial name)
exists, then start sampling
-subst can be used to replace a stripped executable by another
Note that the program must have been started using a full path, rather than a relative path, for analysis to work, or that the -subst option must be specified


It seems to work fine and there are no crash logs.

[dnanian]

Weird. It's almost like it was already done by the time you did the sample!