Re: [BackupPC-users] Is my backup taking too long?

[Miguel P. <mi...@vc...>]

I ran rsync -v --recursive rsync://username@zeus/iDrive and it gave me a 
full directory listing.

I am an rsync newbie so I don't know what the proper command would be to 
actually make the backup, and how would I time it.
(I guess one easy way to time it would be date > time && rsync && date 
 >> time)

Actually, I changed the backup to only include the iDrive partition and 
it worked:

2004-10-18 20:00:04 full backup started for directory iDrive
2004-10-19 04:12:22 full backup 0 complete, 510873 files, 34922873511 bytes, 0 xferErrs (0 bad files, 0 bad shares, 0 other)

6 hours for one rsync job should not be triggering the timeout, should it?
Is there any way to figure out why it's taking so long?
I mean it's taking as long as a partition with almost 2x data and more 
than 2x files.

The partitions on the remote computer are on the same drive/controller.

Craig Barratt wrote:

>Miguel Pilar writes:
>
>  
>
>>I've seem to have hit a small wall when backing up a Windows 2000
>>computer we use mainly for storage.
>>
>>My transport is rsyncd and it already backs up a few other partitions
>>in the same computer.
>>
>>Here's part of my logs to explain:
>>
>>2004-10-12 13:56:45 full backup started for directory cDrive
>>2004-10-12 15:39:09 full backup started for directory dDrive
>>2004-10-12 19:17:58 full backup started for directory gDrive
>>2004-10-13 10:26:12 full backup started for directory hDrive
>>2004-10-13 23:00:13 full backup started for directory iDrive
>>2004-10-14 07:26:07 Aborting backup up after signal ALRM
>>2004-10-14 07:26:08 Saved partial dump 0
>>2004-10-14 14:39:07 full backup started for directory cDrive
>>2004-10-14 15:00:09 full backup started for directory dDrive
>>2004-10-14 16:29:41 full backup started for directory gDrive
>>2004-10-14 22:05:03 full backup started for directory hDrive
>>2004-10-15 01:11:51 full backup started for directory iDrive
>>2004-10-15 09:37:49 Aborting backup up after signal ALRM
>>2004-10-15 09:37:50 Saved partial dump 0
>>
>>Where it gets weird is the bottom of the XferLog (note to self, do not open 160MB log files on Firefox when you have 256MB of ram) it says:
>>
>><hDrive processing here>
>>Done: 130728 files, 58813513356 bytes
>>Connected to zeus:873, remote version 28
>>Connected to module iDrive
>>Sending args: --server --sender --numeric-ids --perms --owner --group --devices --links --times --block-size=2048 --recursive --checksum-seed=32761 --exclude=*.bak --exclude=*.bkf --ignore-times . .
>>Checksum caching enabled (checksumSeed = 32761)
>>exiting after signal PIPE
>>    
>>
>
>I would suggest increasing the client timeout, but it looks like
>you already have a long time.
>
>It looks like it never receives the file list.  That suggests the
>remote rsync takes a long time to traverse the file tree.  Is that
>disk particularly slower?
>
>I'd recommend trying rsync directly (without BackupPC) and seeing
>if it works and how long it takes.
>
>  
>
>>Shouldn't the log say Aborting backup up after signal PIPE (instead
>>of ALRM) and shouldn't it have borked before the timeout? Or does
>>this have to do with using rsync 2.6.3 instead of 2.6.2.
>>    
>>
>
>It really looks like a timeout: it is sittig and waiting for the
>file list and it never arrives.
>
>  
>
>>BTW:
>>"Rsync running on Cygwin is limited to either 2GB or 4GB file sizes.
>>More testing needs to be done to verify the file size limit for rsync
>>on various platforms."
>>
>>I backup a file which windows reports as being 2,405,867MB, I think
>>I've done a few bigger ones on accident (from my G drive) pretty sure
>>they were 5GB, but never tested for consistency. What's the quickest
>>way to do this? Does this even apply?
>>    
>>
>
>That's old info: cygwin now supports large files, so rsync/cygwin does
>support files bigger than 4GB.
>
>Craig
>  
>

Actually about big-files, some of the coreutils have not been repackaged 
for large files yet, but that's probably old news anyways.

Thanks for the help thus far, and for a great piece of software
--
Miguel Pilar