"Kevin O'Brien" <[EMAIL PROTECTED]> wrote:
: You just need to use dd to write to the tape. Use this format:
:
: /usr/local/bin/ssh host_with_files ufsdump 0fu - /var/foo |
: /usr/local/bin/ssh backup_host "dd bs=1024 of=/dev/rmt/0un"
As far as I know, "ufsdump" only exists on Solaris, so I'll assume
that's the context of this query. Note that normally, ufsdump talks
to an rmt (remote mag tape) process on backup_host. Rmt is much more
than just cat(1). Thus, the above will work if all you want to do is
scribble the bits onto a tape. However, it has a few drawbacks.
First, it prevents using ufsdump's "verify" option, as that requires
being able to issue tape ioctl()s for tape positioning and status
retrieval. Admittedly, not many people use the verify option, but it
does exist, and thus should be mentioned.
More important is the second problem, which is that i/o errors are not
propagated back to ufsdump. Rmt returns the result of every read or
write as soon as it gets it. Depending on what backup_host is, either
dd will continue writing, ignoring errors, or it'll exit immediately;
even worse are partial writes, which are generally not considered an
error, but will certainly make ufsrestore unhappy with that part of
the dump. If dd does exit, ufsdump'll want to ask for a new tape to
be mounted and restart the dump.
This brings us to problem three, which is that the dd approach
requires that an entire dump fit on a single tape, or that you have an
atypical dd that can deal with tape changes. Of course, if you do
that, you end up with the subsequent volumes being in a non-standard
format as far as ufsrestore is concerned. That's particularly irksome
if it needs to read multiple volumes, and they aren't presented in
order (ufsdump's tape headers allow gracefully recovering from that).
I'd say the lack of multi-reel support is the worst of the three,
because these days, it's hard to get tapes with anywhere near the
capacity of off-the-shelf disk drives.
So yes, the suggested solution does work, within certain limits.
Of course, most of the above also applies to any BSD-based system's
dump and restore programs, since that's where Solaris' came from. I'm
curious what people think might be good ways of adding a generalized
"use this mechanism to talk to a remote rmt daemon" facility to dump
and restore (please reply directly, since that's only very
tangentially related to using ssh with dump and restore per se).
Dworkin
