Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site qubix.UUCP Path: utzoo!watmath!clyde!floyd!harpo!decvax!decwrl!sun!qubix!msc From: msc@qubix.UUCP (Mark Callow) Newsgroups: net.unix-wizards Subject: Re: Restoring incremental dumps - summary of responses Message-ID: <932@qubix.UUCP> Date: Fri, 16-Mar-84 15:01:27 EST Article-I.D.: qubix.932 Posted: Fri Mar 16 15:01:27 1984 Date-Received: Sun, 18-Mar-84 08:02:38 EST References: <354@rdin.UUCP> Organization: Qubix Graphic Systems, Saratoga, CA Lines: 45 There are a couple of incorrect facts in this list of woes with dump/restor. > Doesn't really matter, does it, since Berkeley dump does use > the normal file system mechanisms. 4.2BSD dump still dumps the old way using inodes. Therefore dumps must still be done on quiescent file systems. We actually do level 0 (monthly) and level 1 (weekly) dumps in single-user mode and do other levels (daily) multi-user but early in the morning. 4.2BSD "restore" is a completely rewritten "restor". The "e" was added to emphasize the difference. It operates through normal file system operations. This means that it can be used to move filesystems from one partition to another even when the destination is smaller than the source (provided of course that the data will fit!). It has some other nifty features too, such as being able to restore files into a real filename instead of one named for the inode and having an interactive mode where you can move through the hierarchy on the dump tape like you move through a disk file system hierarchy. >> What is not explicit here is that you have to read in the >> incremental dump *immediately* after the full dump. As >> Robert Perlberg (rdin2!perl) points out, dump/restor work by >> dumping and restoring files as inodes (i.e. identified by >> their inode number, not their file names). Restoring an >> incremental dump tape will not overwrite an existing inode >> unless that inode was modified between the base dump and the >> incremental dump. However, if you create some files (inodes) >> between reading the base tape and the incremental tape then >> one of these newly created files could easily use the same >> inode as some file that was created between the time of the >> base dump and the time of the incremental dump. > What Tom isn't considering here is that a lot of mixing up of > the filesystem can take place between dumps which would result > in reassigning of inodes. Come on now. If inodes change then the information will be recorded on the incremental dump tape. The point is that if some indoes change between the *restor* of the level 0 dump and the *restor* of the incremental dump then the second restor operation doesn't know about the changes and the result can be a mess. -- From the Tardis of Mark Callow msc@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA ...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc