smurf@work.smurf.noris.de (Matthias Urlichs) writes:
> The real reaosn dump/restore go to the raw disk is that there's otherwise
> NO way to set both ctime and atime/mtime when restoring (or even leaving it
> alone when dumping).
Nope --- dump goes to the raw device, but restore goes through the
filesystem (and hence, you can restore atime/mtime but not ctime).
The main reasons that dump goes to disk directly are (a) to allow
offline backup of unmounted devices, but more importantly (b)
performance. Dump goes through the system in inode order, scanning
blocks sequentially where possible, rather than going through the
nearly random order that a directory scan would imply.
hpa@transmeta.com (H. Peter Anvin) writes:
> Personally, I'd rather see a special system call and go through the
> file system. I do *not* think it is a good idea to go to the raw
> disk on a mounted filesystem. It would be particularly great if a
> utility could be written that would use the BSD dump file format.
We are planning this. I'm not sure entirely how much kernel support
is necessary --- it may be sufficient to simply allow dump to lock
down specific inodes and buffers against reuse by the filesystem, to
protect against the current pathological case where a file or block is
reused by the filesystem between separate passes by dump over the same
block.
However, it may well be possible to do things right through the
filesystem, as long as we can be sure to maintain performance. Once
we start being clever about it, there are a lot of things we can do to
improve dump, including tracking version numbers on inodes so that we
get less confused on active filesystems, and managing the cache
carefully so we don't end up flooding the cache with useless data
during a dump.
For now, however, dump/restore is about the most reliable way of doing
backups as long as the filesystem is quiescent. In particular dump's
incremental backups are rock-solid, whereas gnutar's incremental dumps
have a whole HOST of problems associated with them.
Cheers,
Stephen.