SUMMARY: Backup while in multi-user mode

[Chris Torek]

[NB: I am assuming you do incremental backups, not just full-system
backups.  If you have a few dozen gigabytes of disk, you almost
certainly rely on incremental backups.]

Cpio, like any utility that works through the file system, is not well
suited as an `exact backup' program for most if not all Unix systems.
(There is a `trick' to get around this, but it typically does not work
well anyway.)  Here is why:

In article <1991May27.132333.26592 at gjetor.geac.COM>
adeboer at gjetor.geac.COM (Anthony DeBoer) writes:
>If your cpio implements the "a" parameter, you can do a backup without
>affecting the access times of the files on the disk:
>
># find . -print | cpio -ovBca > /dev/rmt0

Reading a file through the file system updates the file's access time
(and reading a directory updates the directory's access time).  The
only way to change the time back, through the file system, is with the
utime or utimes call (which call to use depends on which Unix system;
some support both---the only real difference is that utimes uses more
precise timestamps).

Using utime/utimes on a file will update the file's `ctime'
(inode-change time), since it changes the inode information.

Any exact-backup program must write out every file whose ctime is
greater than that of the last backup.  Otherwise an important change,
such as `file 1234 went from rw-r--r-- to rw-------', will not appear
on the tape.  It cannot quit after writing just the inode information
since the utime(s) system call(s) can be used to make a new file look
older; when this is done, only the ctime tells the truth: that the
file needs to be backed-up.

Thus, with a through-the-file system backup program, you have your
choice of either clobbering access times (reading everything that
is being backed-up) or making incrementals impossible.

Here is the trick:  When operating on a read-only file system, read
calls do not update the access time.  Thus, if you can unmount the file
system and remount it read-only, you can use cpio or other `ordinary'
utilities to make a backup without affecting the inode timestamps.  It
does not work well because you typically find that you cannot unmount
the file system.  If you could, you could unmount it and run `dump'
anyway.  (You can remount read-only; dump does not care if file systems
are mounted, only whether they change `non-atomically' to dump.)

If inode access times are unimportant to you, this argument collapses.
We happen to like them, and the fact that dump can write a gigabyte
to an Exabyte in just over 66 minutes (or 33 with the 500KB/s model)
does not hurt either.  Dump is currently limited by tape drive data
rates; this is all too often untrue for file system operations.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov