Ken,
I think you just found your problem. Specifically the SIZE_DATA_BUFFERS
parameter. That parameter is the block size that the tape drive uses to
write with. If you changed this at any time and continued to use the same
tape (if you did not change the retention) then you will not be able to read
any data on that tape prior to the change.
Try going back to the previous value(s) used for the SIZE_DATA_BUFFERS
parameter and eventually you will be able to read the data.
If you cannot read the data you just wrote, forget what I said...
Bill Wiessner
VERITAS Software
Staff Systems Engineer
DoD/Intelligence
Office: 410-877-7689
Cell: 410-804-3321
-----Original Message-----
From: SIBLEY, Ken R. - ACCOREL [mailto:sibley_ken AT accorel DOT com]
Sent: Wednesday, January 23, 2002 1:17 AM
To: 'NetBackup List'
Subject: RE: [Veritas-bu] SDLT restore problem
> -----Original Message-----
> From: BAHNMILLER,BRYAN (A-ColSprings,ex1)
> [mailto:bryan_bahnmiller AT agilent DOT com]
> Sent: Tuesday, January 22, 2002 5:39 PM
> To: SIBLEY, Ken R. - ACCOREL
> Subject: RE: [Veritas-bu] SDLT restore problem
>
>
> Ken,
>
> Have you tuned NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS?
>
> When we started working with LTO drives we followed our SE's tuning
> process. This was basically increase the size and number
> until backups fail,
> then try restoring. Back the sizes and number down until
> restores work.
>
> And it seems tuning for optimal performance will be
> different for every
> OS. We are running HP/UX and NT here. The tuning between
> HP/UX and NT are
> way different. I'm pretty sure it will differ between HP/UX, Solaris,
> AIX,,,,.
>
I have tuned the size and number a little. We have increased
them some, but had to back them off a little. The master/media
server (Sun E450) has 4GB RAM and we run so many jobs via
10 DLT7000 drives in 2 libraries (SDLT library to replace 1)
that we started running out of memory and had to back them
down some. If we drop the parameters more then we are going
to definately be in trouble for performance.
Since I have already installed SSO I might try working on
the restore from the SAN media server where I can tune the
parameters seperate from the normal jobs on the master.
Didn't I read in another message that you can tune these
differently on each media server?
Thanks,
Ken
Ken Sibley
Sr. Unix Administrator
Accor Economy Lodging
ksibley AT accorel DOT com
469-737-3370
> Just a thought.
>
> Bryan
>
> Bryan Bahnmiller
> Enterprise Hosting
> Storage Engineer - development team
> IT | Information Technology
>
> Agilent Technologies, Inc.
> 1900 Garden of the Gods Road, M/S C103G
> Colorado Springs, CO 80907
>
> (719) 590-3262 Tele
> www.agilent.com
>
>
> > -----Original Message-----
> > From: SIBLEY, Ken R. - ACCOREL [mailto:sibley_ken AT accorel DOT com]
> > Sent: Tuesday, January 22, 2002 4:02 PM
> > To: 'veritas-bu AT mailman.eng.auburn DOT edu'
> > Subject: RE: [Veritas-bu] SDLT restore problem
> >
> >
> > This is an section of the restore progress log for a test
> > that was performed today. All of our other tests were with
> > multiplexed backups and restore while this test was with
> > multiplexing turned to 1.
> >
> > As you can see below the error is a media read error.
> > We have tried different clients and backups from different
> > days so a tape error is pretty unlikely. I am not sure
> > how to check that the label is "exactly" the same on both
> > lines of the st.conf other than visually with vi. sgscan
> > only shows the label for the drives "QUANTUM SuperDLT1".
> >
> > 10:52:13 (81536.xxx) Restore job id 81536 will require 1 image.
> > 10:52:13 (81536.xxx) Media id SD0234 is needed for the restore.
> >
> > 10:52:17 (81536.001) Restoring from image created Tue Jan 22
> > 10:35:27 2002
> > 10:52:19 (81536.001) INF - Waiting for mount of media id
> > SD0234 on server
> > udal003app.
> > 10:53:16 (81536.001) INF - Waiting for positioning of media
> > id SD0234 on
> > server udal003app.
> > 10:53:32 (81536.001) INF - Beginning restore from server
> udal003app to
> > client u23tst1.
> > 11:08:36 (81536.001) /usr/local/admin/opdir/ was not restored.
> > 11:08:36 (81536.001) /usr/local/admin/opdir/addpr.ksh was not
> > restored.
> > 11:08:36 (81536.001) /usr/local/admin/opdir/addusr.ksh was
> > not restored.
> > 11:08:36 (81536.001) /usr/local/admin/opdir/delpr.ksh was not
> > restored.
> > 11:08:36 (81536.001) /usr/local/admin/opdir/delusr.ksh was
> > not restored.
> > 11:08:36 (81536.001) /usr/local/admin/opdir/menu.ksh was
> not restored.
> > 11:08:37 (81536.001) /usr/local/admin/opdir/altwrap.exe was
> > not restored.
> > 11:08:39 (81536.001) Status of restore from image created Tue Jan 22
> > 10:35:27 2002 = media read error
> >
> > 11:08:40 (81536.xxx) INF - Status = the restore failed to
> recover the
> > requested files.
> >
> >
> >
> > Ken Sibley
> > Sr. Unix Administrator
> > Accor Economy Lodging
> > ksibley AT accorel DOT com
> > 469-737-3370
> >
> > > -----Original Message-----
> > > From: Larry Kingery [mailto:larry.kingery AT veritas DOT com]
> > > Sent: Tuesday, January 22, 2002 4:34 PM
> > > To: SIBLEY, Ken R. - ACCOREL
> > > Subject: RE: [Veritas-bu] SDLT restore problem
> > >
> > >
> > > Looks like the variable mode is set correctly, which is what I was
> > > concerned about. Now the question is if the st.conf
> entry is being
> > > recognized correctly.
> > >
> > > Earlier in the file, there's a line which ends in "SDLT220". The
> > > first string in in this line must match EXACTLY with what
> the drive
> > > returns. If it does, the second entry should show up
> when you do an
> > > mt status on a loaded drive.
> > >
> > > That's the error you're receiving?
> > >
> > > SIBLEY, Ken R. - ACCOREL writes:
> > > > The platform is Sun, Solaris 2.6
> > > > w/ NBU 3.4.1. I believe the st.conf
> > > > entry is correct.
> > > >
> > > > SDLT220 = 1,0x38,0,0x29639,4,0x90,0x91,0x90,0x91,3;
> > > >
> > > > The 2 in 0x29639 is because we are also implementing
> > > > SSO for this library which has been installed, but
> > > > waiting for restore testing before implementation.
> > > >
> > > > We are backing up and restoring a Solaris 2.6 client
> > > > accross the network for this test, but we also have
> > > > HP-UX, Linux and NT clients as well.
> > > >
> > > > Ken
> > > >
> > > > Ken Sibley
> > > > Sr. Unix Administrator
> > > > Accor Economy Lodging
> > > > ksibley AT accorel DOT com
> > > > 469-737-3370
> > > >
> > > > > -----Original Message-----
> > > > > From: Larry Kingery [mailto:larry.kingery AT veritas DOT com]
> > > > > Sent: Tuesday, January 22, 2002 3:51 PM
> > > > > To: SIBLEY, Ken R. - ACCOREL
> > > > > Subject: Re: [Veritas-bu] SDLT restore problem
> > > > >
> > > > >
> > > > > What platform?
> > > > >
> > > > > If Sun, do you have the proper st.conf configured?
> > > > >
> > > > > SIBLEY, Ken R. - ACCOREL writes:
> > > > > > We have installed a STK L180 tape library with
> > > > > > 4 SDLT drives. We finally have the drives writing
> > > > > > to tape with a minimum of problems. Unfortunately
> > > > > > now we are trying to run test restores, both
> > > > > > filesystem and Informix DB's. Neither work.
> > > > > > Has anyone had a problem with restores and resolved
> > > > > > them? We are working with Veritas, but no
> > > > > > results so far so I was hoping someone here could
> > > > > > help. This is our last step before putting the
> > > > > > unit into production.
> > > > > >
> > > > > > Ken Sibley
> > > > > > Sr. Unix Administrator
> > > > > > Accor Economy Lodging
> > > > > > ksibley AT accorel DOT com
> > > > > > 469-737-3370
> > > > > > _______________________________________________
> > > > > > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > > > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > > > >
> > > > > --
> > > > > Larry Kingery
> > > > > ...from the home office in Grand Rapids, Michigan
> > > > >
> > > > _______________________________________________
> > > > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > >
> > > --
> > > Larry Kingery
> > > Of couse, I could be wrong.
> > >
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >
>
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
