Well, once again the list comes through! This one falls into the
"Why didn't I think of that?" category. I was having problems
piping ufsdump to dd like so:
host1# ufsdump 0uf - /dev/dsk/c0t0d0s0 | dd bs=64b of=/dev/rmt/0
which produced backups that could not be read directly by ufsrestore
(original post below).
B C Hamshere <B.C.Hamshere@newcastle.ac.uk> expressed it the most
succintly by saying:
> The problem is that "bs=" specifies the block size for both input and
> output, and you cannot read a 32K block from a pipe. Use "obs=64b" and
> all should then be well.
And indeed, doing:
host1# ufsdump 0uf - /dev/dsk/c0t0d0s0 | dd obs=64b of=/dev/rmt/0
works beautifully, as does:
host1# ufsdump 0uf - /dev/dsk/c0t0d0s0 | ssh host2 "dd obs=64b of=/dev/rmt/0"
Which was the motivation for trying to do this in the first place.
BTW, if you use ssh for network backups, you might also want to
specify "-c blowfish" as it is much faster that the default algorithm
(idea). It is omitted from the line above for clarity reasons.
Some people suggested explicitely specifying "dump 0bf 64 -" which is
the default and by itself is insufficient - the real fix is "dd
obs=64b". Someone suggested we use CFS (the crypto filesystem), but we
only need to encrypt the data for network transport between the
machines being backed up and the tape host. Finally, one person
suggested using Legato, however it is my (possibly flawed and very
minimal) understanding that Legato doesn't encrypt data when doing
network backups, and uses the r-services, which we have disabled for
security reasons. Plus ufsdump is free and familliar. :)
My gratitude goes out to:
:
: David Mitchell <davem@fdgroup.co.uk>
: Peter M Allan <peter.allan@aeat.co.uk>
: B C Hamshere <B.C.Hamshere@newcastle.ac.uk>
: Richard Schulting <richard.schulting@idsys.nl>
: robin.landis@imail.exim.gov
: Kevin Sheehan <Kevin.Sheehan@uniq.com.au>
: Glenn Satchell <Glenn.Satchell@uniq.com.au>
: Marcel Chukwunenye <moc@voyager.mlb.semi.harris.com>
: Frank Pardo <fpardo@tisny.com>
:
and anyone else who's reply may still be on its way to me.
-- Pascal Gaudette <pascal.gaudette@corp.istar.ca> UNIX Programmer/Analyst, iSTAR internet inc. #include <std/disclaimer.h>-----------Original Post------------Original Post-------------
>From pascal@viper.istar.ca Thu May 15 10:44:36 1997 Date: Wed, 14 May 1997 15:18:06 -0400 (EDT) From: Pascal Gaudette <pascal@viper.istar.ca> Reply-To: pascal.gaudette@corp.istar.ca To: sun-managers@ra.mcs.anl.gov Subject: ufsdump & dd weirdness: should I be worried?
Hello fellow sun managers,
We're doing remote backups over the network, and since we're not allowed to send unencrypted data over the wire, I've been using ssh with an invocation like so:
host1# ufsdump 0uf - /dev/dsk/c0t0d0s0 | ssh host2 "dd bs=64b of=/dev/rmt/0"
But we can't seem to read the resulting tapes using ufsrestore! I've reproduced the same behavior without ssh:
host1# ufsdump 0uf - /dev/dsk/c0t0d0s0 | dd bs=64b of=/dev/rmt/0
And after this ufsrestore gives various errors: sometimes it coredumps, sometimes it says something like "Record size (XXX) is not a multiple of dump block size (1024)" and some other times it goes "partial block read: XXX should be YYY" where XXX and YYY are some numbers.
I've read somewhere that there's a problem using ufsdump and dd on Solaris 2.4 and 2.5 (all our machines are 2.5). But looking at this list's archives, I *was* able to figure out a workaround. In Feb 96, Bill Campillo <vm18276@cae802.tu.hac.com> had simillar problems on SunOS 4.1.3_UI and his solution works for me to. I am able to get the data from the tape using something like:
host1# dd bs=64b if=/dev/rmt/0 | ufsrestore rvbf 64 -
Nevertheless, I am somewhat disturbed by the fact that I am making backups which I *know* I won't be able to read directly with ufsrestore. So my question(s) to the list: should I be worried? Should I change the backup method? Am I doing something wrong?
Thanks for any info/help/pointers. I will summarize. -- Pascal Gaudette <pascal.gaudette@corp.istar.ca> UNIX Programmer/Analyst, iSTAR internet inc. #include <std/disclaimer.h>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:55 CDT