In slightly more detail: we have a Sun Ultra E250 running Solaris 2.6.
It has an old DDS3 tape drive and an HP SureStore Ultrium 230 tape
drive, both external. Amanda 2.3.0 is installed, and we've used it
happily for some time with the DDS3 drives. We can write data to
Ultrium tapes with tar or ufsdump, and read it back with tar or
ufsrestore. It seems to be only with Amanda that problems occur.
Restoring files from one backup on the Amanda tape is usually done
with this command:
amrestore -p /dev/rmt/0n machine name disk | ufsrestore -if -
When this is tried with one of the Ultrium backup tapes, the restore
proceeds as normally: I choose the files to be restored, type
"extract", and ufsrestore successfully restores some of the files from
the tape; but before finishing the restore, it stops and gives me the
message
changing volumes on pipe input
abort? [yn]
I tried asking Sun, thinking that this might be a Solaris issue
(before I noticed that the problem only occurs with Amanda-written
ufsdump tapes), but Sun hasn't heard of this problem and says that
it's never heard of Amanda and doesn't support it. Has anyone here
come across a problem like this, or do you know what might be going
wrong?
I'm not sure that I should trust the tapetype definition that I've
been using - the second of the definitions below. Does anyone have a
better one?
define tapetype Ultrium {
comment "HP Ultrium 2300 LTO drive, native"
length 101376 mbytes
filemark 0 kbytes
speed 13334 kbytes
}
define tapetype Ultrium-compressed {
comment "HP Ultrium 2300 LTO drive using compression"
length 160000 mbytes
filemark 0 kbytes
speed 13334 kbytes
}
If more information would help, just ask, and I'll try to supply it.
Happy New Year,
--
-- Chris Cooke.
Division of Informatics, University of Edinburgh, Scotland.
Amanda 2.4.2p2, Solaris 2.6 server, Solaris 2.6 client, DLT-7000,
file system size ~25GB.
You're not the only person to see this. If you search the amanda-users
archive for: changing volumes on pipe input, you'll find a not-terribly
cheerful thread from last May.
I've seen it once, so it appears to be intermittent for me. In my
case, I got all files, but 'ufsrestore i' and 'ufsrestore x' failed
with your error message, so I didn't get proper directory
owner/group/permissions.
In my case, 'ufsrestore r' did work perfectly, so I'm not quite as
frightened as I would be otherwise. The trials I ran were:
Trial Results
----- -------
amrecover Fail with "changing volumes on pipe input"
amrestore to file, then:
ufsrestore if Fail with "Specify next volume #".
ufsrestore xf Fail with "Specify next volume #".
ufsrestore rf Worked perfectly.
It's not clear to me if this is ufsdump problem, a ufsrestore problem,
a taper problem, or some strange combination.
I'm moving everything to Solaris 8 in the next two months, and have
fantasized that the issue will go away; though the amanda-users
archive is not terribly optimistic about that, either. :-)
--
Jay Lessert jay_l...@accelerant.net
Accelerant Networks Inc. (voice)1.503.439.3461
Beaverton OR, USA (fax)1.503.466-9472