Logging problem

[jw schultz]

On Thu, Jul 31, 2003 at 09:29:25AM +0200, René van der Kroft wrote:
> At 01:04 30-7-2003 -0700, you wrote:
> >> Today the rsync run again, the backup directory shows that there where no
> >> file changed.
> >> The Internet statistics for that connection shows: IN 14M, OUT
> >> 133M!  (Incoming on IP port 22, outgoing keep state)
> >> That while the logs shows that there where no files where copied.
> 
> Today I've removed the -vv switch and the traffic is now: IN 7.77M, OUT 
> 423.64 KB. I have three clients running rsync to the server, 1 on OpenBSD, 
> 2 on Windows (cywgin). The windows servers have no trouble with -vv and 
> large traffic, Only the OpenBSD machine. Is this related to the amount of 
> data or files the clients have?

Probably.  You have those detailed logs so you could compare
them to see.  Not being psychic i can't, nor do i want to.
It may also have to do with change rates or other factors.

> Is there another way to do some detailed logging. (files changed, files 
> copied, filesize etc)?
> Now I do this... rsync -vv parameters > /var/log/20030731.log

As i said -vv is primarily for debugging.  For everyday use
most of us use -v.  It gives us a list of files updated and
with --stats some statistics.  I do have some plans for a
new reporting framework to get finer grained control on
verbosity that could also support greater detail but i don't
plan on starting work on it until after 2.5.7 is released.

For now you need to decide how much detail you want and how
to achieve it.  One thing that will greatly reduce the
traffic for the diagnostic messages is to do a pull instead
of a push.  The diagnostic messages are the one thing that
is asymmetrical in comparing pull with push.  Most of those
messages are generated on the receiver so pulling will mean
the messages are generated on the local system.

I prefer having the backup reports and other backup
meta-data with the backups on the backup server which is one
of the reasons why dirvish was written with a pull
methodology.  The other reason being load balancing.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt