On Mon, 18 Feb 2002, Bernhard R. Erdmann wrote:
> > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k
> > Option 2 will nullify all of xfsdump's fault tolerance features when
> > writing to tape. In other words, if there's a tape error or you hit the
> > end of tape, xfsdump can't recover.
> Good point. Does xfsdump's fault tolerance depend on writing/reading
> to/from tape itself or will xfsrestore be happy when being fed out of a
> pipe, too?
xfsdump's fault tolerance for tapes, is based on splitting a dump into a
number of media files and tape records and writing regular file marks. If
something goes wrong, xfsdump will ask for a new tape and continue from
the last file mark which was OK.
With dumping to a file or pipe, xfsdump wont do any of that. The dump
will be interspersed with file headers which xfsrestore will use to verify
the contents, but there's no concept of xfsdump backing up and continuing
a dump from an earlier position if something goes wrong.
In your example, if something goes wrong, xfsdump will probably just exit
early with a dump INTERRUPTED message. If there's a problem on the tape
that xfsdump didn't detect, then upon restoration, xfsrestore will
probably just exit early, assuming the pipe from dd broke.
If you use dd with xfsdump, xfsrestore will not be able to read directly
from the tape, as the dump will have been written with the drive_simple
strategy (ie. the format used for files or pipes). You'd have to use dd
to read from the tape, so if there's a tape error dd wont do anything to