Slow disk access while rsync - what should I tune?

[Matthew Dillon]

: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 and has some serious issues when it
    comes to reliably backing data up.  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, but that opens up a pandora's box of other
    issues (such as whether issuing the snapshot itself will destabilize
    the machine), plus the live system will stall while it is making the
    snapshot, assuming you want a consistent snapshot, plus the snapshot
    itself may not be entirely consistent, depending on how it is made.

    Plus dump uses mtime to detect changes, which is unreliable, 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.  From experience, most
    people need to access backups to pull out small bits of information
    rather than whole filesystems, such as to restore a user's home
    directory or web pages, and dump/restore is really unsuitable for
    that sort of thing.

    Live backups are far, far, far superior to dump/restore.

						-Matt