Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!denali!karish From: karish@denali.stanford.edu (Chuck Karish) Newsgroups: comp.unix.questions Subject: Re: Is dump dumb? (Was: Contest: dump(8) parameters for DC300XL 1/4" ...) Keywords: dump(8) cartridge streamer tape backups Message-ID: <23063@labrea.Stanford.EDU> Date: 15 Jul 88 18:09:46 GMT References: <655@rphroy.UUCP> <170@cui.UUCP> Sender: news@labrea.Stanford.EDU Reply-To: karish@denali.stanford.edu (Chuck Karish) Organization: Mindcraft, Inc. Lines: 69 In article <170@cui.UUCP> petitp@cui.UUCP (PETITPIERRE Dominique) writes: > - Why doesn't 'restore -t' give you the name of the file system stored > on the tape? dump stores only the contents of the partition, not any external information like the name by which the operating system knows the disk device. This is in accordance with the minimalist UNIX traditions. I agree that it's frustrating that the paper label on the tape is so important. Besides, what is the true name of a file system? A block special device may have more than one link (name) in the root file system. > - Why isn't it possible to specify many file system to be stored > on the same tape (cartridge). What happens when you want to re-use the first part of the tape, and the file system you want to dump has grown? You're not able to use the tape efficiently unless you dump both file systems again. If you take seriously the purpose of dump, which is to provide security of your users' data, you may appreciate that it's better to put backups on separate tapes, so that failure of a single tape does not destroy two backups. > - Is it true that restored files will have their modification time > always set to the time of the restore command? (no 'p' option like > for tar). Thats what happend to me with a level 0 dump. I just tried a restore -i, logged in to an Ultrix system as root. The correct dates were restored. > - Why isn't it possible to specify the size of the tape in (mega) bytes > rather than this cumbersome combination of density, length and > mysterious 'c' option? dump was written with the assumption that everyone was using reels of 9-track tape. This was fairly accurate at the time. It wouldn't be a bad idea to have dump accept a size parameter in megabytes. The operator will still have to account for changes in tape capacity when the block size is changed (different number of inter-record gaps). > In fact why doesn't dump use all the space available on the tape > without being told how much on the command line? Because there's no portable, reliable way to sense end of tape on UNIX machines. On machines on which this is possible, the vendor is free to add such a capability. > - Why can't dump work on active file systems? At least for incremental > dumps that would be quite useful to run dump in multi-user mode! dump makes four passes through the file system. If the file system is active while this is going on, information gathered on the early passes will not be valid by the time the final pass is complete. dump does work on active file systems; it's just not as reliable. If you run it on an active file system, the file system will be inconsistent when it is restored. fsck will usually fix this, with some unavoidable loss of data. In extreme cases, the restore will fail. > - Why is dump always interactive? Especially because you have to > wait till every user logs out, it would be nice to have dump > run at night, unattended, and properly coping with tape errors, as a > big boy (and mail to 'root' the results). It should be possible to write a script to make dump run unattended. It's a bit tricky to make it smart enough to unmount the file system for you. As for automatically coping with tape errors, I think you're dreaming. My feeling is that it's an important enough task that it merits the attention of a live operator. If you're thorough about doing the dumps, you'll unmount the file system and run fsck first, at least for level 0 dumps. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041