MAJOR ISSUE: vrestore from tape under Tru64 4.0F

MAJOR ISSUE: vrestore from tape under Tru64 4.0F

Post by James Murr » Mon, 30 Jun 2003 06:29:31



Hello to all:

Here is a recap of what is going on:

1) Hooked up an Ecrix (Exabyte) VXA-1 to an XP1000 alpha w/ Tru64 4.0F

2) Edited and compiled ddr.dbase to add density code (0x80) by a)
extending scsi_density_table_size = 0x81 and b) adding DensityCode   =
 0x80 for DensityNumber   =  1. This got rid of the error message :
ctape_ioctl: unmapped scsi density code (0x80) - DDR entry needed

3) Made a level 0 vdump of several SCSI hard drives, with standard
error & output showing nothing unusual

The error:

I tried selectively restoring a few directories interactively just to
verify all went Ok:

                 vrestore -f /dev/rmt1h -i -D ./

While all top level directories seem to appear in the hierarchy shown
by vrestore, subdirectories willl not be found.

For illustration, here is what happens when attempting to selectively
add for extraction a subdirectory of /home:

                 (/) cd home
                 (/home/) ls
                  .:
                 file or directory <.> does not exist

An extraction of the whole directory /home will return an empty
hierarchy:

               (/) add home
               (/) extract

              XP.localhost{/t1 %65}>ls -l home
              total 0
              XP.localhost{/home %66}>

I have tried going further down in the tape - just to be on the safe
side (mt -f /dev/rmt1h fsf ) - but this is the end of the tape.

At this point, my level 0 dumps are unreliable: some directories are
present, others simply do not make it to the tape. I originally
thought the problem was due to the density issue, hence the edit /
compile of ddr.dbase.

I hope I am not missing something trivial, but this seems more
involved.

Thanks for any help / pointers / suggestions.
James

 
 
 

MAJOR ISSUE: vrestore from tape under Tru64 4.0F

Post by Adam Pric » Mon, 30 Jun 2003 15:58:09



> Hello to all:

> Here is a recap of what is going on:

> 1) Hooked up an Ecrix (Exabyte) VXA-1 to an XP1000 alpha w/ Tru64 4.0F

> 2) Edited and compiled ddr.dbase to add density code (0x80) by a)
> extending scsi_density_table_size = 0x81 and b) adding DensityCode   =
>  0x80 for DensityNumber   =  1. This got rid of the error message :
> ctape_ioctl: unmapped scsi density code (0x80) - DDR entry needed

> 3) Made a level 0 vdump of several SCSI hard drives, with standard
> error & output showing nothing unusual

> The error:

> I tried selectively restoring a few directories interactively just to
> verify all went Ok:

>                  vrestore -f /dev/rmt1h -i -D ./

> While all top level directories seem to appear in the hierarchy shown
> by vrestore, subdirectories willl not be found.

> For illustration, here is what happens when attempting to selectively
> add for extraction a subdirectory of /home:

>                  (/) cd home
>                  (/home/) ls
>                   .:
>                  file or directory <.> does not exist

> An extraction of the whole directory /home will return an empty
> hierarchy:

>                (/) add home
>                (/) extract

>               XP.localhost{/t1 %65}>ls -l home
>               total 0
>               XP.localhost{/home %66}>

> I have tried going further down in the tape - just to be on the safe
> side (mt -f /dev/rmt1h fsf ) - but this is the end of the tape.

> At this point, my level 0 dumps are unreliable: some directories are
> present, others simply do not make it to the tape. I originally
> thought the problem was due to the density issue, hence the edit /
> compile of ddr.dbase.

> I hope I am not missing something trivial, but this seems more
> involved.

> Thanks for any help / pointers / suggestions.
> James

Are you sure that /home is not a separate mount point? It usually
is.
If so then you need to back it up and recover it seperatly.
To test if the problem is really as you describe or if it is
as I guessed, try recovering /etc/fstab and looking at it.
If you can't then the problem is as I described, if you can
then may be able to use /etc/fstab to help with the rest of
the recovery.
I hope that you are just testing this solution at the moment
rather than in a disaster situation.
Good Luck
Adam
PS If you can afford it use a better tool than vdump/vrestore.
It has some major issues.

 
 
 

MAJOR ISSUE: vrestore from tape under Tru64 4.0F

Post by James Murr » Tue, 01 Jul 2003 01:19:17




> > Hello to all:

> > Here is a recap of what is going on:

> > 1) Hooked up an Ecrix (Exabyte) VXA-1 to an XP1000 alpha w/ Tru64 4.0F

> > 2) Edited and compiled ddr.dbase to add density code (0x80) by a)
> > extending scsi_density_table_size = 0x81 and b) adding DensityCode   =
> >  0x80 for DensityNumber   =  1. This got rid of the error message :
> > ctape_ioctl: unmapped scsi density code (0x80) - DDR entry needed

> > 3) Made a level 0 vdump of several SCSI hard drives, with standard
> > error & output showing nothing unusual

> > The error:

> > I tried selectively restoring a few directories interactively just to
> > verify all went Ok:

> >                  vrestore -f /dev/rmt1h -i -D ./

> > While all top level directories seem to appear in the hierarchy shown
> > by vrestore, subdirectories willl not be found.

> > For illustration, here is what happens when attempting to selectively
> > add for extraction a subdirectory of /home:

> >                  (/) cd home
> >                  (/home/) ls
> >                   .:
> >                  file or directory <.> does not exist

> > An extraction of the whole directory /home will return an empty
> > hierarchy:

> >                (/) add home
> >                (/) extract

> >               XP.localhost{/t1 %65}>ls -l home
> >               total 0
> >               XP.localhost{/home %66}>

> > I have tried going further down in the tape - just to be on the safe
> > side (mt -f /dev/rmt1h fsf ) - but this is the end of the tape.

> > At this point, my level 0 dumps are unreliable: some directories are
> > present, others simply do not make it to the tape. I originally
> > thought the problem was due to the density issue, hence the edit /
> > compile of ddr.dbase.

> > I hope I am not missing something trivial, but this seems more
> > involved.

> > Thanks for any help / pointers / suggestions.
> > James

> Are you sure that /home is not a separate mount point? It usually
> is.
> If so then you need to back it up and recover it seperatly.
> To test if the problem is really as you describe or if it is
> as I guessed, try recovering /etc/fstab and looking at it.
> If you can't then the problem is as I described, if you can
> then may be able to use /etc/fstab to help with the rest of
> the recovery.
> I hope that you are just testing this solution at the moment
> rather than in a disaster situation.
> Good Luck
> Adam
> PS If you can afford it use a better tool than vdump/vrestore.
> It has some major issues.

Hello Adam and thanks for your input - this is no panic situation,
just verification of the process....here are further details I should
have posted for guidance.

/home is indeed a separate mount point, but I actually backed-up all
devices with a sequence of vdump commands within a script:

(...)
/sbin/vdump -0 -U -N -D -f /dev/rmt1h / 2>> $TARERR
/sbin/vdump -0 -U -N -D -f /dev/rmt1h /usr/ 2>> $TARERR
/sbin/vdump -0 -U -N -D -f /dev/rmt1h /home/  2>> $TARERR
/sbin/vdump -0 -U -N -D -f /dev/rmt1h /work/  2>> $TARERR
(...)

The above would presumably append all dumps to the same tape (no
rewind / no eject)
I tried exploring the whole media (fsf) but could not find a number of
sub-directories: past fsf1, I get the same error:

vrestore -if /dev/nrmt1h
vrestore: unable to use save-set; invalid or corrupt format

************* PROGRAM ABORT **************

vrestore: can't obtain fileset attributes

I used fsf rew every time to make sure I started from begin of tape,
then fsf accordingly. I am currently using tar as a workaround, but
would be nice to get to the bottom of this - still not sure if the
issue is with mt, vdump / vrestore or - less likely - the OS interface
with the tape drive (ddr.dbase or other).

Sinc you bring it up, what would your suggetsion be for a replacement
utility to vdump / vrestore?

many thanks and regards
James

 
 
 

MAJOR ISSUE: vrestore from tape under Tru64 4.0F

Post by Adam Pric » Tue, 01 Jul 2003 02:45:48






> > > Hello to all:

> > > Here is a recap of what is going on:

> > > 1) Hooked up an Ecrix (Exabyte) VXA-1 to an XP1000 alpha w/ Tru64
> > > 4.0F

> > > 2) Edited and compiled ddr.dbase to add density code (0x80) by a)
> > > extending scsi_density_table_size = 0x81 and b) adding
> > >  DensityCode   = 0x80 for DensityNumber   =  1. This got rid of
> > > the error message :
> > > ctape_ioctl: unmapped scsi density code (0x80) - DDR entry needed

> > > 3) Made a level 0 vdump of several SCSI hard drives, with standard
> > > error & output showing nothing unusual

> > > The error:

> > > I tried selectively restoring a few directories interactively
> > > just to
> > > verify all went Ok:

> > >                  vrestore -f /dev/rmt1h -i -D ./

> > > While all top level directories seem to appear in the hierarchy
> > > shown
> > > by vrestore, subdirectories willl not be found.

> > > For illustration, here is what happens when attempting to
> > > selectively
> > > add for extraction a subdirectory of /home:

> > >                  (/) cd home
> > >                  (/home/) ls
> > >                   .:
> > >                  file or directory <.> does not exist

