:cronfy <cro...@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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
