actually, i would consider it some level of bug that SMB can beat rsync in certain tasks in backuppc.
In reality, the only point at which rsync would be any slower than SMB would be during the initial scan for changed files, which SMB wouldnt be doing and would rely on the program that is doing the actual copy to do in some way. I would assume that most of the time, the client/server based rsync/rsyncd system would outperform the 2 layer SMB system of a transfer protocal and a seperate transfer program. i have noticed that the cygwin based rsync ports are not very good performers and that may really be the root of the problem. the other explanation might just be a configuration error or some peculiar circumstance on my system which may be moderately common. i like to avoid ruling out user error as it usually is the problem. i have combed my config files and found nothing out of the ordinary though... On Nov 14, 2007 8:56 PM, Gene Horodecki <[EMAIL PROTECTED]> wrote: > Interesting point you make about rsyncd vs. smb transfer rates. I would > have never guessed smb to be better at anything. I'm still going rsyncd on > everything, since it's better at dealing with in-use files, etc. It just > seems rsyncd is all around more robust. > > It would be nice if the compression, schedule, and transfer method could be > set per directory, wouldn't it? Then I'd use samba and no compression for > my bigger storage areas that probably won't be open, and rsyncd/compression > for other areas.. > > > "dan" <[EMAIL PROTECTED]> wrote: > > yes! i have noticed that the compression does hit performance a lot. > > I have a windows2003 server that im backing up to an ubuntu backuppc > > server accross gigabit using rsyncd. I notice that the transfer rate > > with compression turned on is not much more than that of 100Mb > > ethernet(maybe 12Mb/s or so, so about twice as high). if i turn off > > compression, my backups suddenly jump up to 30-40Mb/s which is quite > > nice. > > > > this is something to do with how the compression is being handled. I > > have tried to lower the compression level and had very very mild > > results. > > > > im sure everyone is sick of hearing about my nexenta backuppc test rig > > but this is applicable to the situation. on nextenta, using ZFS with > > compression turned on, i see ZERO hit on the transfer speed on the > > gigabit. i get an average of 30-35Mb/s with some higher peeks on > > large files with the ZFS built in compression on OR off. > > > > I am seriously considering a Nexenta, Solaris, or openSolaris platform > > for backuppc for this reason. > > > > unfortunately for me, i need to have compression turned on as i back > > up some thousands of HIGHLY compressible files(4Gb down to 200Mb) and > > can wait longer on the backup to save disk space. > > > > i guess one more point to make is that i get much faster compressed > > file backups when doing it on SMB shares rather than rsyncd(faster as > > in transfer rates, not total backup time) but SMB doesnt cut it for a > > lot of my backups, especially remote backups which I am just now > > experimenting with. > > > > On Nov 14, 2007 12:54 PM, Michael Barrow <[EMAIL PROTECTED]> > wrote: > >> > >> > >> > >> > >> On Nov 14, 2007, at 11:41 AM, Michael Barrow wrote: > >> > >> > >> On Nov 14, 2007, at 10:19 AM, Gene Horodecki wrote: > >> Hi there.. I just did my first big backup with backuppc and to be honest > the > >> results were alittle dissapointing.. It's taken 6 hours now at > approximately > >> 80% CPU to back up my 70Gb photo archive. Does this sound about right? > My > >> entire system is around 240Gb.. at this point I doubt I could do it all > in > >> one day. A regular ntbackup does my photos in about 3 hours. > >> > >> The way to go for me might be to turn off compression entirely. Does > >> anyone know if I backuppc will handle this well now that I have a full > >> backup in place? Or should I delete the backup, set the compression to > zeo, > >> and start over? Thanks! > >> Totally turn off compression! That will use less CPU and take less time. > You > >> don't want to do gzip compression on image files because they're not > going > >> to compress! I think that if you turn off compression now, the next > backup > >> will snag all of the files again and write them into the uncompressed > pool. > >> > >> > >> I think I was wrong about the rewriting the files. I reread the docs > (what a > >> concept!) and it says that it's OK to change the compression value after > >> things have already been written and it will do the right thing -- that > is > >> the hash will work since it's taken of the uncompressed version of the > file. > >> > >> -- > >> Michael Barrow > >> michael at michaelbarrow dot name > > > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