> > > An extraction of the whole directory /home will return an empty
> > > hierarchy:

> > >                (/) add home
> > >                (/) extract

> > >               XP.localhost{/t1 %65}>ls -l home
> > >               total 0
> > >               XP.localhost{/home %66}>

> > > I have tried going further down in the tape - just to be on the
> > > safe
> > > side (mt -f /dev/rmt1h fsf ) - but this is the end of the tape.

> > > At this point, my level 0 dumps are unreliable: some directories
> > > are
> > > present, others simply do not make it to the tape. I originally
> > > thought the problem was due to the density issue, hence the edit /
> > > compile of ddr.dbase.

> > > I hope I am not missing something trivial, but this seems more
> > > involved.

> > > Thanks for any help / pointers / suggestions.
> > > James

> > Are you sure that /home is not a separate mount point? It usually
> > is.
> > If so then you need to back it up and recover it seperatly.
> > To test if the problem is really as you describe or if it is
> > as I guessed, try recovering /etc/fstab and looking at it.
> > If you can't then the problem is as I described, if you can
> > then may be able to use /etc/fstab to help with the rest of
> > the recovery.
> > I hope that you are just testing this solution at the moment
> > rather than in a disaster situation.
> > Good Luck
> > Adam
> > PS If you can afford it use a better tool than vdump/vrestore.
> > It has some major issues.
> Hello Adam and thanks for your input - this is no panic situation,
> just verification of the process....here are further details I should
> have posted for guidance.

> /home is indeed a separate mount point, but I actually backed-up all
> devices with a sequence of vdump commands within a script:

> (...)
> /sbin/vdump -0 -U -N -D -f /dev/rmt1h / 2>> $TARERR
> /sbin/vdump -0 -U -N -D -f /dev/rmt1h /usr/ 2>> $TARERR
> /sbin/vdump -0 -U -N -D -f /dev/rmt1h /home/  2>> $TARERR
> /sbin/vdump -0 -U -N -D -f /dev/rmt1h /work/  2>> $TARERR
> (...)

> The above would presumably append all dumps to the same tape (no
> rewind / no eject)
> I tried exploring the whole media (fsf) but could not find a number of
> sub-directories: past fsf1, I get the same error:

> vrestore -if /dev/nrmt1h
> vrestore: unable to use save-set; invalid or corrupt format

> ************* PROGRAM ABORT **************

> vrestore: can't obtain fileset attributes

> I used fsf rew every time to make sure I started from begin of tape,
> then fsf accordingly. I am currently using tar as a workaround, but
> would be nice to get to the bottom of this - still not sure if the
> issue is with mt, vdump / vrestore or - less likely - the OS interface
> with the tape drive (ddr.dbase or other).

> Sinc you bring it up, what would your suggetsion be for a replacement
> utility to vdump / vrestore?

> many thanks and regards
> James

OK You used rmt1h to do the backups so regardless of the flags to vdump
it is likely you have only one backup on tape.
Try backup to /dev/nrmt1h instead.
HTH
Adam
 
 
 

MAJOR ISSUE: vrestore from tape under Tru64 4.0F

Post by nospa » Wed, 02 Jul 2003 00:18:58


Quote:>> /sbin/vdump -0 -U -N -D -f /dev/rmt1h / 2>> $TARERR
>> /sbin/vdump -0 -U -N -D -f /dev/rmt1h /usr/ 2>> $TARERR
>> /sbin/vdump -0 -U -N -D -f /dev/rmt1h /home/  2>> $TARERR
>> /sbin/vdump -0 -U -N -D -f /dev/rmt1h /work/  2>> $TARERR

/bin/ksh

OSVER=$( /bin/uname -r )
 case ${OSVER} in
V5*)
    TAPE=/dev/ntape/tape0c
;;
*)
    TAPE=/dev/nrmt0h
;;
 esac

/sbin/vdump -0 -f $TAPE / 2>> $TARERR
/sbin/vdump -0 -f $TAPE /usr 2>> $TARERR
/sbin/vdump -0 -f $TAPE /home 2>> $TARERR
/sbin/vdump -0 -f $TAPE /work 2>> $TARERR

You only need to use -D flag if you trying to backup a directory tree that's
not a mount point and if you do use it this way save my sanity and do
/sbin/vdump -0 -f /dev/nrmt0h -D /home ie I like the directory name to
directly follow the -D option.

 The -N for no rewind and -U for no-unload have never been in my faviour.
Use the non-rewinding tape device is much more standard and least for me
more obvious

 
 
 

MAJOR ISSUE: vrestore from tape under Tru64 4.0F

Post by James Murr » Wed, 02 Jul 2003 03:50:44







> > > > Hello to all:

