On many older Unix systems, tar is not; cpio is, to some degree. tar will not back up things like device nodes (and, prior to OpenServer Release 5, it will also not back up empty directories), so a tar backup will not catch anything in /dev, for example, and you will find your device nodes missing when you do your restore. cpio will catch these things.
Handling of sparse files was an issue with older versions.
People ofen used "cpio" with "-p" (pass) to copy files while preserving ownership and perms; most "cp" versions now have a "-p" (preserve) flag to accomplish that need.
Neither one is very good at verification. You can dd the tape to make sure you can read the whole thing, and run it through tar or cpio ... but they'll just check the file headers to make sure they make some sense. If you need better verification, try one of the products listed below. Most third-party backup programs do many things better than the standard utilities included with the OS, including things like making much better emergency recovery diskettes, byte-for-byte verification (if you want), compression, more options for things like nondestructive restore, etc. Many of us swear by them.
gnu tar is a significantly better backup utility, and is available on many archive sites listed in the Administrative FAQ. There is also a shareware tar/cpio archive checker called tapechk, written by Nigel Horne <firstname.lastname@example.org>. A demonstration version is available at ftp://garbo.uwasa.fi/unix/util/tapechk.sco.tar.Z
Commercial programs provide better solutions. The following vendors offer backup programs for SCO, Linux and many other platforms:
Also see /Reviews/supertars.html
It sometimes surprises me that people have trouble with cpio. Not that its usage is at all obvious, but the man or info pages are usually packed with multple examples, and a web search will turn up thousands more.
Probably the two most important things to understand is that the normal use of cpio for creating archives is to feed a list of files to its standard input, and send the output to a storage device or a file. So usually you'll be using a program like "find":
find . | cpio -ocv > /tmp/archive.cpio
Becase cpio reads files from stdin in, you can use it interactively:
cpio -ocv > /tmp/archive.cpio
will hang, waiting for you to type file names. Type in pathnames, pressing enter after each one, and finish with a CTRL-D on a line by itself.
For restoration, if you want everything, a simple:
cpio -ivdum < /tmp/archive.cpio
may be all you need. If you left off " < /tmp/archive.cpio", cpio is just going to sit there and hang, doing nothing.
By the way, that "c" flag in the creation example is supposed to give you compatibility, but it may not: see I can't read a cpio archive created on a Linux box- it fails with "premature end of file". I Used the "c" flag which should give me compatibility..
I often use cpio to copy one directory to a new drive:
cd /data find . | cpio -pdmv /newdrive/data
That used to be important because it retained perms and ownership while cp did not, but cp now can prserve that metadata itself.
Got something to add? Send me email.
I've noticed lately that the paranoid fear of computers becoming intelligent and taking over the world has almost entirely disappeared from the common culture. Near as I can tell, this coincides with the release of MS-DOS. (Larry DeLuca)