search for: chuckw

During my initial download for my home directory backup, it took rsync over 6 hours to do the initial backup, but I can FTP the stuff in about 30 Mins. Is Rsync usualy this slow? I have compression turned on, and its across a 100 MB/S network, Anyone had this problem before? Steve Sills

...latnum Computers, President > > > http://www.platnum.com > > > steve@platnum.com > > > > > > ----- Original Message ----- > > > From: "Streubert, Christoph" <Christoph.Streubert@disney.com> > > > To: "Chuck Wolber" <chuckw@quantumlinux.com>; "Steve Sills" > > > <steve@platnum.com> > > > Cc: <rsync@lists.samba.org> > > > Sent: Thursday, January 22, 2004 12:52 PM > > > Subject: RE: Rsync's Speed > > > > > > > > > I do not know t...

I am attempting to use rsync to backup a Win98 laptop to a FreeBSD 4.8 backup server. I have experienced the same problem at roughly the same point in the process on two occations. The laptop contains ~2.7Gb of data. On the first attempt we received this error at 2.3Gb and on the second at 2.4Gb. rsync error: partial transfer (code 23) at main.c(575) Would love to have a full backup of the

One thing that's bugged me is that some of the man page lines in the options summary are longer than 79 chars and wrap onto the next line. These are just one line summaries (detailed description appear later) so they can, and should, be terse. Here's an edited diff showing my proposed changes (and a 79 char ruler):

Here's my command copied from a shell script:\ rsync --verbose --progress --stats --compress --rsh=/usr/bin/ssh --recursive --times --perms --links \ /home/* trt@xxxxxx.xxxxxxx.xxx:/remotebackups/ Here's some (a small part) of the output: jk/.recently-used 253 100% 0.00kB/s 0:00:00 rsync: recv_generator: mkdir "jk/.secpanel/.runfiles": Permission denied (2) stat

What I want to do is use rsync to back up a folder to an external drive. I would like to keep 30 days worth. For example: I have backups of June 1 - June 30. Once July 1 comes along, I want to keep June 2 - July 1 and delete June 1, and so forth. Any ideas how I can accomplish this? -- View this message in context: http://www.nabble.com/Rysnc-Schedule-tf4104577.html#a11672997 Sent from the

Hi all, I'm new to the rsync list. I've been searching for two days and have tried five different installs and so far none work the way I need them to. I have an "backup" server running rsync --version: rsync version 2.6.6 protocol version 29 Copyright (C) 1996-2005 by Andrew Tridgell and others <http://rsync.samba.org/> Capabilities: 64-bit files, socketpairs, hard

OK, I set up a new PC with a fresh XP load to be my rsync server. Rsync by itself seems to work fine (thank God. I'm going nuts.) I am still having problems when I throw ssh into the mix. At least now, things don't crash, but they do hang. The file list gets build, the transfer starts and it gets through maybe a few hundred files, but then everything stops. All the processes are still

Just got this from our nightly backup rsync: overflow: flags=0x6e l1=99 l2=1952984691 lastname=var/www/manual/mod/mod_php4/de/function.get-exte ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at util.c(238) Command exited with non-zero status 22 real 5.15 user 1.00 sys 0.88 Rsync version information: [root@gluon root]# rsync

System is current Debian stable with rsync version: * rsync version 2.6.0 protocol version 27 * Capabilities: 64-bit files, socketpairs, hard links, symlinks, * batchfiles, IPv6, 64-bit system inums, 64-bit internal inums * * Modified for Debian to have --bwlimit-mod, a variation on the --bwlimit * algorithm. I have noticed that --link-dest only seems to work for me if I'm using an

I've never seen this one before. I'm using rsync 2.6.2 on both ends. Server (Athlon, 768MB RAM) checks out just fine. The only anomoly appears to be that this process has been running for 248268.43 seconds (this is not unexpected with this particular host we're backing up). Commandline: /usr/bin/time -p /usr/bin/rsync -e /usr/bin/ssh --archive --compress --sparse --stats

I've been getting this error message for a few days from a customer's server and we can't seem to decipher it. I googled for it and only found references to it with respect to much older versions of rsync. We're running the Debian packaged version of rsync version 2.6.2-3. The customer side is running 2.6.3 compiled from source. #### inflate (token) returned -5 rsync error:

Have the hard-links optimizations that were described here been implemented? http://lists.samba.org/archive/rsync/2004-January/008137.html In any case, what's the general consensus behind using the --hard-links option on large (100GB and above) images? Does it still use a ton of memory? Or has that situation been alleviated? ..Chuck.. -- http://www.quantumlinux.com Quantum Linux

One of our servers is a CentOS 4 Linux/Samba filesharing server that serves an access database (via a mapped drive) to a client application running on Windows 98. Ever since we started rsync'ing it to back it up every night, it required samba to be restarted after the backup or the clients had trouble accessing the database. Recently though, the client application is complaining when

rsync commandline: /usr/bin/rsync -e /usr/bin/ssh --archive --compress --sparse --verbose --stats --delete --numeric-ids --partial --relative --one-file-system target.host:/ /destination/path/ target rsync version: 2.6.3 destination rsync version: 2.6.2 The server we're trying to synchronize contains directories within "/" that are mounted to other locations within

Hi, We back up a lot of machines with varying version of rsync installed on them. The oldest machine (hopefully soon to be retired) is running rsync version 2.5.7 (protocol version 26). We back this machine up from "/" onwards with a few excludes in there. I noticed today that whenever we use the --relative and --delete flags together, the --delete flag seems to have no affect.

Just built 2.6.1 and started testing it. Nice job guys. I especially love the --progress and hardlink tweaks. Quite often, while I have systems backing up out of cron, I'd love to be able to see the --progress. Unfortunately, it's just not practical to crank up the verbosity like that on a regular basis (some of these systems have a few million files). A neat feature I'd like to see