Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Message-ID: <13596@dog.ee.lbl.gov> Date: 28 May 91 00:37:22 GMT References: <1991May24.013214.2526@servalan.uucp> <1991May27.132333.26592@gjetor.geac.COM> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 55 X-Local-Date: Mon, 27 May 91 17:37:22 PDT [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@gjetor.geac.COM> adeboer@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@ee.lbl.gov