Re: Can't restore from Ultrium: "changing volumes on pipe input, abort?"

2002-06-23 Thread Jay Lessert

On Thu, Jan 03, 2002 at 03:20:02PM +, Chris Cooke wrote:
> 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?

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   [EMAIL PROTECTED]
Accelerant Networks Inc.   (voice)1.503.439.3461
Beaverton OR, USA(fax)1.503.466-9472



Re: Can't restore from Ultrium: "changing volumes on pipe input, abort?"

2002-02-18 Thread Jay Lessert

On Thu, Jan 03, 2002 at 03:20:02PM +, Chris Cooke wrote:
> 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?

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   [EMAIL PROTECTED]
Accelerant Networks Inc.   (voice)1.503.439.3461
Beaverton OR, USA(fax)1.503.466-9472




Re: Can't restore from Ultrium: "changing volumes on pipe input, abort?"

2002-01-03 Thread Jay Lessert

On Thu, Jan 03, 2002 at 03:20:02PM +, Chris Cooke wrote:
> 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?

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   [EMAIL PROTECTED]
Accelerant Networks Inc.   (voice)1.503.439.3461
Beaverton OR, USA(fax)1.503.466-9472