Slow disk access while rsync - what should I tune?

[perryh at pluto.rain.com]

[missing attribution restored]
Matthew Dillon <dillon at apollo.backplane.com> wrote:
> perryh at pluto.rain.com wrote:
> :cronfy <cronfy at gmail.com> wrote:
> :
> :> And also, maybe there are other ways to create incremental backups
> :> instead of using rsync/hardlinks?
> :
> :Yes.  Use dump(8) -- that's what it's for.  It reads the inodes,
> :directories, and files directly from the disk device, thereby
> :eliminating stat() overhead entirely.
> :
> :Any replication mechanism -- rsync, tar, even dd -- can be used
> :as a backup mechanism, but dump was specifically designed for the
> :purpose.

> Well, dump is 25+ years old ...

Why are you running BSD if you prefer newer (=> less mature) stuff?
Switch to Linux!

> ... On a modern (large) filesystem you are virtually guaranteed
> to get corruption due to the asynchronous nature of the dump.
>
> This can be partially mitigated by using a block level snapshot on
> the UFS source filesystem and then dumping the snapshot instead of
> the live filesystem ...

IOW by using "dump -L"

> Plus dump uses mtime to detect changes, which is unreliable, ...

Are you sure about that?  Last I knew it used ctime.

> and the output produced by dump is not live-accessible whereas a
> snapshot / live filesystem copy is.  That makes the dump fairly
> worthless for anything other than catastrophic recovery.

Ever heard of "restore -i"?