Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!bofh.dot!in-news.erinet.com!bug.rahul.net!rahul.net!a2i!ddsw1!news.mcs.net!not-for-mail From: les@MCS.COM (Leslie Mikesell) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: dump on a DAT tape .. Date: 21 May 1996 23:29:39 -0500 Organization: /usr/lib/news/organi[sz]ation Lines: 71 Message-ID: <4nu57j$g7c@Mercury.mcs.com> References: <4mfon3$gib@news.simplex.nl> <4nlka4$1l5@uriah.heep.sax.de> <4nothl$f3f@mercury.mcs.com> <4nqp9a$6gn@uriah.heep.sax.de> NNTP-Posting-Host: mercury.mcs.com In article <4nqp9a$6gn@uriah.heep.sax.de>, J Wunsch <joerg_wunsch@uriah.heep.sax.de> wrote: >> GNUtar fixes most of these problems. Not sure about that last one. > >It breaks. The tar in FreeBSD _is_ GNUtar. >It also breaks on pathnames > 255 chars (since this is a limitation in >the ustar format). I thought GNUtar had an extension for long names similar to the one for handling sparse files (but I don't think I've needed it). >> Maybe, maybe not. I want to be able to read back any tape on >> any machine. > >The opposite (with tar or cpio) is that you won't be able to create a >backup you are guaranteed to be able to successfully restore the >system into the exact state at the point where the backup has been >taken. A full backup with either (GNU) tar or cpio should install just fine and is probably more likely to tolerate the kinds of inconsistencies you get from backing up a live filesystem. Cpio has no way to restore incrementals correctly, GNUtar does. >> GNUtar can do this too, although the documentation for the option >> leaves a lot to be desired. > >GNUtar removes files between a level-8 and a level-9 restore? I >wonder how it should, give that it doesn't know the idea of a table of >contents (which is IMHO required to be at the beginning of the backup >set in order to have this work). Yes. Use the "--listed-incremental filename" option when creating the backup. If "filename" doesn't exist, you get a full run and the file is created containing a timestamp and a list of directories traversed with their device and inode numbers. If "filename" does exist you get an incremental consisting of all files whose ctime is newer than the timestamp plus everything under new or renamed directories (as determined by the list), and the file is modified in place for subsequent runs. If you want all your incrementals based off the previous full run instead of a chain of runs that have to be restored in order you have to copy the file before making the incremental. GNUtar puts a directory listing ahead of each directory in this mode, keeping track of what is one the tape and what isn't. If you restore with the -G option, it will delete any files that weren't present at the time the backup was made. >Despite of this GNUtar != tar(generic), as much as dump(FreeBSD) != >dump(another system). So the entire discussion is moot. You either >want the greatest flexibility in data exchange, or the best method to >restore your system in case of a catastrophic failure. Both goals are >not exactly compatible. (I personally use tar for many things, and it >happens to be GNUtar what i'm using. But i don't use it for backups.) Not at all. GNUtar can be ported to about anything that has a C compiler and understands the concept of files and directories. Perhaps you could do that with dump, but it would be a lot harder. For example, I have a version for DOS that talks to scsi tapes or rsh. I've cloned a lot of PC's by doing the grunge work of loading windows and apps on one machine, rsh'ing a tar image to a host somewhere, then booting from a floppy with a packet driver and rsh'ing it back to a bunch of others in -G mode to wipe out anything already on the hard drive. A little touch up work to defrag, fix the swapfile, and tweak the network address, etc. and they are all set. And, of course, tar on the host could extract any of the files if that happened to be needed. Les Mikesell les@mcs.com