> > > > Here is a recap of what is going on:

> > > > 1) Hooked up an Ecrix (Exabyte) VXA-1 to an XP1000 alpha w/ Tru64
> > > > 4.0F

> > > > 2) Edited and compiled ddr.dbase to add density code (0x80) by a)
> > > > extending scsi_density_table_size = 0x81 and b) adding
> > > >  DensityCode   = 0x80 for DensityNumber   =  1. This got rid of
> > > > the error message :
> > > > ctape_ioctl: unmapped scsi density code (0x80) - DDR entry needed

> > > > 3) Made a level 0 vdump of several SCSI hard drives, with standard
> > > > error & output showing nothing unusual

> > > > The error:

> > > > I tried selectively restoring a few directories interactively
> > > > just to
> > > > verify all went Ok:

> > > >                  vrestore -f /dev/rmt1h -i -D ./

> > > > While all top level directories seem to appear in the hierarchy
> > > > shown
> > > > by vrestore, subdirectories willl not be found.

> > > > For illustration, here is what happens when attempting to
> > > > selectively
> > > > add for extraction a subdirectory of /home:

> > > >                  (/) cd home
> > > >                  (/home/) ls
> > > >                   .:
> > > >                  file or directory <.> does not exist

> > > > An extraction of the whole directory /home will return an empty
> > > > hierarchy:

> > > >                (/) add home
> > > >                (/) extract

> > > >               XP.localhost{/t1 %65}>ls -l home
> > > >               total 0
> > > >               XP.localhost{/home %66}>

> > > > I have tried going further down in the tape - just to be on the
> > > > safe
> > > > side (mt -f /dev/rmt1h fsf ) - but this is the end of the tape.

> > > > At this point, my level 0 dumps are unreliable: some directories
> > > > are
> > > > present, others simply do not make it to the tape. I originally
> > > > thought the problem was due to the density issue, hence the edit /
> > > > compile of ddr.dbase.

> > > > I hope I am not missing something trivial, but this seems more
> > > > involved.

> > > > Thanks for any help / pointers / suggestions.
> > > > James

> > > Are you sure that /home is not a separate mount point? It usually
> > > is.
> > > If so then you need to back it up and recover it seperatly.
> > > To test if the problem is really as you describe or if it is
> > > as I guessed, try recovering /etc/fstab and looking at it.
> > > If you can't then the problem is as I described, if you can
> > > then may be able to use /etc/fstab to help with the rest of
> > > the recovery.
> > > I hope that you are just testing this solution at the moment
> > > rather than in a disaster situation.
> > > Good Luck
> > > Adam
> > > PS If you can afford it use a better tool than vdump/vrestore.
> > > It has some major issues.
> > Hello Adam and thanks for your input - this is no panic situation,
> > just verification of the process....here are further details I should
> > have posted for guidance.

> > /home is indeed a separate mount point, but I actually backed-up all
> > devices with a sequence of vdump commands within a script:

> > (...)
> > /sbin/vdump -0 -U -N -D -f /dev/rmt1h / 2>> $TARERR
> > /sbin/vdump -0 -U -N -D -f /dev/rmt1h /usr/ 2>> $TARERR
> > /sbin/vdump -0 -U -N -D -f /dev/rmt1h /home/  2>> $TARERR
> > /sbin/vdump -0 -U -N -D -f /dev/rmt1h /work/  2>> $TARERR
> > (...)

> > The above would presumably append all dumps to the same tape (no
> > rewind / no eject)
> > I tried exploring the whole media (fsf) but could not find a number of
> > sub-directories: past fsf1, I get the same error:

> > vrestore -if /dev/nrmt1h
> > vrestore: unable to use save-set; invalid or corrupt format

> > ************* PROGRAM ABORT **************

> > vrestore: can't obtain fileset attributes

> > I used fsf rew every time to make sure I started from begin of tape,
> > then fsf accordingly. I am currently using tar as a workaround, but
> > would be nice to get to the bottom of this - still not sure if the
> > issue is with mt, vdump / vrestore or - less likely - the OS interface
> > with the tape drive (ddr.dbase or other).

> > Sinc you bring it up, what would your suggetsion be for a replacement
> > utility to vdump / vrestore?

> > many thanks and regards
> > James

> OK You used rmt1h to do the backups so regardless of the flags to vdump
> it is likely you have only one backup on tape.
> Try backup to /dev/nrmt1h instead.
> HTH
> Adam

Hello Adam -

Indeed, /dev/nrmt1h does seem to work; who would have thought that the
flags would have no effect?

Also of interest to point out that I swaped the order of fs to vdump,
so that '/' is actually second on the tape.. not the best in case of
panic situation, but somehow seemed to help the tape fsf.

Thanks again
James