the consensus of the few responses was that sunos "restore"
was not guaranteed to accept a dump made with "ufsdump".
we were in fact able to run "ufsrestore" successfully on another
solaris machine reading the tape drive through the auspex,
so the backups were being written correctly (which was our
major worry).
note that auspexes have built-in support for filesystems bigger
than the size of the solaris disk being backed up (12GB).
original post:
> we have a SUN sparc 20 file server running solaris 2.4 and
> Online Disksuite 4.0 with the one major Disksuite patch 102580-13,
> along with the patches that came on the solaris 2.4 CD plus
> patch 101945-32.
>
> this file server is backed up over the network, using Budtool,
> from an Auspex running 1.8M1Z2 (which amounts to SunOS 4.1.4
> more or less) to a DLT tape drive on the Auspex. since I have
> reproduced the (or a different) problem without Budtool and
> without any reference to any peripherals other than disk drives,
> Budtool does not seem to be relevant.
>
> the usual problem is that "restore" (on the auspex) refuses to
> believe that certain files actually exist on the backup tape,
> even though the listing that was generated during the ufsdump
> (usually, at least, maybe always) shows the files/directories.
> when I reproduced the problem (ufsdump on solaris, ftp to auspex,
> restore on auspex) I got restore errors like "expected #####,
> got #####" where the ####'s were different of course.
>
> so, where is the real problem here? solaris/sunos incompatibilities,
> Online Disksuite, ??
>
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:55 CDT