Re: Can't restore from Ultrium: changing volumes on pipe input, abort?
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
Can't restore from Ultrium: changing volumes on pipe input, abort?
Since attempting to replace our old DDS3 tape drives with HP Ultriums,
Amanda backups haven't worked properly. The HP tape drives themselves
seem OK when we back things up to them directly. However when we use
Amanda, the backups seem to work properly but restores fail.
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 16 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.
Re: Can't restore from Ultrium: changing volumes on pipe input, abort?
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
Can't restore from Ultrium: changing volumes on pipe input, abort?
Since attempting to replace our old DDS3 tape drives with HP Ultriums,
Amanda backups haven't worked properly. The HP tape drives themselves
seem OK when we back things up to them directly. However when we use
Amanda, the backups seem to work properly but restores fail.
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 16 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.
Re: Can't restore from Ultrium: changing volumes on pipe input, abort?
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
