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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"