two quick conceptual questions RE: rsync (and rsyncing snapshots)

[Chuck Swiger]

user wrote:
> First, how does rsync respond to, and perform, when the source filesystem
> is under very heavy change ?  If I have a filesystem that I want to rsync
> up to a backup server, but that filesystem is _very busy_ with the
> creation, destruction and changing of files, how well does rsync perform,
> and how much does it interfere with the performance of the underlying
> filesystem that it is sending up to the backup server ?

rsync complains when the filesystem changes underneath it, but it will continue 
to run.  On the other hand, rsync is not going to safely maintain the 
referential integrity of a complex file like a live database, but it's okay for 
most other things including mbox's.

Rsync imposes a significant workload if you are syncronizing a large tree of 
stuff which changes a lot, but it's efficient considering the size of the task.

> Related: it occurs to me that perhaps it would be better to snapshot the
> filesystem, mount the snapshot, and then rsync the snapshot.  On the other
> hand, the filesystem is continuously altering the snapshot as files are
> destroyed or changed ... so perhaps this does not gain anything.  Is
> rsyncing a snapshot of a busy filesystem always, ever or never easier than
> rsyncing the busy filesystem itself ?

rsync'ing a snapshot is a fine idea.

> Finally, am I correct that there are _only two_ rsync comparison methods -
> the default checksum method, and the --size-only method ?  Am I correct
> that rsync _always_ looks at the timestamp first, and then applies either
> checksum or size comparison ONLY IF the timestamps are different ?

No, rsync checks both timestamp and size or checksum.

-- 
-Chuck